# Godot Engine Documentation in Hebrew
# Copyright (C) 2014-2020, Juan Linietsky, Ariel Manzur and the Godot community (CC-BY 3.0)
# This file is distributed under the same license as the Godot Engine package.
#
# Daniel <lorddaniel09@gmail.com>, 2018.
# Daniel Dovgun <daniel.dovgun@gmail.com>, 2019.
# Ido Dana <idodana01@gmail.com>, 2019.
# RaikaRakka <shaiyatta@gmail.com>, 2018.
# shai sinai <lemun420il@gmail.com>, 2019.
# Yaron Shahrabani <sh.yaron@gmail.com>, 2018-2019.
# יובל הרמן <nhajeho1@gmail.com>, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n"
"POT-Creation-Date: 2020-06-22 14:46+0200\n"
"PO-Revision-Date: 2019-09-07 13:53+0000\n"
"Last-Translator: Ido Dana <idodana01@gmail.com>\n"
"Language-Team: Hebrew <https://hosted.weblate.org/projects/godot-engine/"
"godot-docs/he/>\n"
"Language: he\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=4; plural=(n == 1) ? 0 : ((n == 2) ? 1 : ((n > 10 && "
"n % 10 == 0) ? 2 : 3));\n"
"X-Generator: Weblate 3.9-dev\n"

#: ../../docs/index.rst:2
#, fuzzy
msgid "Godot Docs – *3.2* branch"
msgstr "תיעוד גודוט - ענף ראשי"

#: ../../docs/index.rst:6
msgid ""
"Godot's documentation is available in various languages and versions. Expand "
"the \"Read the Docs\" panel at the bottom of the sidebar to see the list."
msgstr ""
"ניתן להשתמש בתיעוד בכמה שפות וגרסאות שונות. ניתן להחליף בין הגרסאות בפאנל "
"הימני למטה."

#: ../../docs/index.rst:10
#, fuzzy
msgid ""
"This is the documentation for the stable 3.2 branch. Looking for the "
"documentation of the current **development** branch? `Have a look here "
"<https://docs.godotengine.org/en/latest>`_. You can also browse the "
"documentation for the previous stable `3.1 <https://docs.godotengine.org/"
"en/3.1>`_ branch."
msgstr ""
"זה התיעוד לענף הפיתוח. כדי לעבור לתיעוד לענף הנוכחי **יציב** `לחץ כאן "
"<https://docs.godotengine.org/en/stable>`_."

#: ../../docs/index.rst:18
msgid ""
"This documentation is translated from the `original English one <https://"
"docs.godotengine.org/en/latest>`_ by community members on `Weblate <https://"
"hosted.weblate.org/projects/godot-engine/godot-docs>`_."
msgstr ""
"תיעוד זה תורגם מהשפה המקורית באנגלית < https://docs.godotengine.org/en/"
"latest >'_ על ידי חברי הקהילה באתר _ 'Weblate < https://hosted.weblate.org/"
"projects/godot-engine/godot-docs >'."

#: ../../docs/index.rst:22
msgid ""
"Depending on the translation effort's completion level, you may find "
"paragraphs or whole pages which are still in English. You can help the "
"community by providing new translations or reviewing existing ones on "
"Weblate."
msgstr ""
"בהתאם לרמת המאמץ בתרגום, אתה עשוי לגלות פסקאות דפים שלמים שלא תורגמו ויופיעו "
"באנגלית. באפשרותך לסייע לקהילה באמצעות מתן תרגומים חדשים או בדיקה של תרגומים "
"קיימים ב- Weblate."

#: ../../docs/index.rst:27
msgid ""
"For the time being, localized translations are only available for the "
"\"latest\" (development) branch, but should be suitable to learn how to use "
"stable Godot releases nevertheless."
msgstr ""
"לעת עתה, תרגומים לשפות אחרות זמינות רק עבור ענף הפיתוח \"עדכני\" (פיתוח), "
"אבל צריכים להתאים לגרסאות גודוט יציב בכל זאת."

#: ../../docs/index.rst:31
#, fuzzy
msgid ""
"Welcome to the official documentation of `Godot Engine <https://godotengine."
"org>`__, the free and open source community-driven 2D and 3D game engine! If "
"you are new to this documentation, we recommend that you read the :ref:"
"`introduction page <doc_about_intro>` to get an overview of what this "
"documentation has to offer."
msgstr ""
"ברוך הבא למסמך הרשמי של מנוע גודוט, מנוע המשחקים הדו ותלת מימדי החינמי ובקוד "
"פתוח שמונע ע\"י הקהילה. אם המסמך חדש עבורך, אנחנו ממליצים שתקרא את :ref:` דף "
"ההיכרות <doc_about_intro>` כדי להבין מה המסמך הנ\"ל יכול להציע."

#: ../../docs/index.rst:37
msgid ""
"The table of contents below and in the sidebar should let you easily access "
"the documentation for your topic of interest. You can also use the search "
"function in the top left corner."
msgstr ""
"תוכן העניינים למטה ובצד יכול לאפשר לך לגשת בקלות לתיעוד בנושא שבו הנך "
"מעוניין. אתה גם יכול להשתמש בחיפוש בפינה השמאלית העליונה."

#: ../../docs/index.rst:41
msgid ""
"Godot Engine is an open source project developed by a community of "
"volunteers. The documentation team can always use your feedback and help to "
"improve the tutorials and class reference. If you don't understand "
"something, or cannot find what you are looking for in the docs, help us make "
"the documentation better by letting us know!"
msgstr ""
"מנוע גודוט הוא פרוייקט בקוד פתוח שמפותח ע\"י קהילה של מתנדבים. צוות התיעוד "
"תמיד יכול להעזר במשוב שלך כדי לשפר את המדריכים ואת ההפניות למחלקות. אם אינך "
"מבין משהו, או שאינך יכול למצוא משהו שאתה מחפש במסמכים, תן לנו לדעת ועזור לנו "
"לשפר את התיעוד!"

#: ../../docs/index.rst:48
msgid ""
"Submit an issue or pull request on the `GitHub repository <https://github."
"com/godotengine/godot-docs/issues>`_, help us `translate the documentation "
"<https://hosted.weblate.org/engage/godot-engine/>`_ into your language, or "
"talk to us on either the ``#documentation`` channel on `Discord <https://"
"discord.gg/zH7NUgz>`_, or the ``#godotengine-doc`` channel on `irc.freenode."
"net <http://webchat.freenode.net/?channels=#godotengine-doc>`_!"
msgstr ""
"ניתן להגיש pull request או לפתוח תקלה ב`מאגר ב־GitHub <https://github.com/"
"godotengine/godot-docs/issues>`_, ניתן לסייע לנו `לתרגם את התיעוד <https://"
"hosted.weblate.org/engage/godot-engine/>`_ לשפה שלך או לפנות אלינו דרך הערוץ "
"``‎#documentation`` ב־ `Discord <https://discord.gg/zH7NUgz>`_, או בערוץ "
"``‎#godotengine-doc`` תחת `irc.freenode.net <http://webchat.freenode.net/?"
"channels=#godotengine-doc>`_!"

#: ../../docs/index.rst:58
msgid "weblate_widget"
msgstr ""

#: ../../docs/index.rst:59
msgid ""
"The main documentation for the site is organized into the following sections:"
msgstr "התיעוד העיקרי בשביל האתר מסודר לפי הסעיפים הבאים:"

#: ../../docs/index.rst:61
msgid "General"
msgstr "כללי"

#: ../../docs/index.rst:69
#: ../../docs/tutorials/platform/android_in_app_purchases.rst:35
#: ../../docs/tutorials/platform/android_in_app_purchases.rst:44
msgid "Getting started"
msgstr "מתחילים"

#: ../../docs/index.rst:80
msgid "Tutorials"
msgstr "מדריכים"

#: ../../docs/index.rst:110
msgid "Development"
msgstr "פיתוח"

#: ../../docs/index.rst:121
msgid "Community"
msgstr "קהילה"

#: ../../docs/index.rst:131
msgid "Class reference"
msgstr ""

#: ../../docs/about/index.rst:2
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:7
#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:7
#: ../../docs/development/cpp/variant_class.rst:7
msgid "About"
msgstr "על"

#: ../../docs/about/introduction.rst:4
#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:7
#: ../../docs/getting_started/step_by_step/instancing.rst:7
#: ../../docs/getting_started/step_by_step/scripting.rst:7
#: ../../docs/getting_started/step_by_step/signals.rst:10
#: ../../docs/getting_started/step_by_step/animations.rst:7
#: ../../docs/getting_started/step_by_step/filesystem.rst:7
#: ../../docs/getting_started/step_by_step/scene_tree.rst:7
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:7
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:7
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:7
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:7
#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:7
#: ../../docs/getting_started/workflow/export/feature_tags.rst:7
#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:4
#: ../../docs/tutorials/2d/2d_transforms.rst:7
#: ../../docs/tutorials/2d/using_tilemaps.rst:7
#: ../../docs/tutorials/2d/2d_movement.rst:7
#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:7
#: ../../docs/tutorials/2d/2d_meshes.rst:7
#: ../../docs/tutorials/2d/2d_sprite_animation.rst:7
#: ../../docs/tutorials/3d/using_transforms.rst:7
#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:10
#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:7
#: ../../docs/tutorials/3d/spatial_material.rst:7
#: ../../docs/tutorials/3d/lights_and_shadows.rst:7
#: ../../docs/tutorials/3d/reflection_probes.rst:7
#: ../../docs/tutorials/3d/gi_probes.rst:7
#: ../../docs/tutorials/3d/baked_lightmaps.rst:7
#: ../../docs/tutorials/3d/high_dynamic_range.rst:7
#: ../../docs/tutorials/3d/using_gridmaps.rst:7
#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:7
#: ../../docs/tutorials/audio/audio_buses.rst:7
#: ../../docs/tutorials/audio/audio_streams.rst:7
#: ../../docs/tutorials/audio/sync_with_audio.rst:7
#: ../../docs/tutorials/physics/using_area_2d.rst:7
#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:7
#: ../../docs/tutorials/physics/ray-casting.rst:7
#: ../../docs/tutorials/physics/ragdoll_system.rst:7
#: ../../docs/tutorials/physics/kinematic_character_2d.rst:7
#: ../../docs/tutorials/math/vector_math.rst:7
#: ../../docs/tutorials/math/matrices_and_transforms.rst:7
#: ../../docs/tutorials/animation/2d_skeletons.rst:7
#: ../../docs/tutorials/animation/animation_tree.rst:7
#: ../../docs/tutorials/inputs/input_examples.rst:7
#: ../../docs/tutorials/io/saving_games.rst:7
#: ../../docs/tutorials/i18n/internationalizing_games.rst:7
#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:7
#: ../../docs/tutorials/viewports/viewports.rst:7
#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:7
#: ../../docs/tutorials/viewports/custom_postprocessing.rst:7
#: ../../docs/tutorials/shading/shading_reference/shaders.rst:7
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:7
#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:7
#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:7
#: ../../docs/tutorials/shading/shader_materials.rst:7
#: ../../docs/tutorials/shading/screen-reading_shaders.rst:7
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:7
#: ../../docs/tutorials/shading/advanced_postprocessing.rst:7
#: ../../docs/tutorials/networking/ssl_certificates.rst:7
#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:7
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:7
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:7
#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:7
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:11
#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:7
#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:7
#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:7
#: ../../docs/tutorials/plugins/android/android_plugin.rst:7
#: ../../docs/tutorials/misc/binary_serialization_api.rst:7
#: ../../docs/tutorials/misc/state_design_pattern.rst:7
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:7
#: ../../docs/development/cpp/custom_audiostreams.rst:7
#: ../../docs/development/cpp/custom_godot_servers.rst:7
#: ../../docs/development/editor/editor_style_guide.rst:7
#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:7
msgid "Introduction"
msgstr "מבוא"

#: ../../docs/about/introduction.rst:11
msgid ""
"Welcome to the official documentation of Godot Engine, the free and open "
"source community-driven 2D and 3D game engine! Behind this mouthful, you "
"will find a powerful yet user-friendly tool that you can use to develop any "
"kind of game, for any platform and with no usage restriction whatsoever."
msgstr ""
"ברוכים הבאים לתיעוד הרשמי של מנוע גודוט ( Godot Engine ), מנוע המשחק הדו "
"מימדי ותלת מימדי, בעל קוד פתוח, חינמי, ומפותח על ידי הקהילה!\n"
"מאחורי המשפט הארוך הזה, אתם תמצאו כלי חזק אך ידידותי למשמתש שתוכלו להשתמש "
"לפיתוח כל סוג של משחק, לכל סוג של פלטפורמה, וללא מגבלת שימוש כלשהיא."

#: ../../docs/about/introduction.rst:16
msgid ""
"This page gives a broad presentation of the engine and of the contents of "
"this documentation, so that you know where to start if you are a beginner or "
"where to look if you need info on a specific feature."
msgstr ""
"מטרת דף זה היא לתת הצגה רחבה על המנוע, ועל תוכן מסמך זה, כך שתוכל לדעת מאיפה "
"להתחיל אם אתה מתחיל או איפה להסתכל אם אתה צריך מידע נוסף בנוגע למאפיין "
"מסויים."

#: ../../docs/about/introduction.rst:21
msgid "Before you start"
msgstr ""

#: ../../docs/about/introduction.rst:23
msgid ""
"The :ref:`Tutorials and resources <doc_community_tutorials>` page lists "
"video tutorials contributed by the community. If you prefer video to text, "
"those may be worth a look."
msgstr ""

#: ../../docs/about/introduction.rst:27
msgid ""
"In case you have trouble with one of the tutorials or your project, you can "
"find help on the various :ref:`Community channels <doc_community_channels>`, "
"especially the Godot Discord community, Q&A, and IRC."
msgstr ""

#: ../../docs/about/introduction.rst:32
msgid "About Godot Engine"
msgstr "על אודות המנוע Godot"

#: ../../docs/about/introduction.rst:34
msgid ""
"A game engine is a complex tool, and it is therefore difficult to present "
"Godot in a few words. Here's a quick synopsis, which you are free to reuse "
"if you need a quick writeup about Godot Engine."
msgstr ""
"מנוע משחק הינו כלי מורכב, ולכן זה מסובך להציג את Godot במספר מילים. הנה הצגה "
"של היחצן שלנו, שהינכם חופשים להשתמש אם אתם צריכים לכתוב בקצרה על המנוע Godot."

#: ../../docs/about/introduction.rst:38
msgid ""
"Godot Engine is a feature-packed, cross-platform game engine to create 2D "
"and 3D games from a unified interface. It provides a comprehensive set of "
"common tools, so users can focus on making games without having to reinvent "
"the wheel. Games can be exported in one click to a number of platforms, "
"including the major desktop platforms (Linux, macOS, Windows) as well as "
"mobile (Android, iOS) and web-based (HTML5) platforms."
msgstr ""
"המנוע גודוט הוא מנוע משחק בעל תוכן רב ורחב פלטפורמות שמאפשר ליצור משחקי דו "
"מימד ותלת מימד בממשק אחיד. המנוע מספק אוסף מקיף של כלים נפוצים, כך שהמשתמשים "
"יכלו להתמקד על יצירת משחקים מבלי להמציא את הגלגל מחדש. המשחקים יכולים לייצא "
"למספר פלטפורמות בלחיצת כפתור, כגון לפלטפורמות שולחן העבודה הנפוצות (Linux, "
"macOS, Windows), למובייל (Android, iOS) וגם לפלטפורמות מבוססות דפדפן (HTML5)."

#: ../../docs/about/introduction.rst:45
msgid ""
"Godot is completely free and open source under the permissive MIT license. "
"No strings attached, no royalties, nothing. Users' games are theirs, down to "
"the last line of engine code. Godot's development is fully independent and "
"community-driven, empowering users to help shape their engine to match their "
"expectations. It is supported by the `Software Freedom Conservancy <https://"
"sfconservancy.org>`_ not-for-profit."
msgstr ""
"גודוט הוא לגמרי בחינם ובעל קוד פתוח תחת רישיון MIT שמאוד מרשה. ללא תנאים, "
"ללא תמלוגים, כלום. המשחקים של המשתמשים הם שלהם, עד השורה האחרונה של קוד "
"המנוע. הפיתוח של גודוט הוא עצמאי לחלוטין ומונע על ידי הקהילה, במטרה לתמוך "
"במתשתמשים לעצב את המנוע שלהם לפי הציפיות שלהם. גודוט נתמך על ידי 'Software "
"Freedom Conservancy <https://sfconservancy.org>' ללא כוונת רווח."

#: ../../docs/about/introduction.rst:52
msgid ""
"For a more in-depth view of the engine, you are encouraged to read this "
"documentation further, especially the :ref:`Step by step <toc-learn-"
"step_by_step>` tutorial."
msgstr ""
"בשביל יותר מידע על המנוע, אתם מוזמנים לקרוא את התיעוד האלה, במיוחד את המדריך "
"'צעד אחר צעד'."

#: ../../docs/about/introduction.rst:57
msgid "About the documentation"
msgstr "על אודות התיעוד"

#: ../../docs/about/introduction.rst:59
msgid ""
"This documentation is continuously written, corrected, edited, and revamped "
"by members of the Godot Engine community. It is edited via text files in the "
"`reStructuredText <http://www.sphinx-doc.org/en/stable/rest.html>`_ markup "
"language and then compiled into a static website/offline document using the "
"open source `Sphinx <http://www.sphinx-doc.org>`_ and `ReadTheDocs <https://"
"readthedocs.org/>`_ tools."
msgstr ""
"מסמך זה כל הזמן נכתב, מתוקן, נערך ומתחדש על ידי חברים בקהילת המנוע גודוט. "
"התיעוד נערך על ידי קבצי טקסט בשפת Markup `reStructuredText <http://www."
"sphinx-doc.org/en/stable/rest.html>`_ ואז עובר קימפול לאתר סטטי/מסמך לא "
"מקוון בעזרת הכלים קוד-פתוח חינמיים `Sphinx <http://www.sphinx-doc.org>`_ ו- "
"`ReadTheDocs <https://readthedocs.org/>`_ ."

#: ../../docs/about/introduction.rst:66
#, fuzzy
msgid ""
"You can contribute to Godot's documentation by opening issue tickets or "
"sending patches via pull requests on its GitHub `source repository <https://"
"github.com/godotengine/godot-docs>`_, or translating it into your language "
"on `Hosted Weblate <https://hosted.weblate.org/projects/godot-engine/godot-"
"docs/>`_."
msgstr ""
"אתם יכולים לתרום למסמך של גודוט על ידי פתיחת דוחות בעיה, או שליחת תיקונים "
"בעזרת בקשות משיכה בGitHub של גודוט `source repository <https://github.com/"
"godotengine/godot-docs>`_, או שאתם יכולים לערוך את המסמך לשפה שלכם `Hosted "
"Weblate <https://hosted.weblate.org/projects/godot-engine/godot-docs/>`_."

#: ../../docs/about/introduction.rst:72
msgid ""
"All the contents are under the permissive Creative Commons Attribution 3.0 "
"(`CC-BY 3.0 <https://creativecommons.org/licenses/by/3.0/>`_) license, with "
"attribution to \"Juan Linietsky, Ariel Manzur and the Godot Engine community"
"\"."
msgstr ""
"כל התוכן תחת  הרישיון המרשה  (`CC-BY 3.0 <https://creativecommons.org/"
"licenses/by/3.0/>`_)Creative Commons Attribution 3.0, ועם יחוס ל\"Juan "
"Linietsky, Ariel Manzur and the Godot Engine community\"."

#: ../../docs/about/introduction.rst:77
msgid "Organization of the documentation"
msgstr "סדר התיעוד"

#: ../../docs/about/introduction.rst:79
#, fuzzy
msgid ""
"This documentation is organized in five sections with an impressively "
"unbalanced distribution of contents – but the way it is split up should be "
"relatively intuitive:"
msgstr ""
"התיעוד מוסדר לפי חמישה חלקים עם חלוקה לא מאוזנת מרשימה של התוכן - אבל הדרך "
"זה מחלוק אמור להיות יחסית אינטואיטיבי:"

#: ../../docs/about/introduction.rst:83
msgid ""
"The :ref:`sec-general` section contains this introduction as well as "
"information about the engine, its history, its licensing, authors, etc. It "
"also contains the :ref:`doc_faq`."
msgstr ""
"פרק :ref:`sec-general` מכיל את המבוא וכן את המידע על המנוע, על ההיסטוריה "
"שלו,  על הרשאותיו, על מחבריו ועוד. כמו כן מכיל המבוא את :ref:`doc_faq`."

#: ../../docs/about/introduction.rst:86
msgid ""
"The :ref:`sec-learn` section is the *raison d'être* of this documentation, "
"as it contains all the necessary information on using the engine to make "
"games. It starts with the :ref:`Step by step <toc-learn-step_by_step>` "
"tutorial which should be the entry point for all new users."
msgstr ""

#: ../../docs/about/introduction.rst:91
#, fuzzy
msgid ""
"The :ref:`sec-tutorials` section can be read as needed, in any order. It "
"contains feature-specific tutorials and documentation."
msgstr ""
"את הסעיף :ref:`sec-tutorials`, מצד שני, ניתן לקרוא במקרה הצורך בכל סדר שהוא. "
"הסעיף מכיל הרבה מדריכים ותיעוד למאפיינים מסוימים."

#: ../../docs/about/introduction.rst:93
msgid ""
"The :ref:`sec-devel` section is intended for advanced users and contributors "
"to the engine development, with information on compiling the engine, "
"developing C++ modules or editor plugins."
msgstr ""
"הסעיף :ref:`sec-devel` מיועד למשתמשים מתקדמים ולתורמים לפיתוח המנוע, עם מידע "
"על הידור המנוע, פיתוח מודולי C++‎ או תוספים לעורך."

#: ../../docs/about/introduction.rst:96
msgid ""
"The :ref:`sec-community` section gives information related to contributing "
"to engine development and the life of its community, e.g. how to report "
"bugs, help with the documentation, etc. It also points to various community "
"channels like IRC and Discord and contains a list of recommended third-party "
"tutorials outside of this documentation."
msgstr ""

#: ../../docs/about/introduction.rst:101
msgid ""
"Finally, the :ref:`sec-class-ref` is the documentation of the Godot API, "
"which is also available directly within the engine's script editor. It is "
"generated automatically from a file in the main source repository, therefore "
"the generated files of the documentation are not meant to be modified. See :"
"ref:`doc_updating_the_class_reference` for details."
msgstr ""

#: ../../docs/about/introduction.rst:107
msgid ""
"In addition to this documentation you may also want to take a look at the "
"various `Godot demo projects <https://github.com/godotengine/godot-demo-"
"projects>`_."
msgstr ""

#: ../../docs/about/introduction.rst:110
msgid "Have fun reading and making games with Godot Engine!"
msgstr "תהנו לקרוא וליצור משחקים עם המנוע גודוט!"

#: ../../docs/about/faq.rst:1
msgid "FAQ"
msgstr ""

#: ../../docs/about/faq.rst:7
#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:42
msgid "Frequently asked questions"
msgstr "שאלות נפוצות"

#: ../../docs/about/faq.rst:10
msgid ""
"What can I do with Godot? How much does it cost? What are the license terms?"
msgstr "מה אפשר לעשות עם גודוט? כמה הוא עולה? מה התנאים של הרישיון?"

#: ../../docs/about/faq.rst:12
#, fuzzy
msgid ""
"Godot is `Free and Open-Source Software <https://en.wikipedia.org/wiki/"
"Free_and_open-source_software>`_ available under the `OSI-approved <https://"
"opensource.org/licenses/MIT>`_ MIT license. This means it is free as in "
"\"free speech\" as well as in \"free beer.\""
msgstr ""
"גודוט הוא תוכנה חינמי/חופשי קוד-פתוח תחת רישיון MIT מאושר 'על ידי OSI "
"<https://opensource.org/licenses/MIT>`_."

#: ../../docs/about/faq.rst:14
msgid "In short:"
msgstr "בקצרה:"

#: ../../docs/about/faq.rst:16
msgid ""
"You are free to download and use Godot for any purpose, personal, non-"
"profit, commercial, or otherwise."
msgstr ""

#: ../../docs/about/faq.rst:17
#, fuzzy
msgid ""
"You are free to modify, distribute, redistribute, and remix Godot to your "
"heart's content, for any reason, both non-commercially and commercially."
msgstr "אתה יכול לשנות, להפיץ, ולערוך מחדש את גודוט לעומק ליבך"

#: ../../docs/about/faq.rst:19
#, fuzzy
msgid ""
"All the contents of this accompanying documentation are published under the "
"permissive Creative Commons Attribution 3.0 (`CC-BY 3.0 <https://"
"creativecommons.org/licenses/by/3.0/>`_) license, with attribution to \"Juan "
"Linietsky, Ariel Manzur and the Godot Engine community.\""
msgstr ""
"כל התוכן בתיעוד הזה תחת רישיון reative Commons Attribution 3.0 (`CC-BY 3.0 "
"<https://creativecommons.org/licenses/by/3.0/>`_) וביחוס ל\"Juan Linietsky, "
"Ariel Manzur and the Godot Engine community\"."

#: ../../docs/about/faq.rst:23
msgid ""
"Logos and icons are generally under the same Creative Commons license. Note "
"that some third-party libraries included with Godot's source code may have "
"different licenses."
msgstr ""
"לוֹגוֹ והסמלים הם תחת אותו רישיון Creative Commons. שים לב שחלק מהספריות צד "
"שלישי שנמצאים כחלק מהקוד מקור של גודוט אולי בעלי רישיונות שונים."

#: ../../docs/about/faq.rst:27
msgid ""
"For full details, look at the `COPYRIGHT.txt <https://github.com/godotengine/"
"godot/blob/master/COPYRIGHT.txt>`_ as well as the `LICENSE.txt <https://"
"github.com/godotengine/godot/blob/master/LICENSE.txt>`_ and `LOGO_LICENSE."
"txt <https://github.com/godotengine/godot/blob/master/LOGO_LICENSE.md>`_ "
"files in the Godot repository."
msgstr ""
"למידע מלא, הסתכל בקבצים `COPYRIGHT.txt <https://github.com/godotengine/godot/"
"blob/master/COPYRIGHT.txt>`_ וכמו כן ב `LICENSE.txt <https://github.com/"
"godotengine/godot/blob/master/LICENSE.txt>`_ ו- `LOGO_LICENSE.txt <https://"
"github.com/godotengine/godot/blob/master/LOGO_LICENSE.md>`_ במאגר של גודוט."

#: ../../docs/about/faq.rst:31
#, fuzzy
msgid ""
"Also, see `the license page on the Godot website <https://godotengine.org/"
"license>`_."
msgstr "ראה גם  `את דף הרישיון באתר גודוט <https://godotengine.org/license>`_."

#: ../../docs/about/faq.rst:34
msgid "Which platforms are supported by Godot?"
msgstr "איזה פלטפורמות נתמכות על ידי גודוט?"

#: ../../docs/about/faq.rst:36
msgid "**For the editor:**"
msgstr "**בשביל העורך:**"

#: ../../docs/about/faq.rst:38 ../../docs/tutorials/misc/jitter_stutter.rst:59
#: ../../docs/development/compiling/compiling_with_mono.rst:334
msgid "Windows"
msgstr "וינדוס (Windows)"

#: ../../docs/about/faq.rst:39 ../../docs/about/faq.rst:45
#: ../../docs/getting_started/editor/default_key_mapping.rst:24
#: ../../docs/getting_started/editor/default_key_mapping.rst:89
#: ../../docs/getting_started/editor/default_key_mapping.rst:142
#: ../../docs/getting_started/editor/default_key_mapping.rst:217
#: ../../docs/getting_started/editor/default_key_mapping.rst:298
#: ../../docs/getting_started/editor/default_key_mapping.rst:345
#: ../../docs/getting_started/editor/default_key_mapping.rst:370
#: ../../docs/getting_started/editor/default_key_mapping.rst:381
#: ../../docs/getting_started/editor/default_key_mapping.rst:394
#: ../../docs/getting_started/editor/default_key_mapping.rst:425
#: ../../docs/getting_started/editor/default_key_mapping.rst:438
#: ../../docs/getting_started/editor/default_key_mapping.rst:461
#: ../../docs/getting_started/editor/default_key_mapping.rst:478
#: ../../docs/getting_started/editor/default_key_mapping.rst:513
#: ../../docs/tutorials/misc/jitter_stutter.rst:84
msgid "macOS"
msgstr ""

#: ../../docs/about/faq.rst:40 ../../docs/about/faq.rst:46
msgid "X11 (Linux, \\*BSD)"
msgstr "X11 (לינוקס, ‎\\*BSD)"

#: ../../docs/about/faq.rst:42
msgid "**For exporting your games:**"
msgstr "** בשביל היצוא של המשחקים שלך:**"

#: ../../docs/about/faq.rst:44
msgid "Windows (and UWP)"
msgstr "וינדוס ( וגם UWP)"

#: ../../docs/about/faq.rst:47
#: ../../docs/getting_started/step_by_step/exporting.rst:310
#: ../../docs/tutorials/misc/jitter_stutter.rst:90
#: ../../docs/development/compiling/compiling_with_mono.rst:326
msgid "Android"
msgstr "Android"

#: ../../docs/about/faq.rst:48
#: ../../docs/getting_started/step_by_step/exporting.rst:363
#: ../../docs/tutorials/misc/jitter_stutter.rst:96
#: ../../docs/development/compiling/compiling_with_mono.rst:328
msgid "iOS"
msgstr "iOS"

#: ../../docs/about/faq.rst:49
msgid "Web"
msgstr "אתר אינטרנט"

#: ../../docs/about/faq.rst:51
#, fuzzy
msgid ""
"Both 32- and 64-bit binaries are supported where it makes sense, with 64 "
"being the default."
msgstr ""
"ישנה תמיכה גם בקבצים בינריים של 32 וגם של 64 סיביות איפה שמצב זה הגיוני, "
"כאשר בררת המחדל היא 64."

#: ../../docs/about/faq.rst:54
msgid ""
"Some users also report building and using Godot successfully on ARM-based "
"systems with Linux, like the Raspberry Pi."
msgstr ""
"חלק מהמשתמשים דיווחו שהם גם הצליחו להשתמש ב־Godot על מערכות המובססות על "
"ארכיטקטורת ARM, כגון Raspberry Pi בעזרת לינוקס."

#: ../../docs/about/faq.rst:57
msgid ""
"Additionally, there is some unofficial third-party work being done on "
"building for some consoles. However, none of this is included in the default "
"build scripts or export templates at this time."
msgstr ""
"בנוסף על כך, ישנם כמה ישומיי צד שלישי לא רשמיים המסוגלים לבנות לחלק "
"מהקונסולות. למרות זאת, ישומיים אלו לא כלולים בסקריפטי הבנייה ובתבניות הייצוא "
"הרשמיים."

#: ../../docs/about/faq.rst:61
msgid ""
"For more on this, see the sections on :ref:`exporting <toc-learn-workflow-"
"export>` and :ref:`compiling Godot yourself <toc-devel-compiling>`."
msgstr ""
"לקבלת מידע נוסף, ראו פרק על `<ref:`exporting <toc-learn-workflow-export: וגם "
"פרק על `<ref:`compiling Godot yourself<toc-devel-compiling: ."

#: ../../docs/about/faq.rst:65
msgid "Which programming languages are supported in Godot?"
msgstr "אילו שפות תכנות נתמכות ב־Godot?"

#: ../../docs/about/faq.rst:67
msgid ""
"The officially supported languages for Godot are GDScript, Visual Scripting, "
"C#, and C++. See the subcategories for each language in the :ref:`scripting "
"<toc-learn-scripting>` section."
msgstr ""
"השפות הרשמיות הנתמכות בגודוט הם: C#, GDScript, סקריפטינג חזותי ו++C. ראו את "
"הקטגוריות משנה לכל שפה בפרק '<ref:`scripting <toc-learn-scripting: ."

#: ../../docs/about/faq.rst:71
msgid ""
"If you are just starting out with either Godot or game development in "
"general, GDScript is the recommended language to learn and use since it is "
"native to Godot. While scripting languages tend to be less performant than "
"lower-level languages in the long run, for prototyping, developing Minimum "
"Viable Products (MVPs), and focusing on Time-To-Market (TTM), GDScript will "
"provide a fast, friendly, and capable way of developing your games."
msgstr ""
"אם הינכם רק מתחילים עם גודוט או עם פיתוח משחקים בכללי, GDscript היא השפה "
"המומלצת ללמידה שכן היא שפה שנבנתה על גבי המנוע והיא מותאמת לו. בזמן ששפות "
"סקריפטיות נוטות להיות בעלות ביצועים נחותים יותר משפות עיליות או שפות low-"
"level בטווח הארוך; GDscript יספק דרך מהירה, ידידותית, ובעלת יכולות גבוהות "
"בשביל יצירת אב-טיפוס, בשביל יצירת מוצרי בר-קיימא מינימליים ובשביל יצירת "
"מוצרים שניתן למסחר במהרה."

#: ../../docs/about/faq.rst:78
msgid ""
"Note that C# support is still relatively new, and as such, you may encounter "
"some issues along the way. Our friendly and hard-working development "
"community is always ready to tackle new problems as they arise, but since "
"this is an open-source project, we recommend that you first do some due "
"diligence yourself. Searching through discussions on `open issues <https://"
"github.com/godotengine/godot/issues>`_ is a great way to start your "
"troubleshooting."
msgstr ""
"נא לשים לב כי התמיכה ב־C#‎ עדיין חדשה יחסית, על כן, יתכן ותצוצנה בעיות במהלך "
"העבודה. קהילת המתכנתים הידידותיים שלנו עמלה רבות והיא תמיד מוכנה להתמודד עם "
"בעיות חדשות, אך כיוון שמיזם זה הוא מיזם קוד פתוח, נמליץ לך תחילה לוודא "
"שביצעת הכול כשורה לפני הכול. דרך טובה להתחיל את תהליך פתרון התקלות היא לחפש "
"בדיונים תחת `<נושאים פתוחים <https://github.com/godotengine/godot/issues` ."

#: ../../docs/about/faq.rst:85
msgid ""
"As for new languages, support is possible via third parties using the "
"GDNative / NativeScript / PluginScript facilities. (See the question about "
"plugins below.) Work is currently underway, for example, on unofficial "
"bindings for Godot to `Python <https://github.com/touilleMan/godot-python>`_ "
"and `Nim <https://github.com/pragmagic/godot-nim>`_."
msgstr ""
"לשפות חדשות, תיתכן תמיכה דרך צדדים שלישיים בעזרת GDNative / NativeScript / "
"PluginScript. כרגע העבודה נמצאת בעיצומה על יצירת איגודים לא רשמיים לגודו, "
"לדוגמה:\n"
"`<Python <https://github.com/touilleMan/godot-python>` וגם `<Nim <https://"
"github.com/pragmagic/godot-nim` ."

#: ../../docs/about/faq.rst:93
msgid "What is GDScript and why should I use it?"
msgstr "מה הוא GDScript ומדוע עלי להשתמש בו?"

#: ../../docs/about/faq.rst:95
msgid ""
"GDScript is Godot's integrated scripting language. It was built from the "
"ground up to maximize Godot's potential in the least amount of code, "
"affording both novice and expert developers alike to capitalize on Godot's "
"strengths as fast as possible. If you've ever written anything in a language "
"like Python before then you'll feel right at home. For examples, history, "
"and a complete overview of the power GDScript offers you, check out the :ref:"
"`GDScript scripting guide <doc_gdscript>`."
msgstr ""

#: ../../docs/about/faq.rst:102
msgid ""
"There are several reasons to use GDScript--especially when you are "
"prototyping, in alpha/beta stages of your project, or are not creating the "
"next AAA title--but the most salient reason is the overall **reduction of "
"complexity.**"
msgstr ""

#: ../../docs/about/faq.rst:106
msgid ""
"The original intent of creating a tightly integrated, custom scripting "
"language for Godot was two-fold: first, it reduces the amount of time "
"necessary to get up and running with Godot, giving developers a rapid way of "
"exposing themselves to the engine with a focus on productivity; second, it "
"reduces the overall burden of maintenance, attenuates the dimensionality of "
"issues, and allows the developers of the engine to focus on squashing bugs "
"and improving features related to the engine core--rather than spending a "
"lot of time trying to get a small set of incremental features working across "
"a large set of languages."
msgstr ""

#: ../../docs/about/faq.rst:114
msgid ""
"Since Godot is an open-source project, it was imperative from the start to "
"prioritize a more integrated and seamless experience over attracting "
"additional users by supporting more familiar programming languages--"
"especially when supporting those more familiar languages would result in a "
"worse experience. We understand if you would rather use another language in "
"Godot (see the list of supported options above). That being said, if you "
"haven't given GDScript a try, try it for **three days**. Just like Godot, "
"once you see how powerful it is and rapid your development becomes, we think "
"GDScript will grow on you."
msgstr ""

#: ../../docs/about/faq.rst:123
msgid ""
"More information about getting comfortable with GDScript or dynamically "
"typed languages can be found in the :ref:`doc_gdscript_more_efficiently` "
"tutorial."
msgstr ""

#: ../../docs/about/faq.rst:127
msgid "What were the motivations behind creating GDScript?"
msgstr "מה היו המניעים ליצירת GDScript?"

#: ../../docs/about/faq.rst:129
msgid ""
"In the early days, the engine used the `Lua <https://www.lua.org>`__ "
"scripting language. Lua is fast, but creating bindings to an object oriented "
"system (by using fallbacks) was complex and slow and took an enormous amount "
"of code. After some experiments with `Python <https://www.python.org>`__, it "
"also proved difficult to embed."
msgstr ""

#: ../../docs/about/faq.rst:135
msgid ""
"The main reasons for creating a custom scripting language for Godot were:"
msgstr "הסיבות הראשיות ליצירת שפת סקריפטינג המותאמת אישית לגודוט:"

#: ../../docs/about/faq.rst:137
msgid ""
"Poor threading support in most script VMs, and Godot uses threads (Lua, "
"Python, Squirrel, JavaScript, ActionScript, etc.)."
msgstr ""

#: ../../docs/about/faq.rst:139
msgid ""
"Poor class-extending support in most script VMs, and adapting to the way "
"Godot works is highly inefficient (Lua, Python, JavaScript)."
msgstr ""

#: ../../docs/about/faq.rst:141
msgid ""
"Many existing languages have horrible interfaces for binding to C++, "
"resulting in large amount of code, bugs, bottlenecks, and general "
"inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on "
"a great engine, not a great amount of integrations."
msgstr ""

#: ../../docs/about/faq.rst:144
msgid ""
"No native vector types (vector3, matrix4, etc.), resulting in highly reduced "
"performance when using custom types (Lua, Python, Squirrel, JavaScript, "
"ActionScript, etc.)."
msgstr ""

#: ../../docs/about/faq.rst:147
msgid ""
"Garbage collector results in stalls or unnecessarily large memory usage "
"(Lua, Python, JavaScript, ActionScript, etc.)."
msgstr ""

#: ../../docs/about/faq.rst:149
msgid ""
"Difficulty to integrate with the code editor for providing code completion, "
"live editing, etc. (all of them). This is well-supported by GDScript."
msgstr ""

#: ../../docs/about/faq.rst:153
msgid "GDScript was designed to curtail the issues above, and more."
msgstr ""

#: ../../docs/about/faq.rst:156
msgid "What type of 3D model formats does Godot support?"
msgstr ""

#: ../../docs/about/faq.rst:158
msgid ""
"Godot supports Collada via the `OpenCollada <https://github.com/KhronosGroup/"
"OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_ exporter (Maya, 3DSMax). If you are "
"using Blender, take a look at our own `Better Collada Exporter <https://"
"godotengine.org/download>`_."
msgstr ""

#: ../../docs/about/faq.rst:161
msgid "As of Godot 3.0, glTF is supported."
msgstr ""

#: ../../docs/about/faq.rst:163
msgid ""
"FBX is supported via the Open Asset Import library. However, FBX is "
"proprietary so we recommend using other formats listed above, if suitable "
"for your workflow."
msgstr ""

#: ../../docs/about/faq.rst:167
msgid ""
"Will [insert closed SDK such as FMOD, GameWorks, etc.] be supported in Godot?"
msgstr ""

#: ../../docs/about/faq.rst:169
msgid ""
"The aim of Godot is to create a free and open-source MIT-licensed engine "
"that is modular and extendable. There are no plans for the core engine "
"development community to support any third-party, closed-source/proprietary "
"SDKs, as integrating with these would go against Godot's ethos."
msgstr ""

#: ../../docs/about/faq.rst:174
msgid ""
"That said, because Godot is open-source and modular, nothing prevents you or "
"anyone else interested in adding those libraries as a module and shipping "
"your game with them--as either open- or closed-source."
msgstr ""

#: ../../docs/about/faq.rst:178
msgid ""
"To see how support for your SDK of choice could still be provided, look at "
"the Plugins question below."
msgstr ""

#: ../../docs/about/faq.rst:181
msgid ""
"If you know of a third-party SDK that is not supported by Godot but that "
"offers free and open-source integration, consider starting the integration "
"work yourself. Godot is not owned by one person; it belongs to the "
"community, and it grows along with ambitious community contributors like you."
msgstr ""

#: ../../docs/about/faq.rst:187
msgid ""
"How should assets be created to handle multiple resolutions and aspect "
"ratios?"
msgstr ""

#: ../../docs/about/faq.rst:189
msgid ""
"This question pops up often and it's probably thanks to the misunderstanding "
"created by Apple when they originally doubled the resolution of their "
"devices. It made people think that having the same assets in different "
"resolutions was a good idea, so many continued towards that path. That "
"originally worked to a point and only for Apple devices, but then several "
"Android and Apple devices with different resolutions and aspect ratios were "
"created, with a very wide range of sizes and DPIs."
msgstr ""

#: ../../docs/about/faq.rst:197
msgid ""
"The most common and proper way to achieve this is to, instead, use a single "
"base resolution for the game and only handle different screen aspect ratios. "
"This is mostly needed for 2D, as in 3D it's just a matter of Camera XFov or "
"YFov."
msgstr ""

#: ../../docs/about/faq.rst:201
msgid ""
"Choose a single base resolution for your game. Even if there are devices "
"that go up to 2K and devices that go down to 400p, regular hardware scaling "
"in your device will take care of this at little or no performance cost. Most "
"common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in "
"mind the higher the resolution, the larger your assets, the more memory they "
"will take and the longer the time it will take for loading."
msgstr ""

#: ../../docs/about/faq.rst:209
msgid ""
"Use the stretch options in Godot; 2D stretching while keeping aspect ratios "
"works best. Check the :ref:`doc_multiple_resolutions` tutorial on how to "
"achieve this."
msgstr ""

#: ../../docs/about/faq.rst:213
msgid ""
"Determine a minimum resolution and then decide if you want your game to "
"stretch vertically or horizontally for different aspect ratios, or if there "
"is one aspect ratio and you want black bars to appear instead. This is also "
"explained in :ref:`doc_multiple_resolutions`."
msgstr ""

#: ../../docs/about/faq.rst:218
msgid ""
"For user interfaces, use the :ref:`anchoring <doc_size_and_anchors>` to "
"determine where controls should stay and move. If UIs are more complex, "
"consider learning about Containers."
msgstr ""

#: ../../docs/about/faq.rst:222
msgid "And that's it! Your game should work in multiple resolutions."
msgstr ""

#: ../../docs/about/faq.rst:224
msgid ""
"If there is a desire to make your game also work on ancient devices with "
"tiny screens (fewer than 300 pixels in width), you can use the export option "
"to shrink images, and set that build to be used for certain screen sizes in "
"the App Store or Google Play."
msgstr ""

#: ../../docs/about/faq.rst:230
msgid "How can I extend Godot?"
msgstr ""

#: ../../docs/about/faq.rst:232
msgid ""
"For extending Godot, like creating Godot Editor plugins or adding support "
"for additional languages, take a look at :ref:`EditorPlugins "
"<doc_making_plugins>` and tool scripts."
msgstr ""

#: ../../docs/about/faq.rst:236
msgid "Also, see the official blog posts on these topics:"
msgstr ""

#: ../../docs/about/faq.rst:238
msgid ""
"`A look at the GDNative architecture <https://godotengine.org/article/look-"
"gdnative-architecture>`_"
msgstr ""

#: ../../docs/about/faq.rst:239
msgid "`GDNative is here! <https://godotengine.org/article/dlscript-here>`_"
msgstr ""

#: ../../docs/about/faq.rst:241
msgid ""
"You can also take a look at the GDScript implementation, the Godot modules, "
"as well as the `unofficial Python support <https://github.com/touilleMan/"
"godot-python>`_ for Godot. This would be a good starting point to see how "
"another third-party library integrates with Godot."
msgstr ""

#: ../../docs/about/faq.rst:247
msgid "I would like to contribute! How can I get started?"
msgstr ""

#: ../../docs/about/faq.rst:249
msgid ""
"Awesome! As an open-source project, Godot thrives off of the innovation and "
"ambition of developers like you."
msgstr ""

#: ../../docs/about/faq.rst:252
msgid ""
"The first place to get started is in the `issues <https://github.com/"
"godotengine/godot/issues>`_. Find an issue that resonates with you, then "
"proceed to the `How to Contribute <https://github.com/godotengine/godot/blob/"
"master/CONTRIBUTING.md#contributing-pull-requests>`_ guide to learn how to "
"fork, modify, and submit a Pull Request (PR) with your changes."
msgstr ""

#: ../../docs/about/faq.rst:257
msgid "I have a great idea for Godot. How can I share it?"
msgstr ""

#: ../../docs/about/faq.rst:259
msgid ""
"It might be tempting to want to bring ideas to Godot, like ones that result "
"in massive core changes, some sort of mimicry of what another game engine "
"does, or alternative workflows that you'd like built into the editor. These "
"are great, and we are thankful to have such motivated people want to "
"contribute, but Godot's focus is and always will be the core functionality "
"as outlined in the `Roadmap <https://github.com/godotengine/godot-roadmap/"
"blob/master/ROADMAP.md>`_, `squashing bugs and addressing issues <https://"
"github.com/godotengine/godot/issues>`_, and conversations between Godot "
"community members."
msgstr ""

#: ../../docs/about/faq.rst:268
msgid ""
"Most developers in the Godot community will be more interested to learn "
"about things like:"
msgstr ""

#: ../../docs/about/faq.rst:271
msgid ""
"Your experience using the software and the problems you have (we care about "
"this much more than ideas on how to improve it)."
msgstr ""

#: ../../docs/about/faq.rst:273
msgid ""
"The features you would like to see implemented because you need them for "
"your project."
msgstr ""

#: ../../docs/about/faq.rst:275
msgid ""
"The concepts that were difficult to understand while learning the software."
msgstr ""

#: ../../docs/about/faq.rst:276
msgid "The parts of your workflow you would like to see optimized."
msgstr ""

#: ../../docs/about/faq.rst:277
msgid ""
"Parts where you missed clear tutorials or where the documentation wasn't "
"clear."
msgstr ""

#: ../../docs/about/faq.rst:279
msgid ""
"Please don't feel like your ideas for Godot are unwelcome. Instead, try to "
"reformulate them as a problem first, so developers and the community have a "
"functional foundation to ground your ideas on."
msgstr ""

#: ../../docs/about/faq.rst:283
msgid ""
"A good way to approach sharing your ideas and problems with the community is "
"as a set of user stories. Explain what you are trying to do, what behavior "
"you expect to happen, and then what behavior actually happened. Framing "
"problems and ideas this way will help the whole community stay focused on "
"improving developer experiences as a whole."
msgstr ""

#: ../../docs/about/faq.rst:289
msgid ""
"Bonus points for bringing screenshots, concrete numbers, test cases, or "
"example projects (if applicable)."
msgstr ""

#: ../../docs/about/faq.rst:294
msgid "Why does Godot not use STL (Standard Template Library)"
msgstr ""

#: ../../docs/about/faq.rst:296
msgid ""
"Like many other libraries (Qt as an example), Godot does not make use of "
"STL. We believe STL is a great general purpose library, but we had special "
"requirements for Godot."
msgstr ""

#: ../../docs/about/faq.rst:300
msgid ""
"STL templates create very large symbols, which results in huge debug "
"binaries. We use few templates with very short names instead."
msgstr ""

#: ../../docs/about/faq.rst:301
msgid ""
"Most of our containers cater to special needs, like Vector, which uses copy "
"on write and we use to pass data around, or the RID system, which requires "
"O(1) access time for performance. Likewise, our hash map implementations are "
"designed to integrate seamlessly with internal engine types."
msgstr ""

#: ../../docs/about/faq.rst:302
msgid ""
"Our containers have memory tracking built-in, which helps better track "
"memory usage."
msgstr ""

#: ../../docs/about/faq.rst:303
msgid ""
"For large arrays, we use pooled memory, which can be mapped to either a "
"preallocated buffer or virtual memory."
msgstr ""

#: ../../docs/about/faq.rst:304
msgid ""
"We use our custom String type, as the one provided by STL is too basic and "
"lacks proper internationalization support."
msgstr ""

#: ../../docs/about/faq.rst:307
msgid "Why does Godot not use exceptions?"
msgstr ""

#: ../../docs/about/faq.rst:309
msgid ""
"We believe games should not crash, no matter what. If an unexpected "
"situation happens, Godot will print an error (which can be traced even to "
"script), but then it will try to recover as gracefully as possible and keep "
"going."
msgstr ""

#: ../../docs/about/faq.rst:314
msgid ""
"Additionally, exceptions significantly increase binary size for the "
"executable."
msgstr ""

#: ../../docs/about/faq.rst:318
msgid "Why does Godot not enforce RTTI?"
msgstr ""

#: ../../docs/about/faq.rst:320
msgid ""
"Godot provides its own type-casting system, which can optionally use RTTI "
"internally. Disabling RTTI in Godot means considerably smaller binary sizes "
"can be achieved, at a little performance cost."
msgstr ""

#: ../../docs/about/faq.rst:325
msgid "Why does Godot not force users to implement DoD (Data oriented Design)?"
msgstr ""

#: ../../docs/about/faq.rst:327
msgid ""
"While Godot internally for a lot of the heavy performance tasks attempts to "
"use cache coherency as well as possible, we believe most users don't really "
"need to be forced to use DoD practices."
msgstr ""

#: ../../docs/about/faq.rst:331
msgid ""
"DoD is mostly a cache coherency optimization that can only gain you "
"significant performance improvements when dealing with dozens of thousands "
"of objects (which are processed every frame with little modification). As "
"in, if you are moving a few hundred sprites or enemies per frame, DoD won't "
"help you, and you should consider a different approach to optimization."
msgstr ""

#: ../../docs/about/faq.rst:338
msgid ""
"The vast majority of games do not need this and Godot provides handy helpers "
"to do the job for most cases when you do."
msgstr ""

#: ../../docs/about/faq.rst:341
msgid ""
"If a game that really needs to process such large amount of objects is "
"needed, our recommendation is to use C++ and GDNative for the high "
"performance parts and GDScript (or C#) for the rest of the game."
msgstr ""

#: ../../docs/about/faq.rst:346
msgid "How can I support Godot development or contribute?"
msgstr ""

#: ../../docs/about/faq.rst:348
msgid "See :ref:`doc_ways_to_contribute`."
msgstr ""

#: ../../docs/about/faq.rst:351
msgid "Who is working on Godot? How can I contact you?"
msgstr ""

#: ../../docs/about/faq.rst:353
msgid ""
"See the corresponding page on the `Godot website <https://godotengine.org/"
"contact>`_."
msgstr ""

#: ../../docs/about/docs_changelog.rst:4
msgid "Documentation changelog"
msgstr ""

#: ../../docs/about/docs_changelog.rst:6
msgid ""
"The documentation is continually being improved. The release of version 3.2 "
"includes many new tutorials, many fixes and updates for old tutorials, and "
"many updates to the :ref:`class reference <toc-class-ref>`. Below is a list "
"of new tutorials added since version 3.1."
msgstr ""

#: ../../docs/about/docs_changelog.rst:11
msgid ""
"This document only contains new tutorials so not all changes are reflected, "
"many tutorials have been substantially updated but are not reflected in this "
"document."
msgstr ""

#: ../../docs/about/docs_changelog.rst:15
msgid "New tutorials since version 3.1"
msgstr ""

#: ../../docs/about/docs_changelog.rst:18
#: ../../docs/about/docs_changelog.rst:118
#: ../../docs/getting_started/workflow/index.rst:2
msgid "Project workflow"
msgstr ""

#: ../../docs/about/docs_changelog.rst:20
msgid ":ref:`doc_android_custom_build`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:23
#: ../../docs/about/docs_changelog.rst:134 ../../docs/tutorials/2d/index.rst:2
msgid "2D"
msgstr ""

#: ../../docs/about/docs_changelog.rst:25
#, fuzzy
msgid ":ref:`doc_2d_sprite_animation`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:28
#: ../../docs/tutorials/audio/index.rst:2
msgid "Audio"
msgstr "שמע"

#: ../../docs/about/docs_changelog.rst:30
#, fuzzy
msgid ":ref:`doc_recording_with_microphone`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:31
#, fuzzy
msgid ":ref:`doc_sync_with_audio`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:34 ../../docs/tutorials/math/index.rst:2
msgid "Math"
msgstr ""

#: ../../docs/about/docs_changelog.rst:36
#, fuzzy
msgid ":ref:`doc_beziers_and_curves`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:37
#, fuzzy
msgid ":ref:`doc_interpolation`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:40
#: ../../docs/tutorials/inputs/index.rst:2
msgid "Inputs"
msgstr ""

#: ../../docs/about/docs_changelog.rst:42
#, fuzzy
msgid ":ref:`doc_input_examples`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:45 ../../docs/tutorials/i18n/index.rst:2
msgid "Internationalization"
msgstr ""

#: ../../docs/about/docs_changelog.rst:47
msgid ":ref:`doc_localization_using_gettext`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:50
#: ../../docs/about/docs_changelog.rst:170
#: ../../docs/tutorials/shading/index.rst:2
msgid "Shading"
msgstr ""

#: ../../docs/about/docs_changelog.rst:55
msgid "Your First Shader Series:"
msgstr ""

#: ../../docs/about/docs_changelog.rst:53
msgid ":ref:`doc_what_are_shaders`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:54
msgid ":ref:`doc_your_first_canvasitem_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:55
msgid ":ref:`doc_your_first_spatial_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:56
msgid ":ref:`doc_your_second_spatial_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:57
#, fuzzy
msgid ":ref:`doc_visual_shaders`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:60
#: ../../docs/tutorials/networking/index.rst:2
msgid "Networking"
msgstr ""

#: ../../docs/about/docs_changelog.rst:62
#, fuzzy
msgid ":ref:`doc_webrtc`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:65 ../../docs/tutorials/vr/index.rst:2
msgid "VR"
msgstr ""

#: ../../docs/about/docs_changelog.rst:67
#, fuzzy
msgid ":ref:`doc_vr_starter_tutorial_part_one`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:68
#, fuzzy
msgid ":ref:`doc_vr_starter_tutorial_part_two`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:71
#: ../../docs/about/docs_changelog.rst:185
#: ../../docs/tutorials/plugins/index.rst:2
msgid "Plugins"
msgstr ""

#: ../../docs/about/docs_changelog.rst:73
#, fuzzy
msgid ":ref:`doc_android_plugin`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:74
#, fuzzy
msgid ":ref:`doc_inspector_plugins`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:75
#, fuzzy
msgid ":ref:`doc_visual_shader_plugins`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:78
#: ../../docs/about/docs_changelog.rst:196
#: ../../docs/tutorials/threads/index.rst:2
msgid "Multi-threading"
msgstr ""

#: ../../docs/about/docs_changelog.rst:80
#, fuzzy
msgid ":ref:`doc_using_multiple_threads`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:83
#: ../../docs/about/docs_changelog.rst:201
#: ../../docs/tutorials/content/index.rst:2
#, fuzzy
msgid "Creating content"
msgstr "יצירת תוכן"

#: ../../docs/about/docs_changelog.rst:90
msgid "Procedural geometry series:"
msgstr ""

#: ../../docs/about/docs_changelog.rst:86
msgid ":ref:`Procedural geometry <toc-procedural_geometry>`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:87
#, fuzzy
msgid ":ref:`doc_arraymesh`"
msgstr "Android"

#: ../../docs/about/docs_changelog.rst:88
#, fuzzy
msgid ":ref:`doc_surfacetool`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:89
#, fuzzy
msgid ":ref:`doc_meshdatatool`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:90
#, fuzzy
msgid ":ref:`doc_immediategeometry`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:93
#: ../../docs/tutorials/optimization/index.rst:2
#, fuzzy
msgid "Optimization"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:95
msgid ":ref:`doc_using_multimesh`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:96
msgid ":ref:`doc_using_servers`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:99
#: ../../docs/tutorials/legal/index.rst:2
msgid "Legal"
msgstr ""

#: ../../docs/about/docs_changelog.rst:101
msgid ":ref:`doc_complying_with_licenses`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:104
msgid "New tutorials since version 3.0"
msgstr ""

#: ../../docs/about/docs_changelog.rst:107
#: ../../docs/getting_started/step_by_step/index.rst:2
#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:108
#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:18
msgid "Step by step"
msgstr ""

#: ../../docs/about/docs_changelog.rst:109
msgid ":ref:`doc_signals`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:110
msgid ":ref:`doc_exporting`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:113
#: ../../docs/getting_started/step_by_step/scripting.rst:4
#: ../../docs/getting_started/scripting/index.rst:2
#: ../../docs/tutorials/networking/http_request_class.rst:22
msgid "Scripting"
msgstr ""

#: ../../docs/about/docs_changelog.rst:115
msgid ":ref:`doc_gdscript_static_typing`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:120
msgid "Best Practices:"
msgstr ""

#: ../../docs/about/docs_changelog.rst:122
msgid ":ref:`doc_introduction_best_practices`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:123
msgid ":ref:`doc_what_are_godot_classes`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:124
#, fuzzy
msgid ":ref:`doc_scene_organization`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:125
msgid ":ref:`doc_scenes_versus_scripts`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:126
msgid ":ref:`doc_autoloads_versus_internal_nodes`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:127
msgid ":ref:`doc_node_alternatives`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:128
msgid ":ref:`doc_godot_interfaces`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:129
msgid ":ref:`doc_godot_notifications`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:130
msgid ":ref:`doc_data_preferences`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:131
msgid ":ref:`doc_logic_preferences`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:136
msgid ":ref:`doc_2d_lights_and_shadows`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:137
msgid ":ref:`doc_2d_meshes`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:140 ../../docs/tutorials/3d/index.rst:2
msgid "3D"
msgstr ""

#: ../../docs/about/docs_changelog.rst:142
msgid ":ref:`doc_csg_tools`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:143
msgid ":ref:`doc_animating_thousands_of_fish`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:144
msgid ":ref:`doc_controlling_thousands_of_fish`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:147
#: ../../docs/tutorials/physics/index.rst:2
msgid "Physics"
msgstr ""

#: ../../docs/about/docs_changelog.rst:149
msgid ":ref:`doc_ragdoll_system`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:150
msgid ":ref:`doc_soft_body`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:153
#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:2
#: ../../docs/tutorials/animation/index.rst:2
#: ../../docs/development/file_formats/tscn.rst:375
msgid "Animation"
msgstr ""

#: ../../docs/about/docs_changelog.rst:155
msgid ":ref:`doc_2d_skeletons`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:156
msgid ":ref:`doc_animation_tree`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:159 ../../docs/tutorials/gui/index.rst:2
msgid "GUI"
msgstr ""

#: ../../docs/about/docs_changelog.rst:161
msgid ":ref:`doc_gui_containers`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:164
#: ../../docs/tutorials/viewports/index.rst:2
#: ../../docs/tutorials/viewports/viewports.rst:4
msgid "Viewports"
msgstr ""

#: ../../docs/about/docs_changelog.rst:166
msgid ":ref:`doc_viewport_as_texture`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:167
msgid ":ref:`doc_custom_postprocessing`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:172
msgid ":ref:`doc_intro_to_shaders_water_workshop`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:173
msgid ":ref:`doc_migrating_to_godot_shader_language`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:174
msgid ":ref:`doc_advanced_postprocessing`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:176
msgid "Shading Reference:"
msgstr ""

#: ../../docs/about/docs_changelog.rst:178
msgid ":ref:`doc_shaders`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:179
msgid ":ref:`doc_shading_language`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:180
msgid ":ref:`doc_spatial_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:181
msgid ":ref:`doc_canvas_item_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:182
msgid ":ref:`doc_particle_shader`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:187
#, fuzzy
msgid ":ref:`doc_making_main_screen_plugins`"
msgstr "אנימציות"

#: ../../docs/about/docs_changelog.rst:188
msgid ":ref:`doc_spatial_gizmo_plugins`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:191
#: ../../docs/tutorials/platform/index.rst:2
msgid "Platform-specific"
msgstr ""

#: ../../docs/about/docs_changelog.rst:193
msgid ":ref:`doc_customizing_html5_shell`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:198
msgid ":ref:`doc_thread_safe_apis`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:203
msgid ":ref:`doc_making_trees`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:206
#: ../../docs/tutorials/misc/index.rst:2
msgid "Miscellaneous"
msgstr ""

#: ../../docs/about/docs_changelog.rst:208
msgid ":ref:`doc_jitter_stutter`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:209
msgid ":ref:`doc_running_code_in_the_editor`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:210
msgid ":ref:`doc_change_scenes_manually`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:211
msgid ":ref:`doc_gles2_gles3_differences`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:214
#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:349
#: ../../docs/development/compiling/index.rst:2
#: ../../docs/development/compiling/compiling_for_windows.rst:92
#: ../../docs/development/compiling/compiling_for_x11.rst:89
#: ../../docs/development/compiling/compiling_for_osx.rst:31
#: ../../docs/development/compiling/compiling_for_ios.rst:19
#: ../../docs/development/compiling/compiling_for_uwp.rst:33
msgid "Compiling"
msgstr ""

#: ../../docs/about/docs_changelog.rst:216
msgid ":ref:`doc_optimizing_for_size`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:217
msgid ":ref:`doc_compiling_with_script_encryption_key`"
msgstr ""

#: ../../docs/about/docs_changelog.rst:220
#: ../../docs/development/cpp/index.rst:2
msgid "Engine development"
msgstr ""

#: ../../docs/about/docs_changelog.rst:222
msgid ":ref:`doc_binding_to_external_libraries`"
msgstr ""

#: ../../docs/about/release_policy.rst:4
msgid "Godot release policy"
msgstr ""

#: ../../docs/about/release_policy.rst:7
msgid "Godot versioning"
msgstr ""

#: ../../docs/about/release_policy.rst:9
msgid ""
"Godot uses ``major.minor.patch`` version numbering. However, it does not "
"strictly follow `Semantic Versioning <https://semver.org/>`__. This means "
"that releases considered \"semver-minor\" by that standard (such as 3.1 -> "
"3.2) will most likely introduce breaking changes. Still, there won't be as "
"many breaking changes as a \"semver-major\" version bump such as 3.2 -> 4.0."
msgstr ""

#: ../../docs/about/release_policy.rst:15
msgid ""
"In the interest of stability and usability, patch releases may occasionally "
"introduce small breaking changes as well. When repackaging Godot projects (e."
"g. in a Flatpak), make sure to always use the same patch version as the one "
"used to initially export the project."
msgstr ""

#: ../../docs/about/release_policy.rst:22
msgid ""
"The first release in a major/minor release series doesn't end with a "
"trailing zero. For example, the first release in the 3.2 series is ``3.2``, "
"not ``3.2.0``."
msgstr ""

#: ../../docs/about/release_policy.rst:27
msgid "Release support timeline"
msgstr ""

#: ../../docs/about/release_policy.rst:29
msgid ""
"Godot versions are supported for a certain amount of time. While these "
"durations are not set in stone, here's a table with the expected level of "
"support for each Godot version:"
msgstr ""

#: ../../docs/about/release_policy.rst:34
msgid "**Version**"
msgstr ""

#: ../../docs/about/release_policy.rst:34
msgid "**Release date**"
msgstr ""

#: ../../docs/about/release_policy.rst:34
msgid "**Support level**"
msgstr ""

#: ../../docs/about/release_policy.rst:36
msgid "Godot 4.0"
msgstr ""

#: ../../docs/about/release_policy.rst:36
msgid "~2021 (see below)"
msgstr ""

#: ../../docs/about/release_policy.rst:36
msgid "|unstable| *Current focus of development (unstable).*"
msgstr ""

#: ../../docs/about/release_policy.rst:38
msgid "Godot 3.2"
msgstr ""

#: ../../docs/about/release_policy.rst:38
msgid "January 2020"
msgstr ""

#: ../../docs/about/release_policy.rst:38
msgid ""
"|supported| Backwards-compatible new features (backported from the "
"``master`` branch) as well as bug, security, and platform support fixes."
msgstr ""

#: ../../docs/about/release_policy.rst:41
msgid "Godot 3.1"
msgstr ""

#: ../../docs/about/release_policy.rst:41
msgid "March 2019"
msgstr ""

#: ../../docs/about/release_policy.rst:41
#: ../../docs/about/release_policy.rst:43
#: ../../docs/about/release_policy.rst:45
msgid "|partial| Only critical, security and platform support fixes."
msgstr ""

#: ../../docs/about/release_policy.rst:43
msgid "Godot 3.0"
msgstr ""

#: ../../docs/about/release_policy.rst:43
msgid "January 2018"
msgstr ""

#: ../../docs/about/release_policy.rst:45
msgid "Godot 2.1"
msgstr ""

#: ../../docs/about/release_policy.rst:45
msgid "July 2016"
msgstr ""

#: ../../docs/about/release_policy.rst:47
msgid "Godot 2.0"
msgstr ""

#: ../../docs/about/release_policy.rst:47
msgid "February 2016"
msgstr ""

#: ../../docs/about/release_policy.rst:47
#: ../../docs/about/release_policy.rst:49
#: ../../docs/about/release_policy.rst:51
msgid "|eol| No longer supported."
msgstr ""

#: ../../docs/about/release_policy.rst:49
msgid "Godot 1.1"
msgstr ""

#: ../../docs/about/release_policy.rst:49
msgid "May 2015"
msgstr ""

#: ../../docs/about/release_policy.rst:51
msgid "Godot 1.0"
msgstr ""

#: ../../docs/about/release_policy.rst:51
msgid "December 2014"
msgstr ""

#: ../../docs/about/release_policy.rst:59
msgid ""
"**Legend:** |supported| Full support - |partial| Partial support - |eol| No "
"support (end of life) - |unstable| Development version"
msgstr ""

#: ../../docs/about/release_policy.rst:65
msgid ""
"Pre-release Godot versions aren't intended to be used in production and are "
"provided on a best-effort basis."
msgstr ""

#: ../../docs/about/release_policy.rst:69
msgid "When is the next release out?"
msgstr ""

#: ../../docs/about/release_policy.rst:71
msgid ""
"While Godot contributors aren't working under any deadlines, there's usually "
"a major or minor Godot release made available every year. Following this "
"trend, this means Godot 4.0 will most likely be released in **2021**."
msgstr ""

#: ../../docs/about/release_policy.rst:75
msgid ""
"Patch releases are made available more frequently, typically every 2-6 "
"months while a release is fully supported. Partially supported releases will "
"only have new patch releases once an important security or platform support "
"fix has been merged."
msgstr ""

#: ../../docs/about/release_policy.rst:82
msgid ""
"The `roadmap <https://github.com/godotengine/godot-roadmap>`__ repository "
"documents features that have been agreed upon and may be implemented in "
"future Godot releases."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:4
#, fuzzy
msgid "Introduction to Godot's editor"
msgstr "מבוא"

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:6
msgid ""
"This tutorial will run you through Godot's interface. We're going to look at "
"the **Project Manager, docks, workspaces** and everything you need to know "
"to get started with the engine."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:11
msgid "Project manager"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:13
msgid ""
"When you launch Godot, the first window you'll see is the Project Manager. "
"Since you have no projects there will be a popup asking if you want to open "
"the asset library, just click cancel, we'll look at it later."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:19
msgid ""
"Now you should see the project manager. It lets you create, remove, import "
"or play game projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:24
msgid ""
"In the top-right corner you'll find a drop-down menu to change the editor's "
"language."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:29
msgid ""
"From the **Templates** tab you can download open source project templates "
"and demos from the Asset Library to help you get started faster. Just select "
"the template or demo you want, click download, once it's finished "
"downloading click install and choose where you want the project to go. You "
"can learn more about it in :ref:`doc_what_is_assetlib`."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:38
msgid "Create or import a project"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:40
msgid ""
"To create a new project, click the ``New Project`` button on the right. Here "
"you give it a name, choose an empty folder on your computer to save it to, "
"and choose a renderer."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:46
msgid ""
"Click the Browse button to open Godot's file browser and pick a location or "
"type the folder's path in the Project Path field."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:51
msgid ""
"When you see the green tick on the right, it means the engine detects an "
"empty folder. You can also click the ``Create Folder`` button next to your "
"project name and an empty folder will be created with that name for the "
"project."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:55
msgid ""
"Finally, you need to choose which renderer to use (OpenGL ES 3.0 or OpenGL "
"ES 2.0). The advantages and disadvantages of each are listed to help you "
"choose, and you can refer to :ref:`doc_gles2_gles3_differences` for more "
"details. Note that you can change the backend from the project settings if "
"you change your mind later on. For this tutorial either backend is fine."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:61
msgid ""
"Once you are done click ``Create & Edit``. Godot will create the project for "
"you and open it in the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:64
msgid ""
"The next time you open the project manager, you'll see your new project in "
"the list. Double click on it to open it in the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:69
msgid ""
"You can import existing projects in a similar way, using the Import button. "
"Locate the folder that contains the project or the ``project.godot`` file to "
"import and edit it."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:75
msgid "When the folder path is correct, you'll see a green checkmark."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:80
msgid "Your first look at Godot's editor"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:82
msgid ""
"Welcome to Godot! With your project open, you should see the editor's "
"interface with menus along the top of the interface and docks along the far "
"extremes of the interface on either side of the viewport."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:88
msgid ""
"At the top, from left to right, you can see the **main menus**, the "
"**workspaces**, and the **playtest buttons**."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:91
msgid ""
"The **FileSystem dock** is where you'll manage your project files and assets."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:95
msgid ""
"The **Scene dock** lists the active scene's content and the **Inspector** "
"allows for the management of the properties of a scene's content."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:100
msgid ""
"In the center, you have the **Toolbar** at the top, where you'll find tools "
"to move, scale or lock your scene's objects. It changes as you jump to "
"different workspaces."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:106
msgid ""
"The **Bottom Panel** is the host for the debug console, the animation "
"editor, the audio mixer… They are wide and can take precious space. That's "
"why they're folded by default."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:113
msgid "The workspaces"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:115
msgid ""
"You can see four workspace buttons at the top: 2D, 3D, Script and AssetLib."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:118
msgid ""
"You'll use the **2D workspace** for all types of games. In addition to 2D "
"games, the 2D workspace is where you'll build your interfaces. Press :kbd:"
"`F1` (or :kbd:`Alt + 1` on macOS) to access it."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:124
msgid ""
"In the **3D workspace**, you can work with meshes, lights, and design levels "
"for 3D games. Press :kbd:`F2` (or :kbd:`Alt + 2` on macOS) to access it."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:129
msgid ""
"Notice the perspective button under the toolbar, it opens a list of options "
"related to the 3D viewport."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:134
msgid ""
"Read :ref:`doc_introduction_to_3d` for more detail about **3D workspace**."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:136
msgid ""
"The **Script** workspace is a complete code editor with a debugger, rich "
"auto-completion, and built-in code reference. Press :kbd:`F3` (or :kbd:`Alt "
"+ 3` on macOS) to access it, and :kbd:`Shift + F1` to search the reference."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:142
msgid ""
"To search for information about a class, method, property, constant, or "
"signal in the engine while you are writing a script, press the \"Search Help"
"\" button at the top right of the Script workspace."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:148
msgid ""
"A new window will pop up. Search for the item that you want to find "
"information about."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:153
msgid ""
"Click on the item you are looking for and press open. The documentation for "
"the item will be displayed in the script workspace."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:158
msgid ""
"Finally, the **AssetLib** is a library of free and open source add-ons, "
"scripts and assets to use in your projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:162
msgid "Modify the interface"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:164
msgid ""
"Godot's interface lives in a single window. You cannot split it across "
"multiple screens although you can work with an external code editor like "
"Atom or Visual Studio Code for instance."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:169
msgid "Move and resize docks"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:171
msgid ""
"Click and drag on the edge of any dock or panel to resize it horizontally or "
"vertically."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:176
msgid ""
"Click the three-dotted icon at the top of any dock to change its location."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:181
msgid ""
"Go to the ``Editor`` menu and ``Editor Settings`` to fine-tune the look and "
"feel of the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:4
msgid "Scenes and nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:11
msgid ""
"Imagine for a second that you are not a game developer anymore. Instead, "
"you're a chef! Change your hipster outfit for a toque and a double breasted "
"jacket. Now, instead of making games, you create new and delicious recipes "
"for your guests."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:16
msgid ""
"So, how does a chef create a recipe? Recipes are divided into two sections: "
"the first is the ingredients and the second is the instructions to prepare "
"it. This way, anyone can follow the recipe and savor your magnificent "
"creation."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:21
msgid ""
"Making games in Godot feels pretty much the same way. Using the engine feels "
"like being in a kitchen. In this kitchen, *nodes* are like a refrigerator "
"full of fresh ingredients with which to cook."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:25
msgid ""
"There are many types of nodes. Some show images, others play sound, other "
"nodes display 3D models, etc. There are dozens of them."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:29
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:103
#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:46
#: ../../docs/development/file_formats/tscn.rst:26
msgid "Nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:31
msgid ""
"But let's start with the basics. Nodes are fundamental building blocks for "
"creating a game. As mentioned above, a node can perform a variety of "
"specialized functions. However, any given node always has the following "
"attributes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:35
msgid "It has a name."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:36
msgid "It has editable properties."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:37
msgid "It can receive a callback to process every frame."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:38
msgid "It can be extended (to have more functions)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:39
msgid "It can be added to another node as a child."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:43
msgid ""
"The last one is important. Nodes can have other nodes as children. When "
"arranged in this way, the nodes become a **tree**."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:46
msgid ""
"In Godot, the ability to arrange nodes in this way creates a powerful tool "
"for organizing projects. Since different nodes have different functions, "
"combining them allows for the creation of more complex functions."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:50
msgid ""
"Don't worry if this doesn't click yet. We will continue to explore this over "
"the next few sections. The most important fact to remember for now is that "
"nodes exist and can be arranged this way."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:55
msgid "Scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:59
msgid ""
"Now that the concept of nodes has been defined, the next logical step is to "
"explain what a Scene is."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:62
msgid ""
"A scene is composed of a group of nodes organized hierarchically (in tree "
"fashion). Furthermore, a scene:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:65
msgid "always has one root node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:66
msgid "can be saved to disk and loaded back."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:67
msgid "can be *instanced* (more on that later)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:69
msgid ""
"Running a game means running a scene. A project can contain several scenes, "
"but for the game to start, one of them must be selected as the main scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:72
msgid ""
"Basically, the Godot editor is a **scene editor**. It has plenty of tools "
"for editing 2D and 3D scenes as well as user interfaces, but the editor is "
"based on the concept of editing a scene and the nodes that compose it."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:77
#: ../../docs/getting_started/editor/external_editor.rst:32
#: ../../docs/development/compiling/compiling_with_mono.rst:196
msgid "Editor"
msgstr "עורך"

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:79
msgid ""
"Open the project you made in :ref:`doc_intro_to_the_editor_interface`, or "
"create a new one. This will open the Godot editor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:84
msgid ""
"As mentioned before, making games in Godot feels like being in a kitchen, so "
"let's open the refrigerator and add some fresh nodes to the project. We'll "
"begin with a \"Hello World\" message that we'll put on the screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:89
msgid ""
"To do this we need to add a Label node. Press the \"Add Child Node\" button "
"at the top left of the scene dock (the icon represents a plus symbol). This "
"button is the main way to add new nodes to a scene, and will always add the "
"chosen node as a child of the currently selected node (or, in an empty "
"scene, as the \"root\" node)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:97
msgid ""
"In an empty scene (without root node), the scene dock shows several options "
"to quickly add a root node to the scene. \"2D Scene\" adds a Node2D node, "
"\"3D Scene\" adds a Spatial node, \"User Interface\" adds a Control node, "
"and \"Custom Node\" which lets you select any node (so it is equivalent to "
"pressing the \"Add Child Node\" button). You can also press the star-shaped "
"icon to toggle the display of your favorited nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:105
msgid ""
"Note that these presets are here for convenience and are not mandatory for "
"the different types of scenes. Not every 3D scene needs a Spatial node as "
"its root node, likewise not every GUI or 2D scene needs a Control node or "
"Node2D as their root node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:110
msgid ""
"Now, to add a label node to this scene you can click on the Custom Node "
"button or the Add Node button at the top. In scenes that aren't empty you "
"use the add node button to create every child node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:116
msgid ""
"This will open the Create Node dialog, showing the long list of nodes that "
"can be created:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:121
msgid ""
"From there, select the \"Label\" node first. Searching for it is probably "
"the fastest way:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:126
msgid "And finally, create the Label! A lot happens when Create is pressed:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:130
msgid ""
"First of all, the scene changes to the 2D editor (because Label is a 2D Node "
"type), and the Label appears, selected, at the top left corner of the "
"viewport."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:133
msgid ""
"The node appears in the scene tree editor in the Scene dock, and the label "
"properties appear in the Inspector dock."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:136
msgid ""
"The next step will be to change the \"Text\" Property of the label. Let's "
"change it to \"Hello World\":"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:141
msgid ""
"Ok, everything's ready to run the scene! Press the PLAY SCENE Button on the "
"top bar (or hit :kbd:`F6`):"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:146
msgid "Aaaand... Oops."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:150
msgid ""
"Scenes need to be saved to be run, so save the scene to something like Hello."
"tscn in Scene -> Save:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:155
msgid ""
"And here's when something funny happens. The file dialog is a special file "
"dialog, and only allows you to save inside the project. The project root is "
"``res://`` which means \"resource path\". This means that files can only be "
"saved inside the project. For the future, when doing file operations in "
"Godot, remember that ``res://`` is the resource path, and no matter the "
"platform or install location, it is the way to locate where resource files "
"are from inside the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:163
msgid ""
"After saving the scene and pressing run scene again, the \"Hello World\" "
"demo should finally execute:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:168
msgid "Success!"
msgstr "הצלחה!"

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:172
msgid ""
"If this doesn't immediately work and you have a hiDPI display on at least "
"one of your monitors, go to **Project → Project Settings → Display → "
"Window** then enable **Allow Hidpi** under **Dpi**."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:180
msgid "Configuring the project"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:182
msgid ""
"Ok, it's time to configure the project. Right now, the only way to run "
"something is to execute the current scene. Projects, however, may have "
"several scenes, so one of them must be set as the main scene. This is the "
"scene that will be loaded any time the project is run."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:187
msgid ""
"These settings are all stored in a project.godot file, which is a plaintext "
"file in win.ini format (for easy editing). There are dozens of settings that "
"you can change in this file to alter how a project executes. To simplify "
"this process, Godot provides a project settings dialog, which acts as a sort "
"of frontend to editing a project.godot file."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:193
msgid "To access that dialog, select Project -> Project Settings. Try it now."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:195
msgid ""
"Once the window opens, let's select a main scene. Locate the `Application/"
"Run/Main Scene` property and click on it to select 'Hello.tscn'."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:200
msgid ""
"Now, with this change, when you press the regular Play button (or F5), this "
"scene will run, no matter which scene is actively being edited."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:203
msgid ""
"The project settings dialog provides a lot of options that can be saved to a "
"project.godot file and shows their default values. If you change a value, a "
"tick is marked to the left of its name. This means that the property will be "
"saved to the project.godot file and remembered."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:208
msgid ""
"As a side note, it is also possible to add custom configuration options and "
"read them in at run-time using the :ref:`ProjectSettings "
"<class_ProjectSettings>` singleton."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:212
msgid "To be continued..."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:214
msgid ""
"This tutorial talked about \"scenes and nodes\", but so far there has been "
"only *one* scene and *one* node! Don't worry, the next tutorial will expand "
"on that..."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:4
msgid "Instancing"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:9
msgid ""
"Creating a single scene and adding nodes into it might work for small "
"projects, but as a project grows in size and complexity, the number of nodes "
"can quickly become unmanageable. To address this, Godot allows a project to "
"be separated into any number of scenes. This provides you with a powerful "
"tool that helps you organize the different components of your game."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:15
msgid ""
"In :ref:`doc_scenes_and_nodes` you learned that a scene is a collection of "
"nodes organized in a tree structure, with a single node as the tree root."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:20
msgid ""
"You can create as many scenes as you like and save them to disk. Scenes "
"saved in this manner are called \"Packed Scenes\" and have a ``.tscn`` "
"filename extension."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:26
msgid ""
"Once a scene has been saved, it can be instanced into another scene as if it "
"were any other node."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:31
msgid "In the above picture, Scene B was added to Scene A as an instance."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:34
msgid "Instancing by example"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:36
msgid ""
"To learn how instancing works, let's start by downloading a sample project: :"
"download:`instancing.zip <files/instancing.zip>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:39
msgid ""
"Unzip this project anywhere you like. Then open Godot and add this project "
"to the project manager using the 'Import' button:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:44
msgid ""
"Browse to the folder you extracted and open the \"project.godot\" file you "
"can find inside it. After doing this, the new project will appear on the "
"list of projects. Edit the project by pressing the 'Edit' button."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:48
msgid ""
"This project contains two scenes: \"Ball.tscn\" and \"Main.tscn\". The ball "
"scene uses a :ref:`RigidBody2D <class_RigidBody2D>` to provide physics "
"behavior while the main scene has a set of obstacles for the ball to collide "
"with (using :ref:`StaticBody2D <class_StaticBody2D>`)."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:57
msgid "Open the ``Main`` scene, and then select the root node:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:61
msgid ""
"We want to add an instance of the ``Ball`` scene as a child of ``Main``. "
"Click the \"link\"-shaped button (its hover-text says \"Instance a scene "
"file as a Node.\") and select the ``Ball.tscn`` file."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:67
msgid ""
"The ball will be placed at the top-left corner of the screen area (this is "
"``(0, 0)`` in screen coordinates). Click and drag the ball somewhere near "
"the top-center of the scene:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:73
msgid "Press \"Play\" and watch the ball fall to the bottom of the screen:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:78
msgid "Multiple instances"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:80
msgid ""
"You can add as many instances as you like to a scene, either by using the "
"\"Instance\" button again, or by clicking on the ball instance and pressing :"
"kbd:`Ctrl + D` (:kbd:`Cmd + D` on macOS) to duplicate it:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:86
msgid "Run the scene again and all of the balls will fall."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:91
msgid "Editing instances"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:93
msgid ""
"Open the ``Ball`` scene, expand the ``PhysicsMaterial`` by clicking on it, "
"and set the ``Bounce`` property to ``1``."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:98
msgid ""
"Press \"Play\" and notice that all of the instanced balls are now much more "
"bouncy. Because the instanced balls are based on the saved scene, changes to "
"that scene will affect all instances."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:102
msgid ""
"You can also adjust individual instances. Set the bounce value back to ``0`` "
"and then in the ``Main`` scene, select one of the instanced balls. Resources "
"like ``PhysicsMaterial`` are shared between instances by default, so we need "
"to make it unique. Click on the down arrow and select \"Make Unique\". Set "
"its ``Bounce`` to ``1`` and press \"Play\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:110
msgid ""
"Notice that a grey \"revert\" button appears next to the adjusted property. "
"When this button is present, it means you modified a property in the "
"instanced scene to override its value in the saved scene. Even if that "
"property is modified in the original scene, the custom value will remain. "
"Pressing the revert button will restore the property to the value in the "
"saved scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:118
#: ../../docs/getting_started/step_by_step/signals.rst:276
#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:151
#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:214
msgid "Conclusion"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:120
msgid ""
"Instancing can be useful when you want to create many copies of the same "
"object. It is also possible to create instances in code by using GDScript, "
"see :ref:`doc_instancing_continued`."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:4
msgid "Instancing (continued)"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:7
msgid "Recap"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:9
msgid "Instancing has many handy uses. At a glance, with instancing you have:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:11
msgid "The ability to subdivide scenes and make them easier to manage."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:12
msgid "A tool to manage and edit multiple node instances at once."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:13
msgid ""
"A way to organize and embed complex game flows or even UIs (in Godot, UI "
"Elements are nodes, too)."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:17
msgid "Design language"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:19
msgid ""
"But the greatest strength that comes with instancing scenes is that it works "
"as an excellent design language. This distinguishes Godot from all the other "
"engines out there. Godot was designed from the ground up around this concept."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:24
msgid ""
"When making games with Godot, the recommended approach is to dismiss most "
"common design patterns, such as MVC or Entity-Relationship diagrams, and "
"instead think about your scenes in a more natural way. Start by imagining "
"the visible elements in your game, the ones that can be named not just by a "
"programmer, but by anyone."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:30
msgid "For example, here's how a simple shooter game could be imagined:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:34
msgid ""
"You can come up with a diagram like this for almost any kind of game. Write "
"down the parts of the game that you can visualize, and then add arrows to "
"represent ownership of one component by another."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:38
msgid ""
"Once you have a diagram like this, the recommended process for making a game "
"is to create a scene for each element listed in the diagram. You'll use "
"instancing (either by code or directly in the editor) for the ownership "
"relationships."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:42
msgid ""
"A lot of time spent in programming games (or software in general) is on "
"designing an architecture and fitting game components to that architecture. "
"Designing based on scenes replaces that approach and makes development much "
"faster and more straightforward, allowing you to concentrate on the game "
"logic itself. Because most game components map directly to a scene, using a "
"design based on scene instantiation means little other architectural code is "
"needed."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:48
msgid ""
"Let's take a look at one more, somewhat more complex, example of an open-"
"world type game with lots of assets and nested elements:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:53
msgid ""
"Take a look at the room element. Let's say we started there. We could make a "
"couple of different room scenes, with different arrangements of furniture "
"(also scenes) in them. Later, we could make a house scene, connecting rooms "
"to make up its interior."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:58
msgid ""
"Then, we could make a citadel scene, which is made out of many instanced "
"houses. Then, we could start working on the world map terrain, adding the "
"citadel onto it."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:62
msgid ""
"Later, we could create scenes that represent guards (and other NPCs) and add "
"them to the citadel as well. As a result, they would be indirectly added to "
"the overall game world."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:66
msgid ""
"With Godot, it's easy to iterate on your game like this, as all you need to "
"do is create and instance more scenes. Furthermore, the editor UI is "
"designed to be user friendly for programmers and non-programmers alike. A "
"typical team development process can involve 2D or 3D artists, level "
"designers, game designers, and animators, all working with the editor "
"interface."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:73
msgid "Information overload!"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:75
msgid ""
"This has been a lot of high level information dropped on you all at once. "
"However, the important part of this tutorial was to create an awareness of "
"how scenes and instancing are used in real projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:79
msgid ""
"Everything discussed here will become second nature to you once you start "
"making games and putting these concepts into practice. For now, don't worry "
"about it too much, and go on to the next tutorial!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:9
msgid ""
"Before Godot 3.0, the only choice for scripting a game was to use :ref:"
"`GDScript<doc_gdscript>`. Nowadays, Godot has four (yes, four!) official "
"languages and the ability to add extra scripting languages dynamically!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:13
msgid ""
"This is great, mostly due to the large amount of flexibility provided, but "
"it also makes our work supporting languages more difficult."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:16
msgid ""
"The \"main\" languages in Godot, though, are GDScript and VisualScript. The "
"main reason to choose them is their level of integration with Godot, as this "
"makes the experience smoother; both have slick editor integration, while C# "
"and C++ need to be edited in a separate IDE. If you are a big fan of "
"statically typed languages, go with C# and C++ instead."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:22
#: ../../docs/getting_started/scripting/gdscript/index.rst:2
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:30
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:59
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:199
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:214
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:237
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:245
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:260
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:272
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:329
#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:107
msgid "GDScript"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:24
msgid ""
":ref:`GDScript<doc_gdscript>` is, as mentioned above, the main language used "
"in Godot. Using it has some positive points compared to other languages due "
"to its high integration with Godot:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:28
msgid ""
"It's simple, elegant, and designed to be familiar for users of other "
"languages such as Lua, Python, Squirrel, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:29
msgid "Loads and compiles blazingly fast."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:30
msgid ""
"The editor integration is a pleasure to work with, with code completion for "
"nodes, signals, and many other items pertaining to the scene being edited."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:31
msgid ""
"Has vector types built-in (such as Vectors, transforms, etc.), making it "
"efficient for heavy use of linear algebra."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:32
msgid ""
"Supports multiple threads as efficiently as statically typed languages - one "
"of the limitations that made us avoid VMs such as Lua, Squirrel, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:33
msgid ""
"Uses no garbage collector, so it trades a small bit of automation (most "
"objects are reference counted anyway), by determinism."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:34
msgid ""
"Its dynamic nature makes it easy to optimize sections of code in C++ (via "
"GDNative) if more performance is required, all without recompiling the "
"engine."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:36
msgid ""
"If you're undecided and have experience with programming, especially "
"dynamically typed languages, go for GDScript!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:40
#: ../../docs/getting_started/scripting/visual_script/index.rst:2
msgid "VisualScript"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:42
msgid ""
"Beginning with 3.0, Godot offers :ref:`Visual "
"Scripting<doc_what_is_visual_script>`. This is a typical implementation of a "
"\"blocks and connections\" language, but adapted to how Godot works."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:46
msgid ""
"Visual scripting is a great tool for non-programmers, or even for "
"experienced developers who want to make parts of the code more accessible to "
"others, like game designers or artists."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:50
msgid ""
"It can also be used by programmers to build state machines or custom visual "
"node workflows - for example, a dialogue system."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:55
msgid ".NET / C#"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:57
msgid ""
"As Microsoft's C# is a favorite amongst game developers, we have added "
"official support for it. C# is a mature language with tons of code written "
"for it, and support was added thanks to a generous donation from Microsoft."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:62
msgid ""
"It has an excellent tradeoff between performance and ease of use, although "
"one must be aware of its garbage collector."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:65
msgid ""
"Since Godot uses the `Mono <https://mono-project.com>`_ .NET runtime, in "
"theory any third-party .NET library or framework can be used for scripting "
"in Godot, as well as any Common Language Infrastructure-compliant "
"programming language, such as F#, Boo or ClojureCLR. In practice however, C# "
"is the only officially supported .NET option."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:71
msgid "GDNative / C++"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:73
msgid ""
"Finally, one of our brightest additions for the 3.0 release: GDNative allows "
"scripting in C++ without needing to recompile (or even restart) Godot."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:77
msgid ""
"Any C++ version can be used, and mixing compiler brands and versions for the "
"generated shared libraries works perfectly, thanks to our use of an internal "
"C API Bridge."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:81
msgid ""
"This language is the best choice for performance and does not need to be "
"used throughout an entire game, as other parts can be written in GDScript or "
"Visual Script. However, the API is clear and easy to use as it resembles, "
"mostly, Godot's actual C++ API."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:86
msgid ""
"More languages can be made available through the GDNative interface, but "
"keep in mind we don't have official support for them."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:90
msgid "Scripting a scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:92
msgid ""
"For the rest of this tutorial we'll set up a GUI scene consisting of a "
"button and a label, where pressing the button will update the label. This "
"will demonstrate:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:96
msgid "Writing a script and attaching it to a node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:97
msgid "Hooking up UI elements via signals."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:98
msgid "Writing a script that can access other nodes in the scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:100
msgid ""
"Before continuing, please make sure to read the :ref:"
"`GDScript<doc_gdscript>` reference. It's a language designed to be simple, "
"and the reference is short, so it will not take more than a few minutes to "
"get an overview of the concepts."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:105
#: ../../docs/tutorials/physics/kinematic_character_2d.rst:79
#: ../../docs/tutorials/animation/introduction_2d.rst:109
msgid "Scene setup"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:107
msgid ""
"Use the \"Add Child Node\" dialogue accessed from the Scene tab (or by "
"pressing :kbd:`Ctrl + A`) to create a hierarchy with the following nodes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:110
msgid "Panel"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:112
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:144
msgid "Label"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:113
msgid "Button"
msgstr "כפתור"

#: ../../docs/getting_started/step_by_step/scripting.rst:115
msgid "The scene tree should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:119
msgid ""
"Use the 2D editor to position and resize the Button and Label so that they "
"look like the image below. You can set the text from the Inspector tab."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:124
msgid "Finally, save the scene with a name such as ``sayhello.tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:129
msgid "Adding a script"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:131
msgid ""
"Right click on the Panel node, then select \"Attach Script\" from the "
"context menu:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:136
msgid ""
"The script creation dialog will pop up. This dialog allows you to set the "
"script's language, class name, and other relevant options."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:139
msgid ""
"In GDScript, the file itself represents the class, so the class name field "
"is not editable."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:142
msgid ""
"The node we're attaching the script to is a panel, so the Inherits field "
"will automatically be filled in with \"Panel\". This is what we want, as the "
"script's goal is to extend the functionality of our panel node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:146
msgid "Finally, enter a path name for the script and select Create:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:150
msgid ""
"The script will then be created and added to the node. You can see this as "
"an \"Open script\" icon next to the node in the Scene tab, as well as in the "
"script property under Inspector:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:156
msgid ""
"To edit the script, select either of these buttons, both of which are "
"highlighted in the above image. This will bring you to the script editor, "
"where a default template will be included:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:161
msgid ""
"There's not much there. The ``_ready()`` function is called when the node, "
"and all its children, enters the active scene. **Note:** ``_ready()`` is not "
"the constructor; the constructor is instead ``_init()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:166
msgid "The role of the script"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:168
msgid ""
"A script adds behavior to a node. It is used to control how the node "
"functions as well as how it interacts with other nodes: children, parent, "
"siblings, and so on. The local scope of the script is the node. In other "
"words, the script inherits the functions provided by that node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:179
msgid "Handling a signal"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:181
msgid ""
"Signals are \"emitted\" when some specific kind of action happens, and they "
"can be connected to any function of any script instance. Signals are used "
"mostly in GUI nodes, although other nodes have them too, and you can even "
"define custom signals in your own scripts."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:186
msgid ""
"In this step, we'll connect the \"pressed\" signal to a custom function. "
"Forming connections is the first part and defining the custom function is "
"the second part. For the first part, Godot provides two ways to create "
"connections: through a visual interface the editor provides or through code."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:191
msgid ""
"While we will use the code method for the remainder of this tutorial series, "
"let's cover how the editor interface works for future reference."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:194
msgid ""
"Select the Button node in the scene tree and then select the \"Node\" tab. "
"Next, make sure that you have \"Signals\" selected."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:199
msgid ""
"If you then select \"pressed()\" under \"BaseButton\" and click the "
"\"Connect...\" button in the bottom right, you'll open up the connection "
"creation dialogue."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:204
msgid ""
"The top of the dialogue displays a list of your scene's nodes with the "
"emitting node's name highlighted in blue. Select the \"Panel\" node here."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:207
msgid ""
"The bottom of the dialogue shows the name of the method that will be "
"created. By default, the method name will contain the emitting node's name "
"(\"Button\" in this case), resulting in ``_on_[EmitterNode]_[signal_name]``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:211
msgid ""
"And that concludes the guide on how to use the visual interface. However, "
"this is a scripting tutorial, so for the sake of learning, let's dive into "
"the manual process!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:215
msgid ""
"To accomplish this, we will introduce a function that is probably the most "
"used by Godot programmers: :ref:`Node.get_node() "
"<class_Node_method_get_node>`. This function uses paths to fetch nodes "
"anywhere in the scene, relative to the node that owns the script."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:220
msgid ""
"For the sake of convenience, delete everything underneath ``extends Panel``. "
"You will fill out the rest of the script manually."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:223
msgid ""
"Because the Button and Label are siblings under the Panel where the script "
"is attached, you can fetch the Button by typing the following underneath the "
"``_ready()`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:240
msgid "Next, write a function which will be called when the button is pressed:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:255
msgid ""
"Finally, connect the button's \"pressed\" signal to ``_on_Button_pressed()`` "
"by using :ref:`Object.connect() <class_Object_method_connect>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:271
msgid "The final script should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:304
msgid ""
"Run the scene and press the button. You should get the following result:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:308
msgid "Why, hello there! Congratulations on scripting your first scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:312
msgid ""
"A common misunderstanding regarding this tutorial is how ``get_node(path)`` "
"works. For a given node, ``get_node(path)`` searches its immediate children. "
"In the above code, this means that Button must be a child of Panel. If "
"Button were instead a child of Label, the code to obtain it would be:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:330
msgid "Also, remember that nodes are referenced by name, not by type."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:334
msgid ""
"The right-hand panel of the connect dialogue is for binding specific values "
"to the connected function's parameters. You can add and remove values of "
"different types."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:338
msgid ""
"The code approach also enables this with a 4th ``Array`` parameter that is "
"empty by default. Feel free to read up on the ``Object.connect`` method for "
"more information."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:4
msgid "Scripting (continued)"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:7
msgid "Processing"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:9
msgid ""
"Several actions in Godot are triggered by callbacks or virtual functions, so "
"there is no need to write code that runs all the time."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:12
msgid ""
"However, it is still common to need a script to be processed on every frame. "
"There are two types of processing: idle processing and physics processing."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:16
msgid ""
"Idle processing is activated when the method :ref:`Node._process() "
"<class_Node_method__process>` is found in a script. It can be turned off and "
"on with the :ref:`Node.set_process() <class_Node_method_set_process>` "
"function."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:20
msgid "This method will be called every time a frame is drawn:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:36
msgid ""
"It's important to bear in mind that the frequency with which ``_process()`` "
"will be called depends on how many frames per second (FPS) your application "
"is running at. This rate can vary over time and devices."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:40
msgid ""
"To help manage this variability, the ``delta`` parameter contains the time "
"elapsed in seconds as a floating-point number since the previous call to "
"``_process()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:43
msgid ""
"This parameter can be used to make sure things always take the same amount "
"of time, regardless of the game's FPS."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:46
msgid ""
"For example, movement is often multiplied with a time delta to make movement "
"speed both constant and independent of the frame rate."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:49
msgid ""
"Physics processing with ``_physics_process()`` is similar, but it should be "
"used for processes that must happen before each physics step, such as "
"controlling a character. It always runs before a physics step and it is "
"called at fixed time intervals: 60 times per second by default. You can "
"change the interval from the Project Settings, under Physics -> Common -> "
"Physics Fps."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:55
msgid ""
"The function ``_process()``, however, is not synced with physics. Its frame "
"rate is not constant and is dependent on hardware and game optimization. Its "
"execution is done after the physics step on single-threaded games."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:58
msgid ""
"A simple way to see the ``_process()`` function at work is to create a scene "
"with a single Label node, with the following script:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:85
msgid "Which will show a counter increasing each frame."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:88
msgid "Groups"
msgstr "קבוצות"

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:90
msgid ""
"Groups in Godot work like tags you might have come across in other software. "
"A node can be added to as many groups as desired. This is a useful feature "
"for organizing large scenes. There are two ways to add nodes to groups. The "
"first is from the UI, using the Groups button under the Node panel:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:97
msgid ""
"And the second way is from code. The following script would add the current "
"node to the ``enemies`` group as soon as it appeared in the scene tree."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:115
msgid ""
"This way, if the player is discovered sneaking into a secret base, all "
"enemies can be notified about its alarm sounding by using :ref:`SceneTree."
"call_group() <class_SceneTree_method_call_group>`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:132
msgid ""
"The above code calls the function ``player_was_discovered`` on every member "
"of the group ``enemies``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:135
msgid ""
"It is also possible to get the full list of ``enemies`` nodes by calling :"
"ref:`SceneTree.get_nodes_in_group() "
"<class_SceneTree_method_get_nodes_in_group>`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:148
msgid ""
"The :ref:`SceneTree <class_SceneTree>` class provides many useful methods, "
"like interacting with scenes, their node hierarchy and groups of nodes. It "
"allows you to easily switch scenes or reload them, to quit the game or pause "
"and unpause it. It even comes with interesting signals. So check it out if "
"you have some time!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:156
#: ../../docs/tutorials/gui/custom_gui_controls.rst:157
msgid "Notifications"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:158
msgid ""
"Godot has a system of notifications. These are usually not needed for "
"scripting, as it's too low-level and virtual functions are provided for most "
"of them. It's just good to know they exist. For example, you may add an :ref:"
"`Object._notification() <class_Object_method__notification>` function in "
"your script:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:193
msgid ""
"The documentation of each class in the :ref:`Class Reference <toc-class-"
"ref>` shows the notifications it can receive. However, in most cases "
"GDScript provides simpler overridable functions."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:198
msgid "Overridable functions"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:200
msgid ""
"Such overridable functions, which are described as follows, can be applied "
"to nodes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:272
msgid ""
"As mentioned before, it's better to use these functions instead of the "
"notification system."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:276
msgid "Creating nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:278
msgid ""
"To create a node from code, call the ``.new()`` method, like for any other "
"class-based datatype. For example:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:302
msgid ""
"To delete a node, be it inside or outside the scene, ``free()`` must be used:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:318
msgid ""
"When a node is freed, it also frees all its child nodes. Because of this, "
"manually deleting nodes is much simpler than it appears. Free the base node "
"and everything else in the subtree goes away with it."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:322
msgid ""
"A situation might occur where we want to delete a node that is currently "
"\"blocked\", because it is emitting a signal or calling a function. This "
"will crash the game. Running Godot with the debugger will often catch this "
"case and warn you about it."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:327
msgid ""
"The safest way to delete a node is by using :ref:`Node.queue_free() "
"<class_Node_method_queue_free>`. This erases the node safely during idle."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:345
#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:128
msgid "Instancing scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:347
msgid ""
"Instancing a scene from code is done in two steps. The first one is to load "
"the scene from your hard drive:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:360
msgid ""
"Preloading it can be more convenient, as it happens at parse time (GDScript "
"only):"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:368
msgid ""
"But ``scene`` is not yet a node. It's packed in a special resource called :"
"ref:`PackedScene <class_PackedScene>`. To create the actual node, the "
"function :ref:`PackedScene.instance() <class_PackedScene_method_instance>` "
"must be called. This will return the tree of nodes that can be added to the "
"active scene:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:386
msgid ""
"The advantage of this two-step process is that a packed scene may be kept "
"loaded and ready to use so that you can create as many instances as desired. "
"This is especially useful to quickly instance several enemies, bullets, and "
"other entities in the active scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:394
msgid "Register scripts as classes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:396
msgid ""
"Godot has a \"Script Class\" feature to register individual scripts with the "
"Editor. By default, you can only access unnamed scripts by loading the file "
"directly."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:400
msgid ""
"You can name a script and register it as a type in the editor with the "
"``class_name`` keyword followed by the class's name. You may add a comma and "
"an optional path to an image to use as an icon. You will then find your new "
"type in the Node or Resource creation dialog."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:422
msgid "In Godot 3.1:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:424
msgid ""
"Only GDScript and NativeScript, i.e., C++ and other GDNative-powered "
"languages, can register scripts."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:425
msgid "Only GDScript creates global variables for each named script."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:1
#: ../../docs/tutorials/misc/instancing_with_signals.rst:1
#, fuzzy
msgid "Signal"
msgstr "אותות"

#: ../../docs/getting_started/step_by_step/signals.rst:7
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1296
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:484
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:164
#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:696
#: ../../docs/development/cpp/object_class.rst:214
msgid "Signals"
msgstr "אותות"

#: ../../docs/getting_started/step_by_step/signals.rst:12
msgid ""
"Signals are Godot's version of the *observer* pattern. They allow a node to "
"send out a message that other nodes can listen for and respond to. For "
"example, rather than continuously checking a button to see if it's being "
"pressed, the button can emit a signal when it's pressed."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:17
msgid ""
"You can read more about the observer pattern here: https://"
"gameprogrammingpatterns.com/observer.html"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:19
msgid ""
"Signals are a way to *decouple* your game objects, which leads to better "
"organized and more manageable code. Instead of forcing game objects to "
"expect other objects to always be present, they can instead emit signals "
"that all interested objects can subscribe to and respond to."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:24
msgid ""
"Below you can see some examples of how you can use signals in your own "
"projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:27
msgid "Timer example"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:29
msgid ""
"To see how signals work, let's try using a :ref:`Timer <class_Timer>` node. "
"Create a new scene with a Node2D and two children: a Timer and a :ref:"
"`Sprite <class_Sprite>`. In the Scene dock, rename Node2D to TimerExample."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:33
msgid ""
"For the Sprite's texture, you can use the Godot icon, or any other image you "
"like. Do so by selecting ``Load`` in the Sprite's Texture attribute drop-"
"down menu. Attach a script to the root node, but don't add any code to it "
"yet."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:37
msgid "Your scene tree should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:41
msgid ""
"In the Timer node's properties, check the \"On\" box next to *Autostart*. "
"This will cause the timer to start automatically when you run the scene. You "
"can leave the *Wait Time* at 1 second."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:45
msgid ""
"Next to the \"Inspector\" tab is a tab labeled \"Node\". Click on this tab "
"and you'll see all of the signals that the selected node can emit. In the "
"case of the Timer node, the one we're concerned with is \"timeout\". This "
"signal is emitted whenever the Timer reaches ``0``."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:52
msgid ""
"Click on the \"timeout()\" signal and click \"Connect...\" at the bottom of "
"the signals panel. You'll see the following window, where you can define how "
"you want to connect the signal:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:58
msgid ""
"On the left side, you'll see the nodes in your scene and can select the node "
"that you want to \"listen\" for the signal. Note that the Timer node is "
"blue, this is a visual indication that it's the node that is emitting the "
"signal. Select the root node."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:63
msgid ""
"The target node *must* have a script attached or you'll receive an error "
"message."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:66
msgid ""
"If you toggle the Advanced menu, you'll see on the right side that you can "
"bind an arbitrary number of arguments of (possibly) different types. This "
"can be useful when you have more than one signal connected to the same "
"method, as each signal propagation will result in different values for those "
"extra call arguments."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:70
msgid ""
"On the bottom of the window is a field labeled \"Receiver Method\". This is "
"the name of the function in the target node's script that you want to use. "
"By default, Godot will create this function using the naming convention "
"``_on_<node_name>_<signal_name>`` but you can change it if you wish."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:75
msgid ""
"Click \"Connect\" and you'll see that the function has been created in the "
"script:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:96
msgid ""
"Now we can replace the placeholder code with whatever code we want to run "
"when the signal is received. Let's make the Sprite blink:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:121
msgid ""
"Run the scene and you'll see the Sprite blinking on and off every second. "
"You can change the Timer's *Wait Time* property to alter this."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:125
msgid "Connecting signals in code"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:127
msgid ""
"You can also make the signal connection in code rather than with the editor. "
"This is usually necessary when you're instancing nodes via code and so you "
"can't use the editor to make the connection."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:131
msgid ""
"First, disconnect the signal by selecting the connection in the Timer's "
"\"Node\" tab and clicking disconnect."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:136
msgid ""
"To make the connection in code, we can use the ``connect`` function. We'll "
"put it in ``_ready()`` so that the connection will be made on run. The "
"syntax of the function is ``<source_node>.connect(<signal_name>, "
"<target_node>, <target_function_name>)``. Here is the code for our Timer "
"connection:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:171
#, fuzzy
msgid "Custom signals"
msgstr "אותות"

#: ../../docs/getting_started/step_by_step/signals.rst:173
msgid "You can also declare your own custom signals in Godot:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:192
msgid ""
"Once declared, your custom signals will appear in the Inspector and can be "
"connected in the same way as a node's built-in signals."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:195
msgid "To emit a signal via code, use the ``emit_signal`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:222
msgid ""
"A signal can also optionally declare one or more arguments. Specify the "
"argument names between parentheses:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:243
msgid ""
"The signal arguments show up in the editor's node dock, and Godot can use "
"them to generate callback functions for you. However, you can still emit any "
"number of arguments when you emit signals. So it's up to you to emit the "
"correct values."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:248
msgid ""
"To pass values, add them as the second argument to the ``emit_signal`` "
"function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:278
msgid ""
"Many of Godot's built-in node types provide signals you can use to detect "
"events. For example, an :ref:`Area2D <class_Area2D>` representing a coin "
"emits a ``body_entered`` signal whenever the player's physics body enters "
"its collision shape, allowing you to know when the player collected it."
msgstr ""

#: ../../docs/getting_started/step_by_step/signals.rst:283
msgid ""
"In the next section, :ref:`doc_your_first_game`, you'll build a complete "
"game including several uses of signals to connect different game components."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:4
msgid "Your first game"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:7
#: ../../docs/getting_started/step_by_step/exporting.rst:7
#: ../../docs/tutorials/animation/introduction_2d.rst:7
#: ../../docs/tutorials/assetlib/using_assetlib.rst:10
msgid "Overview"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:9
msgid ""
"This tutorial will guide you through making your first Godot project. You "
"will learn how the Godot editor works, how to structure a project, and how "
"to build a 2D game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:13
msgid ""
"This project is an introduction to the Godot engine. It assumes that you "
"have some programming experience already. If you're new to programming "
"entirely, you should start here: :ref:`doc_scripting`."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:18
msgid ""
"The game is called \"Dodge the Creeps!\". Your character must move and avoid "
"the enemies for as long as possible. Here is a preview of the final result:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:24
msgid ""
"**Why 2D?** 3D games are much more complex than 2D ones. You should stick to "
"2D until you have a good understanding of the game development process and "
"how to use Godot."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:29
#: ../../docs/getting_started/workflow/project_setup/index.rst:2
#: ../../docs/tutorials/2d/using_tilemaps.rst:21
#: ../../docs/tutorials/misc/state_design_pattern.rst:233
msgid "Project setup"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:31
msgid ""
"Launch Godot and create a new project. Then, download :download:"
"`dodge_assets.zip <files/dodge_assets.zip>`. This contains the images and "
"sounds you'll be using to make the game. Unzip these files in your project "
"folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:36
msgid ""
"For this tutorial, we will assume you are familiar with the Godot editor. If "
"you haven't read :ref:`doc_scenes_and_nodes`, do so now for an explanation "
"of setting up a project and using the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:40
msgid ""
"This game is designed for portrait mode, so we need to adjust the size of "
"the game window. Click on Project -> Project Settings -> Display -> Window "
"and set \"Width\" to ``480`` and \"Height\" to ``720``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:44
msgid ""
"Also in this section, under the \"Stretch\" options, set ``Mode`` to \"2d\" "
"and ``Aspect`` to \"keep\". This ensures that the game scales consistently "
"on different sized screens."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:49
msgid "Organizing the project"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:51
msgid ""
"In this project, we will make 3 independent scenes: ``Player``, ``Mob``, and "
"``HUD``, which we will combine into the game's ``Main`` scene. In a larger "
"project, it might be useful to create folders to hold the various scenes and "
"their scripts, but for this relatively small game, you can save your scenes "
"and scripts in the project's root folder, identified by ``res://``.  You can "
"see your project folders in the FileSystem Dock in the lower left corner:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:62
msgid "Player scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:64
msgid ""
"The first scene we will make defines the ``Player`` object. One of the "
"benefits of creating a separate Player scene is that we can test it "
"separately, even before we've created other parts of the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:69
msgid "Node structure"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:71
msgid ""
"To begin, we need to choose a root node for the player object. As a general "
"rule, a scene's root node should reflect the object's desired functionality "
"- what the object *is*. Click the \"Other Node\" button and add an :ref:"
"`Area2D <class_Area2D>` node to the scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:78
msgid ""
"Godot will display a warning icon next to the node in the scene tree. You "
"can ignore it for now. We will address it later."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:81
msgid ""
"With ``Area2D`` we can detect objects that overlap or run into the player. "
"Change the node's name to ``Player`` by double-clicking on it. Now that "
"we've set the scene's root node, we can add additional nodes to give it more "
"functionality."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:86
msgid ""
"Before we add any children to the ``Player`` node, we want to make sure we "
"don't accidentally move or resize them by clicking on them. Select the node "
"and click the icon to the right of the lock; its tooltip says \"Makes sure "
"the object's children are not selectable.\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:93
msgid ""
"Save the scene. Click Scene -> Save, or press :kbd:`Ctrl + S` on Windows/"
"Linux or :kbd:`Cmd + S` on macOS."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:95
msgid "For this project, we will be following the Godot naming conventions."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:97
msgid ""
"**GDScript**: Classes (nodes) use PascalCase, variables and functions use "
"snake_case, and constants use ALL_CAPS (See :ref:`doc_gdscript_styleguide`)."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:101
msgid ""
"**C#**: Classes, export variables and methods use PascalCase, private fields "
"use _camelCase, local variables and parameters use camelCase (See :ref:"
"`doc_c_sharp_styleguide`).  Be careful to type the method names precisely "
"when connecting signals."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:108
#, fuzzy
msgid "Sprite animation"
msgstr "אנימציות"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:110
msgid ""
"Click on the ``Player`` node and add an :ref:`AnimatedSprite "
"<class_AnimatedSprite>` node as a child. The ``AnimatedSprite`` will handle "
"the appearance and animations for our player. Notice that there is a warning "
"symbol next to the node. An ``AnimatedSprite`` requires a :ref:`SpriteFrames "
"<class_SpriteFrames>` resource, which is a list of the animations it can "
"display. To create one, find the ``Frames`` property in the Inspector and "
"click \"[empty]\" -> \"New SpriteFrames\". Click again to open the "
"\"SpriteFrames\" panel:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:121
msgid ""
"On the left is a list of animations. Click the \"default\" one and rename it "
"to \"walk\". Then click the \"New Animation\" button to create a second "
"animation named \"up\". Find the player images in the \"FileSystem\" tab - "
"they're in the ``art`` folder you unzipped earlier. Drag the two images for "
"each animation, named ``playerGrey_up[1/2]`` and ``playerGrey_walk[1/2]``, "
"into the \"Animation Frames\" side of the panel for the corresponding "
"animation:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:130
msgid ""
"The player images are a bit too large for the game window, so we need to "
"scale them down. Click on the ``AnimatedSprite`` node and set the ``Scale`` "
"property to ``(0.5, 0.5)``. You can find it in the Inspector under the "
"``Node2D`` heading."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:137
msgid ""
"Finally, add a :ref:`CollisionShape2D <class_CollisionShape2D>` as a child "
"of ``Player``. This will determine the player's \"hitbox\", or the bounds of "
"its collision area. For this character, a ``CapsuleShape2D`` node gives the "
"best fit, so next to \"Shape\" in the Inspector, click \"[empty]\"\" -> "
"\"New CapsuleShape2D\".  Using the two size handles, resize the shape to "
"cover the sprite:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:146
msgid "When you're finished, your ``Player`` scene should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:150
msgid "Make sure to save the scene again after these changes."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:153
msgid "Moving the player"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:155
msgid ""
"Now we need to add some functionality that we can't get from a built-in "
"node, so we'll add a script. Click the ``Player`` node and click the "
"\"Attach Script\" button:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:161
msgid ""
"In the script settings window, you can leave the default settings alone. "
"Just click \"Create\":"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:164
msgid ""
"If you're creating a C# script or other languages, select the language from "
"the `language` drop down menu before hitting create."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:169
msgid ""
"If this is your first time encountering GDScript, please read :ref:"
"`doc_scripting` before continuing."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:172
msgid "Start by declaring the member variables this object will need:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:193
msgid ""
"Using the ``export`` keyword on the first variable ``speed`` allows us to "
"set its value in the Inspector. This can be handy for values that you want "
"to be able to adjust just like a node's built-in properties. Click on the "
"``Player`` node and you'll see the property now appears in the \"Script "
"Variables\" section of the Inspector. Remember, if you change the value "
"here, it will override the value written in the script."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:200
msgid ""
"If you're using C#, you need to (re)build the project assemblies whenever "
"you want to see new export variables or signals. This build can be manually "
"triggered by clicking the word \"Mono\" at the bottom of the editor window "
"to reveal the Mono Panel, then clicking the \"Build Project\" button."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:208
msgid ""
"The ``_ready()`` function is called when a node enters the scene tree, which "
"is a good time to find the size of the game window:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:224
msgid ""
"Now we can use the ``_process()`` function to define what the player will "
"do. ``_process()`` is called every frame, so we'll use it to update elements "
"of our game, which we expect will change often. For the player, we need to "
"do the following:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:229
msgid "Check for input."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:230
msgid "Move in the given direction."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:231
msgid "Play the appropriate animation."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:233
msgid ""
"First, we need to check for input - is the player pressing a key? For this "
"game, we have 4 direction inputs to check. Input actions are defined in the "
"Project Settings under \"Input Map\". Here, you can define custom events and "
"assign different keys, mouse events, or other inputs to them. For this demo, "
"we will use the default events that are assigned to the arrow keys on the "
"keyboard."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:240
msgid ""
"You can detect whether a key is pressed using ``Input.is_action_pressed()``, "
"which returns ``true`` if it's pressed or ``false`` if it isn't."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:302
msgid ""
"We start by setting the ``velocity`` to ``(0, 0)`` - by default, the player "
"should not be moving. Then we check each input and add/subtract from the "
"``velocity`` to obtain a total direction. For example, if you hold ``right`` "
"and ``down`` at the same time, the resulting ``velocity`` vector will be "
"``(1, 1)``. In this case, since we're adding a horizontal and a vertical "
"movement, the player would move *faster* diagonally than if it just moved "
"horizontally."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:309
msgid ""
"We can prevent that if we *normalize* the velocity, which means we set its "
"*length* to ``1``, then multiply by the desired speed. This means no more "
"fast diagonal movement."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:313
msgid ""
"If you've never used vector math before, or need a refresher, you can see an "
"explanation of vector usage in Godot at :ref:`doc_vector_math`. It's good to "
"know but won't be necessary for the rest of this tutorial."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:317
msgid ""
"We also check whether the player is moving so we can call ``play()`` or "
"``stop()`` on the AnimatedSprite."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:320
msgid ""
"``$`` is shorthand for ``get_node()``. So in the code above, ``"
"$AnimatedSprite.play()`` is the same as ``get_node(\"AnimatedSprite\")."
"play()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:323
msgid ""
"In GDScript, ``$`` returns the node at the relative path from the current "
"node, or returns ``null`` if the node is not found. Since AnimatedSprite is "
"a child of the current node, we can use ``$AnimatedSprite``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:326
msgid ""
"Now that we have a movement direction, we can update the player's position. "
"We can also use ``clamp()`` to prevent it from leaving the screen. "
"*Clamping* a value means restricting it to a given range. Add the following "
"to the bottom of the ``_process`` function (make sure it's not indented "
"under the `else`):"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:347
msgid ""
"The `delta` parameter in the `_process()` function refers to the *frame "
"length* - the amount of time that the previous frame took to complete. Using "
"this value ensures that your movement will remain consistent even if the "
"frame rate changes."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:352
msgid ""
"Click \"Play Scene\" (``F6``) and confirm you can move the player around the "
"screen in all directions."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:355
msgid "If you get an error in the \"Debugger\" panel that says"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:357
msgid ""
"``Attempt to call function 'play' in base 'null instance' on a null "
"instance``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:359
msgid ""
"this likely means you spelled the name of the AnimatedSprite node wrong. "
"Node names are case-sensitive and ``$NodeName`` must match the name you see "
"in the scene tree."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:364
#, fuzzy
msgid "Choosing animations"
msgstr "אנימציות"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:366
msgid ""
"Now that the player can move, we need to change which animation the "
"AnimatedSprite is playing based on its direction. We have the \"walk\" "
"animation, which shows the player walking to the right. This animation "
"should be flipped horizontally using the ``flip_h`` property for left "
"movement. We also have the \"up\" animation, which should be flipped "
"vertically with ``flip_v`` for downward movement. Let's place this code at "
"the end of the ``_process()`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:401
msgid ""
"The boolean assignments in the code above are a common shorthand for "
"programmers. Since we're doing a comparison test (boolean) and also "
"*assigning* a boolean value, we can do both at the same time. Consider this "
"code versus the one-line boolean assignment above:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:425
msgid ""
"Play the scene again and check that the animations are correct in each of "
"the directions."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:428
msgid ""
"A common mistake here is to type the names of the animations wrong. The "
"animation names in the SpriteFrames panel must match what you type in the "
"code. If you named the animation ``\"Walk\"``, you must also use a capital "
"\"W\" in the code."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:433
msgid ""
"When you're sure the movement is working correctly, add this line to "
"``_ready()``, so the player will be hidden when the game starts:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:446
msgid "Preparing for collisions"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:448
msgid ""
"We want ``Player`` to detect when it's hit by an enemy, but we haven't made "
"any enemies yet! That's OK, because we're going to use Godot's *signal* "
"functionality to make it work."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:452
msgid "Add the following at the top of the script, after ``extends Area2D``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:466
msgid ""
"This defines a custom signal called \"hit\" that we will have our player "
"emit (send out) when it collides with an enemy. We will use ``Area2D`` to "
"detect the collision. Select the ``Player`` node and click the \"Node\" tab "
"next to the Inspector tab to see the list of signals the player can emit:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:473
msgid ""
"Notice our custom \"hit\" signal is there as well! Since our enemies are "
"going to be ``RigidBody2D`` nodes, we want the ``body_entered(body: Node)`` "
"signal. This signal will be emitted when a body contacts the player. Click "
"\"Connect..\" and the \"Connect a Signal\" window appears. We don't need to "
"change any of these settings so click \"Connect\" again. Godot will "
"automatically create a function in your player's script."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:482
msgid ""
"Note the green icon indicating that a signal is connected to this function. "
"Add this code to the function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:502
msgid ""
"Each time an enemy hits the player, the signal is going to be emitted. We "
"need to disable the player's collision so that we don't trigger the ``hit`` "
"signal more than once."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:506
msgid ""
"Disabling the area's collision shape can cause an error if it happens in the "
"middle of the engine's collision processing. Using ``set_deferred()`` tells "
"Godot to wait to disable the shape until it's safe to do so."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:510
msgid ""
"The last piece is to add a function we can call to reset the player when "
"starting a new game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:531
msgid "Enemy scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:533
msgid ""
"Now it's time to make the enemies our player will have to dodge. Their "
"behavior will not be very complex: mobs will spawn randomly at the edges of "
"the screen, choose a random direction, and move in a straight line."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:537
msgid ""
"We'll create a ``Mob`` scene, which we can then *instance* to create any "
"number of independent mobs in the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:540
msgid "See :ref:`doc_instancing` to learn more about instancing."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:543
#, fuzzy
msgid "Node setup"
msgstr "נתיב"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:545
msgid "Click Scene -> New Scene and add the following nodes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:547
msgid ":ref:`RigidBody2D <class_RigidBody2D>` (named ``Mob``)"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:549
msgid ":ref:`AnimatedSprite <class_AnimatedSprite>`"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:550
msgid ":ref:`CollisionShape2D <class_CollisionShape2D>`"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:551
msgid ":ref:`VisibilityNotifier2D <class_VisibilityNotifier2D>`"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:553
msgid ""
"Don't forget to set the children so they can't be selected, like you did "
"with the Player scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:556
msgid ""
"In the :ref:`RigidBody2D <class_RigidBody2D>` properties, set ``Gravity "
"Scale`` to ``0``, so the mob will not fall downward. In addition, under the "
"``PhysicsBody2D`` section, click the ``Mask`` property and uncheck the first "
"box. This will ensure the mobs do not collide with each other."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:563
msgid ""
"Set up the :ref:`AnimatedSprite <class_AnimatedSprite>` like you did for the "
"player. This time, we have 3 animations: ``fly``, ``swim``, and ``walk``. "
"There are two images for each animation in the art folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:567
msgid "Adjust the \"Speed (FPS)\" to ``3`` for all animations."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:571
msgid "Set the ``Playing`` property in the Inspector to “On”."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:573
msgid ""
"We'll select one of these animations randomly so that the mobs will have "
"some variety."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:575
msgid ""
"Like the player images, these mob images need to be scaled down. Set the "
"``AnimatedSprite``'s ``Scale`` property to ``(0.75, 0.75)``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:578
msgid ""
"As in the ``Player`` scene, add a ``CapsuleShape2D`` for the collision. To "
"align the shape with the image, you'll need to set the ``Rotation Degrees`` "
"property to ``90`` (under \"Transform\" in the Inspector)."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:582
#, fuzzy
msgid "Save the scene."
msgstr "יצירת תוכן"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:585
#, fuzzy
msgid "Enemy script"
msgstr "תיאור"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:587
msgid "Add a script to the ``Mob`` and add the following member variables:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:611
msgid ""
"When we spawn a mob, we'll pick a random value between ``min_speed`` and "
"``max_speed`` for how fast each mob will move (it would be boring if they "
"were all moving at the same speed)."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:615
msgid ""
"Now let's look at the rest of the script. In ``_ready()`` we randomly choose "
"one of the three animation types:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:637
msgid ""
"First, we get the list of animation names from the AnimatedSprite's "
"``frames`` property. This returns an Array containing all three animation "
"names: ``[\"walk\", \"swim\", \"fly\"]``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:641
msgid ""
"We then need to pick a random number between ``0`` and ``2`` to select one "
"of these names from the list (array indices start at ``0``). ``randi() % n`` "
"selects a random integer between ``0`` and ``n-1``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:645
msgid ""
"You must use ``randomize()`` if you want your sequence of \"random\" numbers "
"to be different every time you run the scene. We're going to use "
"``randomize()`` in our ``Main`` scene, so we won't need it here."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:649
msgid ""
"The last piece is to make the mobs delete themselves when they leave the "
"screen. Connect the ``screen_exited()`` signal of the "
"``VisibilityNotifier2D`` node and add this code:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:666
msgid "This completes the `Mob` scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:669
msgid "Main scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:671
msgid ""
"Now it's time to bring it all together. Create a new scene and add a :ref:"
"`Node <class_Node>` named ``Main``. Click the \"Instance\" button and select "
"your saved ``Player.tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:677
msgid ""
"Now, add the following nodes as children of ``Main``, and name them as shown "
"(values are in seconds):"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:680
msgid ""
":ref:`Timer <class_Timer>` (named ``MobTimer``) - to control how often mobs "
"spawn"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:681
msgid ""
":ref:`Timer <class_Timer>` (named ``ScoreTimer``) - to increment the score "
"every second"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:682
msgid ""
":ref:`Timer <class_Timer>` (named ``StartTimer``) - to give a delay before "
"starting"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:683
msgid ""
":ref:`Position2D <class_Position2D>` (named ``StartPosition``) - to indicate "
"the player's start position"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:685
msgid ""
"Set the ``Wait Time`` property of each of the ``Timer`` nodes as follows:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:688
msgid "``MobTimer``: ``0.5``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:689
msgid "``ScoreTimer``: ``1``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:690
msgid "``StartTimer``: ``2``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:692
msgid ""
"In addition, set the ``One Shot`` property of ``StartTimer`` to \"On\" and "
"set ``Position`` of the ``StartPosition`` node to ``(240, 450)``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:696
msgid "Spawning mobs"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:698
msgid ""
"The Main node will be spawning new mobs, and we want them to appear at a "
"random location on the edge of the screen. Add a :ref:`Path2D "
"<class_Path2D>` node named ``MobPath`` as a child of ``Main``. When you "
"select ``Path2D``, you will see some new buttons at the top of the editor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:705
msgid ""
"Select the middle one (\"Add Point\") and draw the path by clicking to add "
"the points at the corners shown. To have the points snap to the grid, make "
"sure \"Use Grid Snap\" is selected. This option can be found to the left of "
"the \"Lock\" button, appearing as a magnet next to some intersecting lines."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:712
msgid ""
"Draw the path in *clockwise* order, or your mobs will spawn pointing "
"*outwards* instead of *inwards*!"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:717
msgid ""
"After placing point ``4`` in the image, click the \"Close Curve\" button and "
"your curve will be complete."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:720
msgid ""
"Now that the path is defined, add a :ref:`PathFollow2D <class_PathFollow2D>` "
"node as a child of ``MobPath`` and name it ``MobSpawnLocation``. This node "
"will automatically rotate and follow the path as it moves, so we can use it "
"to select a random position and direction along the path."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:725
msgid "Your scene should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:730
msgid "Main script"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:732
msgid ""
"Add a script to ``Main``. At the top of the script, we use ``export "
"(PackedScene)`` to allow us to choose the Mob scene we want to instance."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:772
msgid ""
"Click the ``Main`` node and you will see the ``Mob`` property in the "
"Inspector under \"Script Variables\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:775
msgid "You can assign this property's value in two ways:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:777
msgid ""
"Drag ``Mob.tscn`` from the \"FileSystem\" panel and drop it in the ``Mob`` "
"property ."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:779
msgid ""
"Click the down arrow next to \"[empty]\" and choose \"Load\". Select ``Mob."
"tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:782
msgid ""
"Next, click on the Player and connect the ``hit`` signal. We want to make a "
"new function named ``game_over``, which will handle what needs to happen "
"when a game ends. Type \"game_over\" in the \"Receiver Method\" box at the "
"bottom of the \"Connect a Signal\" window and click \"Connect\". Add the "
"following code to the new function, as well as a ``new_game`` function that "
"will set everything up for a new game:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:820
msgid ""
"Now connect the ``timeout()`` signal of each of the Timer nodes "
"(``StartTimer``, ``ScoreTimer`` , and ``MobTimer``) to the main script. "
"``StartTimer`` will start the other two timers. ``ScoreTimer`` will "
"increment the score by 1."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:847
msgid ""
"In ``_on_MobTimer_timeout()``, we will create a mob instance, pick a random "
"starting location along the ``Path2D``, and set the mob in motion. The "
"``PathFollow2D`` node will automatically rotate as it follows the path, so "
"we will use that to select the mob's direction as well as its position."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:853
msgid ""
"Note that a new instance must be added to the scene using ``add_child()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:901
msgid ""
"Why ``PI``? In functions requiring angles, GDScript uses *radians*, not "
"degrees. If you're more comfortable working with degrees, you'll need to use "
"the ``deg2rad()`` and ``rad2deg()`` functions to convert between the two."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:907
#, fuzzy
msgid "Testing the scene"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/step_by_step/your_first_game.rst:909
msgid ""
"Let's test the scene to make sure everything is working. Add this to "
"``_ready()``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:926
msgid ""
"Let's also assign ``Main`` as our \"Main Scene\" - the one that runs "
"automatically when the game launches. Press the \"Play\" button and select "
"``Main.tscn`` when prompted."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:930
msgid ""
"You should be able to move the player around, see mobs spawning, and see the "
"player disappear when hit by a mob."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:933
msgid ""
"When you're sure everything is working, remove the call to ``new_game()`` "
"from ``_ready()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:937
msgid "HUD"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:939
msgid ""
"The final piece our game needs is a UI: an interface to display things like "
"score, a \"game over\" message, and a restart button. Create a new scene, "
"and add a :ref:`CanvasLayer <class_CanvasLayer>` node named ``HUD``. \"HUD\" "
"stands for \"heads-up display\", an informational display that appears as an "
"overlay on top of the game view."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:945
msgid ""
"The :ref:`CanvasLayer <class_CanvasLayer>` node lets us draw our UI elements "
"on a layer above the rest of the game, so that the information it displays "
"isn't covered up by any game elements like the player or mobs."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:949
msgid "The HUD needs to display the following information:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:951
msgid "Score, changed by ``ScoreTimer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:952
msgid "A message, such as \"Game Over\" or \"Get Ready!\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:953
msgid "A \"Start\" button to begin the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:955
msgid ""
"The basic node for UI elements is :ref:`Control <class_Control>`. To create "
"our UI, we'll use two types of :ref:`Control <class_Control>` nodes: :ref:"
"`Label <class_Label>` and :ref:`Button <class_Button>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:959
msgid "Create the following as children of the ``HUD`` node:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:961
msgid ":ref:`Label <class_Label>` named ``ScoreLabel``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:962
msgid ":ref:`Label <class_Label>` named ``Message``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:963
msgid ":ref:`Button <class_Button>` named ``StartButton``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:964
msgid ":ref:`Timer <class_Timer>` named ``MessageTimer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:966
msgid ""
"Click on the ``ScoreLabel`` and type a number into the ``Text`` field in the "
"Inspector. The default font for ``Control`` nodes is small and doesn't scale "
"well. There is a font file included in the game assets called \"Xolonium-"
"Regular.ttf\". To use this font, do the following:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:971
msgid "Under \"Custom Fonts\", choose \"New DynamicFont\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:975
msgid ""
"Click on the \"DynamicFont\" you added, and under \"Font/Font Data\", choose "
"\"Load\" and select the \"Xolonium-Regular.ttf\" file. You must also set the "
"font's ``Size``. A setting of ``64`` works well."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:981
msgid ""
"Once you've done this on the ``ScoreLabel``, you can click the down arrow "
"next to the DynamicFont property and choose \"Copy\", then \"Paste\" it in "
"the same place on the other two Control nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:985
msgid ""
"**Anchors and Margins:** ``Control`` nodes have a position and size, but "
"they also have anchors and margins. Anchors define the origin - the "
"reference point for the edges of the node. Margins update automatically when "
"you move or resize a control node. They represent the distance from the "
"control node's edges to its anchor. See :ref:"
"`doc_design_interfaces_with_the_control_nodes` for more details."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:992
msgid ""
"Arrange the nodes as shown below. Click the \"Layout\" button to set a "
"Control node's layout:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:997
msgid ""
"You can drag the nodes to place them manually, or for more precise "
"placement, use the following settings:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1001
msgid "ScoreLabel"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1003
msgid "*Layout* : \"Top Wide\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1004
msgid "*Text* : ``0``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1005
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1012
msgid "*Align* : \"Center\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1008
msgid "Message"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1010
msgid "*Layout* : \"HCenter Wide\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1011
msgid "*Text* : ``Dodge the Creeps!``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1013
msgid "*Autowrap* : \"On\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1016
msgid "StartButton"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1018
msgid "*Text* : ``Start``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1019
msgid "*Layout* : \"Center Bottom\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1020
msgid "*Margin* :"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1022
msgid "Top: ``-200``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1023
msgid "Bottom: ``-100``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1025
msgid ""
"On the ``MessageTimer``, set the ``Wait Time`` to ``2`` and set the ``One "
"Shot`` property to \"On\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1028
msgid "Now add this script to ``HUD``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1047
msgid ""
"The ``start_game`` signal tells the ``Main`` node that the button has been "
"pressed."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1069
msgid ""
"This function is called when we want to display a message temporarily, such "
"as \"Get Ready\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1103
msgid ""
"This function is called when the player loses. It will show \"Game Over\" "
"for 2 seconds, then return to the title screen and, after a brief pause, "
"show the \"Start\" button."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1107
msgid ""
"When you need to pause for a brief time, an alternative to using a Timer "
"node is to use the SceneTree's ``create_timer()`` function. This can be very "
"useful to add delays such as in the above code, where we want to wait some "
"time before showing the \"Start\" button."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1125
msgid "This function is called by ``Main`` whenever the score changes."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1127
msgid ""
"Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` "
"signal of ``StartButton`` and add the following code to the new functions:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155
msgid "Connecting HUD to Main"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1157
msgid ""
"Now that we're done creating the ``HUD`` scene, go back to ``Main``. "
"Instance the ``HUD`` scene in ``Main`` like you did the ``Player`` scene. "
"The scene tree should look like this, so make sure you didn't miss anything:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1163
msgid ""
"Now we need to connect the ``HUD`` functionality to our ``Main`` script. "
"This requires a few additions to the ``Main`` scene:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166
msgid ""
"In the Node tab, connect the HUD's ``start_game`` signal to the "
"``new_game()`` function of the Main node by typing \"new_game\" in the "
"\"Receiver Method\" in the \"Connect a Signal\" window. Verify that the "
"green connection icon now appears next to ``func new_game()`` in the script."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171
msgid ""
"In ``new_game()``, update the score display and show the \"Get Ready\" "
"message:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1186
msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1197
msgid ""
"Finally, add this to ``_on_ScoreTimer_timeout()`` to keep the display in "
"sync with the changing score:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1209
msgid ""
"Now you're ready to play! Click the \"Play the Project\" button. You will be "
"asked to select a main scene, so choose ``Main.tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1213
msgid "Removing old creeps"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1215
msgid ""
"If you play until \"Game Over\" and then start a new game right away, the "
"creeps from the previous game may still be on the screen. It would be better "
"if they all disappeared at the start of a new game. We just need a way to "
"tell *all* the mobs to remove themselves. We can do this with the \"group\" "
"feature."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1220
msgid ""
"In the ``Mob`` scene, select the root node and click the \"Node\" tab next "
"to the Inspector (the same place where you find the node's signals). Next to "
"\"Signals\", click \"Groups\" and you can type a new group name and click "
"\"Add\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1226
msgid ""
"Now all mobs will be in the \"mobs\" group. We can then add the following "
"line to the ``game_over()`` function in ``Main``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1239
msgid ""
"The ``call_group()`` function calls the named function on every node in a "
"group - in this case we are telling every mob to delete itself."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1243
msgid "Finishing up"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1245
msgid ""
"We have now completed all the functionality for our game. Below are some "
"remaining steps to add a bit more \"juice\" to improve the game experience. "
"Feel free to expand the gameplay with your own ideas."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1250
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:59
msgid "Background"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1252
msgid ""
"The default gray background is not very appealing, so let's change its "
"color. One way to do this is to use a :ref:`ColorRect <class_ColorRect>` "
"node. Make it the first node under ``Main`` so that it will be drawn behind "
"the other nodes. ``ColorRect`` only has one property: ``Color``. Choose a "
"color you like and select \"Layout\" -> \"Full Rect\" so that it covers the "
"screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1258
msgid ""
"You could also add a background image, if you have one, by using a "
"``TextureRect`` node instead."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1262
msgid "Sound effects"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1264
msgid ""
"Sound and music can be the single most effective way to add appeal to the "
"game experience. In your game assets folder, you have two sound files: "
"\"House In a Forest Loop.ogg\" for background music, and \"gameover.wav\" "
"for when the player loses."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1269
msgid ""
"Add two :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` nodes as children "
"of ``Main``. Name one of them ``Music`` and the other ``DeathSound``. On "
"each one, click on the ``Stream`` property, select \"Load\", and choose the "
"corresponding audio file."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1274
msgid ""
"To play the music, add ``$Music.play()`` in the ``new_game()`` function and "
"``$Music.stop()`` in the ``game_over()`` function."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1277
msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1280
msgid "Keyboard shortcut"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1282
msgid ""
"Since the game is played with keyboard controls, it would be convenient if "
"we could also start the game by pressing a key on the keyboard. We can do "
"this with the \"Shortcut\" property of the ``Button`` node."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1286
msgid ""
"In the ``HUD`` scene, select the ``StartButton`` and find its *Shortcut* "
"property in the Inspector. Select \"New Shortcut\" and click on the "
"\"Shortcut\" item. A second *Shortcut* property will appear. Select \"New "
"InputEventAction\" and click the new \"InputEventAction\". Finally, in the "
"*Action* property, type the name ``ui_select``. This is the default input "
"event associated with the spacebar."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1294
msgid ""
"Now when the start button appears, you can either click it or press :kbd:"
"`Space` to start the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1298
msgid "Project files"
msgstr ""

#: ../../docs/<generated>:1
msgid "You can find a completed version of this project at these locations:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1301
msgid "https://github.com/kidscancode/Godot3_dodge/releases"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1302
msgid "https://github.com/godotengine/godot-demo-projects"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:4
#: ../../docs/getting_started/editor/command_line_tutorial.rst:257
msgid "Exporting"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:9
msgid ""
"Now that you have a working game, you probably want to share your success "
"with others. However, it's not practical to ask your friends to download "
"Godot just so they can open your project. Instead, you can *export* your "
"project, converting it into a \"package\" that can be run by anyone."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:14
msgid ""
"The way you export your game depends on what platform you are targeting. In "
"this tutorial, you'll learn how to export the \"Dodge the Creeps\" game for "
"a variety of platforms. First, however, we need to make some changes to the "
"way the game works."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:19
msgid ""
"If you haven't made \"Dodge the Creeps\" yourself yet, please read :ref:"
"`doc_your_first_game` before continuing with this tutorial."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:23
msgid "Preparing the project"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:25
msgid ""
"In \"Dodge the Creeps\" we used keyboard controls to move the player's "
"character. This is fine if your game is being played on a PC platform, but "
"on a phone or tablet, you need to support touchscreen input. Because a click "
"event can be treated the same as a touch event, we'll convert the game to a "
"click-and-move input style."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:31
msgid ""
"By default Godot emulates mouse input from touch input. That means if "
"anything is coded to happen on a mouse event, touch will trigger it as well. "
"Godot can also emulate touch input from mouse clicks, which we will need to "
"be able to keep playing our game on our computer after we switch to touch "
"input. In the \"Project Settings\" under *Input Devices* and *Pointing*, set "
"*Emulate Touch From Mouse* to \"On\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:39
msgid ""
"We also want to ensure that the game scales consistently on different-sized "
"screens, so in the project settings go to *Display*, then click on *Window*. "
"In the *Stretch* options, set *Mode* to \"2d\" and *Aspect* to \"keep\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:43
msgid ""
"Since we are already in the *Window* settings, we should also set under "
"*Handheld* the *Orientation* to \"portrait\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:48
msgid ""
"Next, we need to modify the ``Player.gd`` script to change the input method. "
"We'll remove the key inputs and make the player move towards a \"target\" "
"that's set by the touch (or click) event."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:52
msgid ""
"Here is the full script for the player, with comments noting what we've "
"changed:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:240
#, fuzzy
msgid "Setting a main scene"
msgstr "אנימציות"

#: ../../docs/getting_started/step_by_step/exporting.rst:242
msgid ""
"The main scene is the one that your game will start in. In *Project -> "
"Project Settings -> Application -> Run*, set *Main Scene* to \"Main.tscn\" "
"by clicking the folder icon and selecting it."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:247
#: ../../docs/getting_started/workflow/export/exporting_projects.rst:92
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:295
#: ../../docs/development/compiling/compiling_with_mono.rst:172
msgid "Export templates"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:249
msgid ""
"In order to export, you need to download the *export templates* from the "
"http://godotengine.org/download. These templates are optimized versions of "
"the engine without the editor pre-compiled for each platform . You can also "
"download them in Godot by clicking on *Editor -> Manage Export Templates*:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:256
msgid ""
"In the window that appears, you can click \"Download\" to get the template "
"version that matches your version of Godot."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:261
msgid ""
"If you upgrade Godot, you must download templates that match the new version "
"or your exported projects may not work correctly."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:265
#, fuzzy
msgid "Export presets"
msgstr "ייצוא"

#: ../../docs/getting_started/step_by_step/exporting.rst:267
msgid ""
"Next, you can configure the export settings by clicking on *Project -> "
"Export*."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:269
msgid ""
"Create a new export preset by clicking \"Add...\" and selecting a platform. "
"You can make as many presets as you like with different settings."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:274
msgid ""
"At the bottom of the window are two buttons. \"Export PCK/ZIP\" only creates "
"a packed version of your project's data. This doesn't include an executable "
"so the project can't be run on its own."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:278
msgid ""
"The second button, \"Export Project\", creates a complete executable version "
"of your game, such as an `.apk` for Android or an `.exe` for Windows."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:281
msgid ""
"In the \"Resources\" and \"Features\" tabs, you can customize how the game "
"is exported for each platform. We can leave those settings alone for now."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:285
msgid "Exporting by platform"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:287
msgid ""
"In this section, we'll walk through the process for each platform, including "
"any additional software or requirements you'll need."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:291
msgid "PC (Linux/macOS/Windows)"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:293
msgid ""
"Exporting PC platforms works the same across the three supported operating "
"systems. Open the export window and click \"Add..\" to create the preset(s) "
"you want to make. Then click \"Export Project\" and choose a name and "
"destination folder. Choose a location *outside* of your project folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:298
msgid "Click \"Save\" and the engine will build the export files."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:300
msgid ""
"When exporting for macOS, if you export on a macOS computer, you'll end up "
"with a `.dmg` file, while using Linux or Windows produces a `.zip`. In "
"either case, the compressed file contains a macOS `.app` that you can double-"
"click and run."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:305
msgid ""
"On Windows, if you want your exported executable to have a different icon "
"than the default one, you need to change it manually. See: :ref:"
"`doc_changing_application_icon_for_windows`."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:312
msgid ""
"Mobile devices come with a wide variety of capabilities. In most cases, "
"Godot's default settings will work, but mobile development is sometimes more "
"art than science, and you may need to do some experimenting and searching "
"for help in order to get everything working."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:318
msgid ""
"Before you can export your project for Android, you must download the "
"following software:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:321
msgid "Android SDK: https://developer.android.com/studio/"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:322
msgid ""
"Open JDK(version 8 is required, more recent versions won't work): https://"
"adoptopenjdk.net/index.html"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:324
msgid ""
"When you run Android Studio for the first time, click on *Configure -> SDK "
"Manager* and install \"Android SDK Platform Tools\". This installs the `adb` "
"command-line tool that Godot uses to communicate with your device."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:328
msgid ""
"Next, create a debug keystore by running the following command on your "
"system's command line:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:335
msgid ""
"Click on *Editor -> Editor Settings* in Godot and select the *Export/"
"Android* section. Here, you need to set the paths to the Android SDK "
"applications on your system and the location of the keystore you just "
"created."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:341
msgid ""
"Now you're ready to export. Click on *Project -> Export* and add a preset "
"for Android (see above). Select the Android Presets and under *Options* go "
"to *Screen* and set *Orientation* to \"Portrait\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:345
msgid ""
"Click the \"Export Project\" button and Godot will build an APK you can "
"download on your device. To do this on the command line, use the following:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:352
msgid ""
"Your device may need to be in *developer mode*. Consult your device's "
"documentation for details."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:355
msgid ""
"If your system supports it, connecting a compatible Android device will "
"cause a \"One-click Deploy\" button to appear in Godot's playtest button "
"area:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:360
msgid ""
"Clicking this button builds the APK and copies it onto your device in one "
"step."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:365
msgid ""
"In order to build your game for iOS, you must have a computer running macOS "
"with Xcode installed."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:368
msgid ""
"Before exporting, there are some settings that you *must* complete for the "
"project to export successfully. First, the \"App Store Team Id\", which you "
"can find by logging in to your Apple developer account and looking in the "
"\"Membership\" section."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:372
msgid "You must also provide icons and splash screen images as shown below:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:376
msgid "Click \"Export Project\" and select a destination folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:378
msgid ""
"Once you have successfully exported the project, you'll find the following "
"folders and files have been created in your selected location:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:383
msgid ""
"You can now open the project in Xcode and build the project for iOS. Xcode "
"build procedure is beyond the scope of this tutorial. See https://help.apple."
"com/xcode/mac/current/#/devc8c2a6be1 for more information."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:389
msgid "HTML5 (web)"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:391
msgid ""
"Click \"Export Project\" on the HTML5 preset. We don't need to change any of "
"the default settings."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:394
msgid ""
"When the export is complete, you'll have a folder containing the following "
"files:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:399
msgid ""
"Viewing the `.html` file in your browser lets you play the game. However, "
"you can't open the file directly, it needs to be served by a web server. If "
"you don't have one set up on your computer, you can search online to find "
"suggestions for your specific OS."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:404
msgid ""
"Point your browser at the URL where you've placed the html file. You may "
"have to wait a few moments while the game loads before you see the start "
"screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:409
msgid ""
"The console window beneath the game tells you if anything goes wrong. You "
"can disable it by setting \"Export With Debug\" off when you export the "
"project."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:414
msgid ""
"While WASM is supported in all major browsers, it is still an emerging "
"technology and you may find some things that don't work. Make sure you have "
"updated your browser to the most recent version, and report any bugs you "
"find at the `Godot GitHub repository <https://github.com/godotengine/godot/"
"issues>`_."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:4
msgid "Godot's design philosophy"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:6
msgid "Now that you've gotten your hands wet, let's talk about Godot's design."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:8
msgid ""
"**Every game engine is different and fits different needs.** Not only do "
"they offer a range of features, but the design of each engine is unique. "
"This leads to different workflows and different ways to form your games' "
"structures. This all stems from their respective design philosophies."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:13
msgid ""
"This page is here to help you understand how Godot works, starting with some "
"of its core pillars. It is not a list of available features, nor is it an "
"engine comparison. To know if any engine can be a good fit for your project, "
"you need to try it out for yourself and understand its design and "
"limitations."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:19
msgid ""
"Please watch `Discover Godot 3, the Free game engine <https://youtu."
"be/4v3qge-3CqQ>`_ if you're looking for an overview of the engine's features."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:23
msgid "Object-oriented design and composition"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:25
msgid ""
"Godot embraces object-oriented design at its core with its flexible scene "
"system and Node hierarchy. It tries to stay away from strict programming "
"patterns to offer an intuitive way to structure your game."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:29
msgid ""
"For one, Godot lets you **compose or aggregate** scenes. It's like nested "
"prefabs: you can create a BlinkingLight scene and a BrokenLantern scene that "
"uses the BlinkingLight. Then, create a city filled with BrokenLanterns. "
"Change the BlinkingLight's color, save, and all the BrokenLanterns in the "
"city will update instantly."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:36
msgid "On top of that, you can **inherit** from any scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:38
msgid ""
"A Godot scene could be a Weapon, a Character, an Item, a Door, a Level, part "
"of a level… anything you'd like. It works like a class in pure code, except "
"you're free to design it by using the editor, using only the code, or mixing "
"and matching the two."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:43
msgid ""
"It's different from prefabs you find in several 3D engines, as you can then "
"inherit from and extend those scenes. You may create a Magician that extends "
"your Character. Modify the Character in the editor and the Magician will "
"update as well. It helps you build your projects so that their structure "
"matches the game's design."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:49
#: ../../docs/tutorials/assetlib/using_assetlib.rst:16
#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:82
msgid "|image0|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:51
msgid ""
"Also note that Godot offers many different types of objects called nodes, "
"each with a specific purpose. Nodes are part of a tree and always inherit "
"from their parents up to the Node class. Although the engine does feature "
"components like collision shapes, they're the exception, not the norm."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:57
#: ../../docs/tutorials/assetlib/using_assetlib.rst:48
msgid "|image1|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:59
msgid ""
"Sprite is a Node2D, a CanvasItem and a Node. It has all the properties and "
"features of its three parent classes, like transforms or the ability to draw "
"custom shapes and render with a custom shader."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:64
msgid "All-inclusive package"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:66
msgid ""
"Godot tries to provide its own tools to answer most common needs. It has a "
"dedicated scripting workspace, an animation editor, a tilemap editor, a "
"shader editor, a debugger, a profiler, the ability to hot-reload locally and "
"on remote devices, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:71
#: ../../docs/tutorials/assetlib/using_assetlib.rst:58
msgid "|image2|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:73
msgid ""
"The goal is to offer a full package to create games and a continuous user "
"experience. You can still work with external programs as long as there is an "
"import plugin for it. Or you can create one, like the `Tiled Map Importer "
"<https://github.com/vnen/godot-tiled-importer>`__."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:78
msgid ""
"That is also partly why Godot offers its own programming languages GDscript "
"and VisualScript, along with C#. They're designed for the needs of game "
"developers and game designers, and they're tightly integrated in the engine "
"and the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:83
msgid ""
"GDscript lets you write simple code using Python-like syntax, yet it detects "
"types and offers a static language's quality of auto-completion. It is also "
"optimized for gameplay code with built-in types like Vectors and Colors."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:87
msgid ""
"Note that with GDNative, you can write high-performance code using compiled "
"languages like C, C++, Rust, or Python (using the Cython compiler) without "
"recompiling the engine."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:91
#: ../../docs/tutorials/assetlib/using_assetlib.rst:81
msgid "|image3|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:93
msgid ""
"*VisualScript is a node-based programming language that integrates well in "
"the editor. You can drag and drop nodes or resources into the graph to "
"create new code blocks.*"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:97
msgid ""
"Note that the 3D workspace doesn't feature as many tools as the 2D "
"workspace. You'll need external programs or add-ons to edit terrains, "
"animate complex characters, and so on. Godot provides a complete API to "
"extend the editor's functionality using game code. See `The Godot editor is "
"a Godot game`_ below."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:102
#: ../../docs/tutorials/assetlib/using_assetlib.rst:86
msgid "|image4|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:104
msgid ""
"*A State Machine editor plugin in Godot 2 by kubecz3k. It lets you manage "
"states and transitions visually.*"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:108
msgid "Open source"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:110
msgid ""
"Godot offers a fully open source codebase under the **MIT license**. This "
"means all the technologies that ship with it have to be Free (as in freedom) "
"as well. For the most part, they're developed from the ground up by "
"contributors."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:115
msgid ""
"Anyone can plug in proprietary tools for the needs of their projects — they "
"just won't ship with the engine. This may include Google AdMob, or FMOD. Any "
"of these can come as third-party plugins instead."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:120
msgid ""
"On the other hand, an open codebase means you can **learn from and extend "
"the engine** to your heart's content. You can also debug games easily, as "
"Godot will print errors with a stack trace, even if they come from the "
"engine itself."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:126
msgid ""
"This **does not affect the work you do with Godot** in any way: there's no "
"strings attached to the engine or anything you make with it."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:130
msgid "Community-driven"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:132
msgid ""
"**Godot is made by its community, for the community, and for all game "
"creators out there.** It's the needs of the users and open discussions that "
"drive the core updates. New features from the core developers often focus on "
"what will benefit the most users first."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:137
msgid ""
"That said, although a handful of core developers work on it full-time, the "
"project has over 600 contributors at the time of writing. Benevolent "
"programmers work on features they may need themselves, so you'll see "
"improvements in all corners of the engine at the same time in every major "
"release."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:144
msgid "The Godot editor is a Godot game"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:146
msgid ""
"The Godot editor runs on the game engine. It uses the engine's own UI "
"system, it can hot-reload code and scenes when you test your projects, or "
"run game code in the editor. This means you can **use the same code** and "
"scenes for your games, or **build plugins and extend the editor.**"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:151
msgid ""
"This leads to a reliable and flexible UI system, as it powers the editor "
"itself. With the ``tool`` keyword, you can run any game code in the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:154
#: ../../docs/tutorials/assetlib/using_assetlib.rst:90
msgid "|image5|"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:156
msgid ""
"*RPG in a Box is a voxel RPG editor made with Godot 2. It uses Godot's UI "
"tools for its node-based programming system and for the rest of the "
"interface.*"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:160
msgid ""
"Put the ``tool`` keyword at the top of any GDScript file and it will run in "
"the editor. This lets you import and export plugins, create plugins like "
"custom level editors, or create scripts with the same nodes and API you use "
"in your projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:166
msgid "Separate 2D and 3D engines"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:168
msgid ""
"Godot offers dedicated 2D and 3D rendering engines. As a result, **the base "
"unit for 2D scenes is pixels.** Even though the engines are separate, you "
"can render 2D in 3D, 3D in 2D, and overlay 2D sprites and interfaces over "
"your 3D world."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:4
msgid "Design interfaces with the Control nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:6
msgid ""
"Computer displays, mobile phones, and TV screens come in all shapes and "
"sizes. To ship a game, you'll need to support different screen ratios and "
"resolutions. It can be hard to build responsive interfaces that adapt to all "
"platforms. Thankfully, Godot comes with robust tools to design and manage a "
"responsive User Interface."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:14
msgid "Godot's editor is made with the engine's UI framework"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:16
msgid "This guide will get you started with UI design. You will learn:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:18
msgid "The five most useful control nodes to build your games' interface"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:19
msgid "How to work with the anchor of UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:20
msgid ""
"How to efficiently place and arrange your user interface using containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:22
msgid ""
"The five most common containers (you can learn more about containers in the :"
"ref:`GUI Containers <doc_gui_containers>` documentation page)."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:25
msgid ""
"To learn how to control the interface and connect it to other scripts, read :"
"ref:`Build your first game UI in Godot <doc_ui_game_user_interface>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:28
msgid ""
"To design your UI, you'll use the Control nodes. These are the nodes with "
"green icons in the editor. There are dozens of them, for creating anything "
"from life bars to complex applications. Godot's editor itself is built using "
"Control nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:32
msgid ""
"Control nodes have unique properties that allow them to work well with one "
"another. Other visual nodes, like Node2D and Sprite don't have these "
"capabilities. So to make your life easier use Control nodes wherever "
"possible when building your UIs."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:36
msgid "All control nodes share the same main properties:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:38
msgid "Anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:39
msgid "Bounding rectangle"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:40
msgid "Focus and focus neighbor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:41
#: ../../docs/tutorials/gui/gui_containers.rst:38
msgid "Size flags"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:42
msgid "Margin"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:43
msgid "The optional UI theme"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:45
msgid ""
"Once you understand the basics of the Control node, it will take you less "
"time to learn all the nodes that derive from it."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:50
msgid "The 5 most common UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:52
msgid ""
"Godot ships with dozens of Control nodes. A lot of them are here to help you "
"build editor plugins and applications."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:55
msgid ""
"For most games, you'll only need five types of UI elements, and a few "
"Containers. These five Control nodes are:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:58
msgid "Label: for displaying text"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:59
msgid ""
"TextureRect: used mostly for backgrounds, or everything that should be a "
"static image"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:61
msgid ""
"TextureProgress: for lifebars, loading bars, horizontal, vertical or radial"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:63
msgid "NinePatchRect: for scalable panels"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:64
msgid "TextureButton: to create buttons"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:68
msgid "The 5 most common Control nodes for UI design"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:71
msgid "TextureRect"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:73
msgid ""
"**TextureRect** displays a texture or image inside a UI. It seems similar to "
"the Sprite node, but it offers multiple scaling modes. Set the Stretch Mode "
"property to change its behavior:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:77
msgid ""
"``Scale On Expand (compat)`` scales the texture to fit the node's bounding "
"rectangle, only if ``expand`` property is ``true``; otherwise, it behaves "
"like ``Keep`` mode. Default mode for backwards compatibility."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:80
msgid "``Scale`` scales the texture to fit the node's bounding rectangle."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:81
msgid "``Tile`` makes the texture repeat, but it won't scale."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:82
msgid ""
"``Keep`` and ``Keep Centered`` force the texture to remain at its original "
"size, in the top left corner or the center of the frame respectively."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:85
msgid ""
"``Keep Aspect`` and ``Keep Aspect Centered`` scales the texture but force it "
"to remain its original aspect ratio, in the top left corner or the center of "
"the frame respectively."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:87
msgid ""
"``Keep Aspect Covered`` works just like ``Keep Aspect Centered`` but the "
"shorter side fits the bounding rectangle and the other one clips to the "
"node's limits."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:90
msgid ""
"As with Sprite nodes, you can modulate the TextureRect's color. Click the "
"``Modulate`` property and use the color picker."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:95
msgid "TextureRect modulated with a red color"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:98
msgid "TextureButton"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:100
msgid ""
"**TextureButton** is like TextureRect, except it has 5 texture slots: one "
"for each of the button's states. Most of the time, you'll use the Normal, "
"Pressed, and Hover textures. Focused is useful if your interface listens to "
"the keyboard's input. The sixth image slot, the Click Mask, lets you define "
"the clickable area using a 1-bit, pure black and white image."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:107
msgid ""
"In the Base Button section, you'll find a few checkboxes that change how the "
"button behaves. When ``Toggle Mode`` is on, the button will toggle between "
"active and normal states when you press it. ``Disabled`` makes it disabled "
"by default, in which case it will use the ``Disabled`` texture. "
"TextureButton shares a few properties with the texture frame: it has a "
"``modulate`` property, to change its color, and ``Resize`` and ``Stretch`` "
"modes to change its scale behavior."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:117
msgid "TextureButton and its 5 texture slots"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:120
msgid "TextureProgress"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:122
msgid ""
"**TextureProgress** layers up to 3 sprites to create a progress bar. The "
"Under and Over textures sandwich the Progress one, which displays the bar's "
"value."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:126
msgid ""
"The ``Mode`` property controls the direction in which the bar grows: "
"horizontally, vertically, or radially. If you set it to radial, the "
"``Initial Angle`` and ``Fill Degrees`` properties let you limit the range of "
"the gauge."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:131
msgid ""
"To animate the bar, you'll want to look at the Range section. Set the "
"``Min`` and ``Max`` properties to define the range of the gauge. For "
"instance, to represent a character's life, you'll want to set ``Min`` to ``0,"
"`` and ``Max`` to the character's maximum life. Change the ``Value`` "
"property to update the bar. If you leave the ``Min`` and ``Max`` values to "
"the default of ``0`` and ``100,`` and set the ``Value`` property to ``40``, "
"40% of the ``Progress`` texture will show up, and 60% of it will stay hidden."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:141
msgid "TextureProgress bar, two thirds filled"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:146
msgid ""
"**Label** prints text to the screen. You'll find all its properties in the "
"Label section, in the Inspector. Write the text in the ``Text`` property, "
"and check Autowrap if you want it to respect the textbox's size. If Autowrap "
"is off, you won't be able to scale the node. You can align the text "
"horizontally and vertically with Align and Valign, respectively."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:155
msgid "Picture of a Label"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:158
msgid "NinePatchRect"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:160
msgid ""
"**NinePatchRect** takes a texture split in 3 rows and 3 columns. The center "
"and the sides tile when you scale the texture, but it never scales the "
"corners. It is useful to build panels, dialog boxes and scalable backgrounds "
"for your UI."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:167
msgid "NinePatchRect scaled with the min\\_size property"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:170
msgid "There are two workflows to build responsive UIs"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:172
msgid ""
"There are two workflows to build scalable and flexible interfaces in Godot:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:174
msgid ""
"You have many container nodes at your disposal that scale and place UI "
"elements for you. They take control over their children."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:175
msgid ""
"On the other side, you have the layout menu. It helps you to anchor, place "
"and resize a UI element within its parent."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:177
msgid ""
"The two approaches are not always compatible. Because a container controls "
"its children, you cannot use the layout menu on them. Each container has a "
"specific effect, so you may need to nest several of them to get a working "
"interface. With the layout approach you work from the bottom up, on the "
"children. As you don't insert extra containers in the scene it can make for "
"cleaner hierarchies, but it's harder to arrange items in a row, column, "
"grid, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:179
msgid ""
"As you create UIs for your games and tools, you'll develop a sense for what "
"fits best in each situation."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:183
msgid "Place UI elements precisely with anchors"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:185
msgid ""
"Control nodes have a position and size, but they also have anchors and "
"margins. Anchors define the origin, or the reference point, for the Left, "
"Top, Right and Bottom edges of the node. Change any of the 4 anchors to "
"change the reference point of the margins."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:192
msgid "The anchor property"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:195
msgid "How to change the anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:197
msgid ""
"Like any properties, you can edit the 4 anchor points in the Inspector, but "
"this is not the most convenient way. When you select a control node, the "
"layout menu appears above the viewport, in the toolbar. It gives you a list "
"of icons to set all 4 anchors with a single click, instead of using the "
"inspector's 4 properties. The layout menu will only show up when you select "
"a control node."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:206
msgid "The layout menu in the viewport"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:209
msgid "Anchors are relative to the parent container"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:211
msgid ""
"Each anchor is a value between 0 and 1. For the left and top anchors, a "
"value of 0 means that without any margin, the node's edges will align with "
"the left and top edges of its parent. For the right and bottom edges, a "
"value of 1 means they'll align with the parent container's right and bottom "
"edges. On the other hand, margins represent a distance to the anchor "
"position in pixels, while anchors are relative to the parent container's "
"size."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:221
msgid ""
"Margins are relative to the anchor position, which is relative to the "
"anchors. In practice, you'll often let the container update margins for you"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:226
msgid "Margins change with the anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:228
msgid ""
"Margins update automatically when you move or resize a control node. They "
"represent the distance from the control node's edges to its anchor, which is "
"relative to the parent control node or container. That's why your control "
"nodes should always be inside a container, as we'll see in a moment. If "
"there's no parent, the margins will be relative to the node's own bounding "
"Rectangle, set in the Rect section, in the inspector."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:238
msgid "Margins on a CenterContainer set to the \"Full Rect\" anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:240
msgid ""
"Try to change the anchors or nest your Control nodes inside Containers: the "
"margins will update. You'll rarely need to edit the margins manually. Always "
"try to find a container to help you first; Godot comes with nodes to solve "
"all the common cases for you. Need to add space between a lifebar and the "
"border of the screen? Use the MarginContainer. Want to build a vertical "
"menu? Use the VBoxContainer. More on these below."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:249
msgid "Use size tags to change how UI elements fill the available space"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:251
msgid ""
"Every control node has Size Flags. They tell containers how the UI elements "
"should scale. If you add the \"Fill\" flag to the Horizontal or Vertical "
"property, the node's bounding box will take all the space it can, but it'll "
"respect its siblings and retain its size. If there are 3 TextureRect nodes "
"in an HBoxContainer, with the \"Fill\" flags on both axes, they'll each take "
"up to a third of the available space, but no more. The container will take "
"over the node and resize it automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:261
msgid "3 UI elements in an HBoxContainer, they align horizontally"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:263
msgid ""
"The \"Expand\" flag lets the UI element take all the space it can, and push "
"against its siblings. Its bounding rectangle will grow against the edges of "
"its parent, or until it's blocked by another UI node."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:269
msgid ""
"The same example as above, but the center node has the \"Expand\" size flag"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:272
msgid ""
"You'll need some practice to understand the size tags, as their effect can "
"change quite a bit depending on how you set up your interface."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:276
msgid "Arrange control nodes automatically with containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:278
msgid ""
"Containers automatically arrange all children Control nodes including other "
"containers in rows, columns, and more. Use them to add padding around your "
"interface or center nodes in their bounding rectangles. All built-in "
"containers update in the editor, so you can see the effect instantly."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:284
msgid ""
"Containers have a few special properties to control how they arrange UI "
"elements. To change them, navigate down to the Custom Constants section in "
"the Inspector."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:289
msgid "The 5 most useful containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:291
msgid ""
"If you build tools, you might need all of the containers. But for most "
"games, a handful will be enough:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:294
msgid "MarginContainer, to add margins around part of the UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:295
msgid "CenterContainer, to center its children in its bounding box"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:296
msgid ""
"VboxContainer and HboxContainer, to arrange UI elements in rows or columns"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:298
msgid "GridContainer, to arrange Controls nodes in a grid-like pattern"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:300
msgid ""
"CenterContainer centers all its children inside of its bounding rectangle. "
"It's one you typically use for title screens, if you want the options to "
"stay in the center of the viewport. As it centers everything, you'll often "
"want a single container nested inside it. If you use textures and buttons "
"instead, they'll stack up."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:308
msgid ""
"CenterContainer in action. The life bar centers inside its parent container."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:311
msgid ""
"The MarginContainer adds a margin on any side of the child nodes. Add a "
"MarginContainer that encompasses the entire viewport to add a separation "
"between the edge of the window and the UI. You can set a margin on the top, "
"left, right, or bottom side of the container. No need to tick the checkbox: "
"click the corresponding value box and type any number. It will activate "
"automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:320
msgid "The MarginContainer adds a 40px margin around the Game User Interface"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:322
msgid ""
"There are two BoxContainers: VBoxContainer and HBoxContainer. You cannot add "
"the BoxContainer node itself, as it is a helper class, but you can use "
"vertical and horizontal box containers. They arrange nodes either in rows or "
"columns. Use them to line up items in a shop, or to build complex grids with "
"rows and columns of different sizes, as you can nest them to your heart's "
"content."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:331
msgid "The HBoxContainer horizontally aligns UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:333
msgid ""
"VBoxContainer automatically arranges its children into a column. It puts "
"them one after the other. If you use the separation parameter, it will leave "
"a gap between its children. HBoxContainer arranges UI elements in a row. "
"It's similar to the VBoxContainer, with an extra ``add_spacer`` method to "
"add a spacer control node before its first child or after its last child, "
"from a script."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:340
msgid ""
"The GridContainer lets you arrange UI elements in a grid-like pattern. You "
"can only control the number of columns it has, and it will set the number of "
"rows by itself, based on its children's count. If you have nine children and "
"three columns, you will have 9÷3 = 3 rows. Add three more children and "
"you'll have four rows. In other words, it will create new rows as you add "
"more textures and buttons. Like the box containers, it has two properties to "
"set the vertical and horizontal separation between the rows and columns "
"respectively."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:351
msgid "A GridContainer with 2 columns. It sizes each column automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:353
msgid ""
"Godot's UI system is complex, and has a lot more to offer. To learn how to "
"design more advanced interfaces, head to the :ref:`GUI section <toc-learn-"
"features-gui>` of the docs."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:4
msgid "Design a title screen"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:6
msgid ""
"In the next two tutorials, you will build two responsive UI (user interface) "
"scenes step-by-step using the engine's UI system:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:9
msgid "A main menu."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:10
msgid "A game UI with a health bar, energy bar, bomb and money counters."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:12
msgid ""
"You will learn how to design game UIs efficiently, and how to use Godot's "
"Control nodes. This page focuses on the visual part: everything you do from "
"the editor. To learn how to code a life bar, read :doc:`ui_code_a_life_bar`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:20
msgid "The GUI you're going to create."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:22
msgid ""
"Download the project files: :download:`ui_main_menu_design.zip <files/"
"ui_main_menu_design.zip>` and extract the archive. Import the ``start/`` "
"project in Godot to follow this tutorial. The ``end/`` folder contains the "
"final result. You'll find all the sprites in the ``start/assets/main_menu`` "
"folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:30
msgid ""
"Read the :doc:`ui_introduction_to_the_ui_system` first to learn how Godot's "
"UI system works."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:34
msgid "How to design your game UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:36
msgid ""
"To design a good UI, you want to come up with a rough mockup first: a plain "
"drawing version that focuses on the placement of your UI components, their "
"size, and user interaction. Pen and paper is all you need. You shouldn't use "
"fancy and final graphics at this stage. Then, you only need simple "
"placeholder sprites and you're good to jump into Godot. You want to make "
"sure the players can find their way around the interface using those "
"placeholders."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:46
msgid "The UI's rough plan or mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:48
msgid ""
"Placeholder doesn't have to mean ugly, but you should keep the graphics "
"simple and clean. Avoid special effects, animation, and detailed "
"illustration before you have players playtest your UI. Otherwise:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:52
msgid ""
"The graphics might skew the players' perception of the experience and you'll "
"miss out on valuable feedback."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:54
msgid "If the User Experience doesn't work, you'll have to redo some sprites."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:58
msgid ""
"Always try to make the interface work with simple text and boxes first. It's "
"easy to replace the textures later. Professional UX designers often work "
"with plain outlines and boxes in greyscale. When you take colors and fancy "
"visuals away, it's a lot easier to size and place UI elements properly. It "
"helps you refine the design foundation you'll build upon."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:65
msgid "There are two ways to design your UI in Godot. You can:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:67
msgid ""
"Build it all in a single scene, and eventually save some branches as "
"reusable scenes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:69
msgid ""
"Build template scenes for reusable components and create specific components "
"that inherit from your base scenes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:72
msgid ""
"We will use the first approach, because the first version of your UI may not "
"work as well as you'd like. You're likely to throw parts away and redesign "
"components as you go. When you're sure everything works, it's easy to make "
"some parts reusable, as you'll see below."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:79
msgid ""
"The files you'll find in Godot. The graphics look cleaner than on the rough "
"design, but they're still placeholders."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:83
msgid "Design the main menu"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:85
msgid ""
"Before we jump into the editor, we want to plan how we'll nest containers "
"based on our mockup image."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:89
#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:282
msgid "Break down the UI mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:91
msgid "Here are my three rules of thumb to find the right containers:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:93
msgid ""
"Break down the UI into nested boxes, from the largest that contains "
"everything, to the smallest ones, that encompass one widget, like a bar with "
"its label, a panel or a button."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:96
msgid "If there's some padding around an area, use a ``MarginContainer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:97
msgid ""
"If the elements are arranged in rows or columns, use an ``HBoxContainer`` or "
"``VBoxContainer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:100
msgid ""
"These rules are enough to get us started, and work well for simple "
"interfaces."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:103
msgid ""
"For the main menu, the largest box is the entire game window. There's "
"padding between the edges of the window and the first components: this "
"should be a ``MarginContainer``. Then, the screen is split into two columns, "
"so we'll use an ``HBoxContainer``. In the left column, we'll manage the rows "
"with a ``VBoxContainer``. And in the right column, we'll center the "
"illustration with a ``CenterContainer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:112
msgid "Interface building blocks, broken down using the three rules of thumb."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:116
msgid ""
"Containers adapt to the window's resolution and width-to-height ratio. "
"Although we could place UI elements by hand, containers are faster, more "
"precise, and **responsive**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:121
msgid "Prepare the Main Menu scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:123
msgid ""
"Let's create the main menu. We'll build it in a single scene. To create an "
"empty scene, click on **Scene > New Scene**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:126
msgid ""
"We have to add a root node before we can save the scene. Your UI's root "
"should be the outermost container or element. In this case it's a "
"``MarginContainer``. ``MarginContainer`` is a good starting point for most "
"interfaces, as you often need padding around the UI. Press :kbd:`Ctrl + S` (:"
"kbd:`Cmd + S` on macOS) to save the scene to the disk. Name it *MainMenu*."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:132
msgid ""
"Select the ``MarginContainer`` again, and head to the inspector to define "
"the margins' size. Scroll down the ``Control`` class, to the ``Custom "
"Constants`` section. Unfold it. Set the margins as such:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:136
msgid "Margin Right: *120*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:137
msgid "Margin Top: *80*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:138
msgid "Margin Left: *120*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:139
msgid "Margin Bottom: *80*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:141
msgid ""
"We want the container to fit the window. In the toolbar above the Viewport, "
"open the **Layout** menu and select the last option, **Full Rect**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:145
msgid "Add the UI sprites"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:147
msgid ""
"Select the ``MarginContainer``, and create the UI elements as "
"``TextureRect`` nodes. We need:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:150
msgid "the title or logo,"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:151
msgid "the three text options as individual nodes,"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:152
msgid "the version note,"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:153
msgid "and the main menu's illustration."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:155
msgid ""
"Click the **Add Node** button or press :kbd:`Ctrl + A` (:kbd:`Cmd + A` on "
"macOS) on your keyboard. Start to type ``TextureRect`` to find the "
"corresponding node and press enter. With the new node selected, press :kbd:"
"`Ctrl + D` (:kbd:`Cmd + D` on macOS) five times to create five extra "
"``TextureRect`` instances."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:160
msgid ""
"Click each of the nodes to select it. In the inspector, find the **Texture** "
"property and click **[empty] > Load**. A file browser opens and lets you "
"pick a sprite to load into the texture slot."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:166
msgid "The file browser lets you find and load textures."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:168
msgid ""
"Repeat the operation for all ``TextureRect`` nodes. You should have the "
"logo, the illustration, the three menu options and the version note, each as "
"a separate node. Then, double click on each of the nodes in the Scene tab to "
"rename them. Nothing has been placed in containers yet so this should look "
"messy."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:176
msgid "The six nodes with textures loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:180
msgid ""
"If you want to support localization in your game, use ``Labels`` for menu "
"options instead of ``TextureRect``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:184
msgid "Add containers to place UI elements automatically"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:186
msgid ""
"Our main menu has some margin around the edges of the screen. It is split in "
"two parts: on the left, you have the logo and the menu options. On the "
"right, you have the characters. We can use one of two containers to achieve "
"this: ``HSplitContainer`` or ``HBoxContainer``. Split containers split the "
"area into two: a left and a right side or a top and a bottom side. They also "
"allow the user to resize the left and right areas using an interactive bar. "
"On the other hand, ``HBoxContainer`` just splits itself into as many columns "
"as it has children. Although you can deactivate the split container's resize "
"behavior, I recommend to favor box containers."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:197
msgid ""
"Select the ``MarginContainer`` and add an ``HBoxContainer``. Then, we need "
"two containers as children of our ``HBoxContainer``: a ``VBoxContainer`` for "
"the menu options on the left, and a ``CenterContainer`` for the illustration "
"on the right."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:204
msgid ""
"You should have four nested containers and the TextureRect nodes sitting "
"aside from it."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:207
msgid ""
"In the node tree, select all the ``TextureRect`` nodes that should go on the "
"left side: the logo, the menu options (Continue, NewGame, Options), and the "
"version note. Drag and drop them into the ``VBoxContainer``. The nodes "
"should position automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:214
msgid "Containers automatically place and resize textures"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:216
msgid "We're left with two problems to solve:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:218
msgid "The characters on the right aren't centered."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:219
msgid "There's no space between the logo and the other UI elements."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:221
msgid ""
"To center the characters on the right, first select the ``CenterContainer``. "
"Then in the Inspector, scroll down to the **Size Flags** category and click "
"on the field to the right of the **Vertical** property, and check **Expand** "
"in addition to **Fill**. Do the same for the **Horizontal** property. This "
"makes the ``CenterContainer`` expand into all available space while "
"respecting its neighbour ``VBoxContainer``. Finally, drag and drop the "
"Characters node into the ``CenterContainer``. The Characters element will "
"center automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:232
msgid ""
"The character node centers inside the right half of the screen as soon as "
"you place it inside the CenterContainer."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:235
msgid ""
"To space out the menu options and the logo on the left, we'll use one final "
"container and its size flags. Select the ``VBoxContainer`` and press :kbd:"
"`Ctrl + A` (:kbd:`Cmd + A` on macOS) to add a new node inside it. Add a "
"second ``VBoxContainer`` and name it *MenuOptions*. Select all three menu "
"options, ``Continue``, ``NewGame`` and ``Options``, and drag and drop them "
"inside the new ``VBoxContainer``. The UI's layout should barely change, if "
"at all."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:245
msgid ""
"Place the new container between the other two nodes to retain the UI's "
"layout."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:248
msgid ""
"Now we grouped the menu options together, we can tell their container to "
"expand to take as much vertical space as possible. Select the "
"``MenuOptions`` node. In the Inspector, scroll down to the **Size Flags** "
"category. Click on the field to the right of the **Vertical** property, and "
"check **Expand** in addition to **Fill**. The container expands to take all "
"the available vertical space while respecting its neighbors, the ``Logo`` "
"and ``Version`` elements."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:256
msgid ""
"To center the nodes in the ``VBoxContainer``, scroll to the top of the "
"Inspector and change the **Alignment** property to **Center**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:261
msgid "The menu options should center vertically in the UI's left column."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:263
msgid ""
"To wrap things up, let's add some separation between the menu options. "
"Expand the **Custom Constants** category below **Size Flags**, and click the "
"field next to the **Separation** parameter. Set it to 30. Once you press "
"enter, the **Separation** property becomes active and Godot adds 30 pixels "
"between menu options."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:271
msgid "The final interface."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:273
msgid ""
"Without a single line of code, we have a precise and responsive main menu."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:276
msgid ""
"Congratulations for getting there! You can download the final menu :download:"
"`ui_main_menu_design.zip <files/ui_main_menu_design.zip>` to compare with "
"your own. In the next tutorial, you'll create a Game User Interface with "
"bars and item counters."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:284
msgid ""
"A responsive User Interface is all about making sure our UIs scale well on "
"all screen types. TV screens and computer displays have different sizes and "
"ratios. In Godot, we use containers to control the position and the size of "
"UI elements."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:289
msgid ""
"The order in which you nest matters. To see if your UI adapts nicely to "
"different screen ratios, select the root node, press :kbd:`Q` to activate "
"the Select Mode, select the container and click and drag on one of the "
"container's corners to resize it. The UI components should flow inside of it."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:295
msgid ""
"You'll notice that although containers move sprites around, they don't scale "
"them. This is normal. We want the UI system to handle different screen "
"ratios, but we also need the entire game to adapt to different screen "
"resolutions. To do this, Godot scales the entire window up and down."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:301
msgid ""
"You can change the scale mode in the project settings: click **Project > "
"Project Settings** in the top menu. In the window's left column, look for "
"the **Display** category. Click on the **Window** sub-category. On the right "
"side of the window, you'll find a **Stretch** section. The three settings, "
"**Mode**, **Aspect**, and **Shrink**, control the screen size. For more "
"information, see :ref:`doc_multiple_resolutions`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:4
msgid "Design the GUI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:6
msgid ""
"Now that you've nailed the basics, we're going to see how to build a game "
"Graphical User Interface (GUI) with reusable UI components: a life bar, an "
"energy bar, and bomb and emerald counters. By the end of this tutorial, "
"you'll have a game GUI, ready to control with GDscript or VisualScript:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:13
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:621
msgid "The final result"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:15
msgid "You'll also learn to:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:17
msgid "Create flexible UI components"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:18
msgid "Use scene inheritance"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:19
msgid "Build a complex UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:21
msgid ""
"Download the project files: :download:`ui_gui_design.zip <files/"
"ui_gui_design.zip>` and extract the archive. Import the `start/` project in "
"Godot to follow this tutorial. The `end/` folder contains the final result."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:25
msgid ""
"You can watch this tutorial as a `video on YouTube <https://www.youtube.com/"
"watch?v=y1E_y9AIqow>`_."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:28
msgid "Breaking down the UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:30
msgid ""
"Let's break down the final UI and plan the containers we'll use. As in the :"
"doc:`ui_main_menu`, it starts with a ``MarginContainer``. Then, we can see "
"up to three columns:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:34
msgid "The life and energy counters on the left"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:35
msgid "The life and energy bars"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:36
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:42
msgid "The bomb and emerald counters on the right"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:38
msgid ""
"But the bar's label and the gauge are two parts of the same UI element. If "
"we think of them this way, we're left with two columns:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:41
msgid "The life and energy bars on the left"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:44
msgid ""
"This makes it easier to nest containers: we have some margins around the "
"border of the screen using a ``MarginContainer``, followed by an "
"``HBoxContainer`` to manage our two columns. The two bars stack on top of "
"one another inside a ``VBoxContainer``. And we'll need a last "
"``HBoxContainer`` in the right column to place the bomb and emerald counters "
"side-by-side."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:53
msgid "We get a clean UI layout with only 4 containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:55
msgid ""
"We will need extra containers inside the individual UI components, but this "
"gives us the main GUI scene's structure. With this plan in place, we can "
"jump into Godot and create our GUI."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:60
msgid "Create the base GUI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:62
msgid ""
"There are two possible approaches to the GUI: we can design elements in "
"separate scenes and put them together, or prototype everything in a single "
"scene and break it down later. I recommend working with a single scene as "
"you can play with your UI's placement and proportions faster this way. Once "
"it looks good, you can save entire sections of the node tree as reusable sub-"
"scenes. We'll do that in a moment."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:69
msgid "For now, let's start with a few containers."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:71
msgid ""
"Create a new scene and add a ``MarginContainer``. Select the node and name "
"it ``GUI``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:74
msgid ""
"We want our interface to anchor to the top of the screen. Select the ``GUI`` "
"node and click the Layout button at the top of the viewport. Select the "
"``Top Wide`` option. The ``GUI`` node will anchor to the top edge of its "
"parent, the viewport by default. It will resize automatically on the "
"vertical axis to make space for its child UI components."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:80
msgid "Save the scene as ``GUI.tscn``. We will put the entire GUI in it."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:82
msgid ""
"With the ``MarginContainer`` selected, head to the inspector and scroll down "
"to the custom constants section. Unfold it and click the field next to each "
"of the ``Margin`` properties. Set them all to ``20`` pixels. Next, add an "
"``HBoxContainer`` node. This one will contain our two bars on the left and "
"separate them from the two counters on the right."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:88
msgid ""
"We want to stack the bars vertically inside the ``HBoxContainer``. Add a "
"``VBoxContainer`` as a child of ``HBoxContainer`` and name it ``Bars``. "
"Select the parent ``HBoxContainer`` again and this time, add another "
"``HBoxContainer`` as a child of it. Call it ``Counters``. With these four "
"containers, we have the base for our GUI scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:95
msgid "You should have 4 containers that look like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:99
msgid ""
"We can work this way because we first broke down our UI design and took a "
"few moments to think about the containers we'd use. When you follow a "
"tutorial like this, it may seem weird. But once you're working on real "
"games, you'll see it's an efficient workflow."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:105
msgid "Create the bars' base"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:107
msgid ""
"Each bar is split into two sub-elements that align horizontally: the label "
"with the health count on the left, and the gauge on the right. Once again, "
"the ``HBoxContainer`` is the perfect tool for the job. Select the ``Bars`` "
"node and add a new ``HBoxContainer`` inside of it. Name it ``Bar``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:113
msgid ""
"The label itself requires at least three nodes: a ``NinePatchRect`` for the "
"background, on top of which we'll add a texture on the left, either ``HP`` "
"or ``EP``, and a ``Label`` on the right for the value. We can nest "
"``Control`` nodes however we want. We could use the ``NinePatchRect`` as a "
"parent for the two other elements, as it encompasses them. In general, you "
"want to use containers instead, as their role is to help organize UI "
"components. We'll need a ``MarginContainer`` later anyway to add some space "
"between the life count and the gauge. Select the ``Bar`` and add a "
"``MarginContainer``. Name it ``Count``. Inside of it, add three nodes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:124
msgid "A ``NinePatchRect`` named ``Background``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:125
msgid "A ``TextureRect`` named ``Title``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:126
msgid "And a ``Label`` named ``Number``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:128
msgid "To add the nodes as siblings, always select the ``Count`` node first."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:132
msgid ""
"Your scene tree should look like this. We're ready to throw in some textures"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:135
msgid ""
"Our scene is still empty. It's time to throw in some textures. To load the "
"textures, head to the FileSystem dock to the left of the viewport. Browse "
"down to the res://assets/GUI folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:141
msgid "You should see a list of textures that we'll use to skin our interface."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:144
msgid ""
"Select the ``Background`` in the Scene dock. In the Inspector, you should "
"see a ``Texture`` property. In the FileSystem tab, click and drag "
"``label_HP_bg.png`` onto the ``Texture`` slot. It stays squashed. The parent "
"MarginContainer will force its size down to 0 until we force elements inside "
"the container to have a minimum size. Select the ``Background`` node. In the "
"Inspector, scroll down to the Rect section. Set ``Min Size`` to (100, 40). "
"You should see the ``Background`` resize along with its parent containers."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:153
msgid ""
"Next, select the ``Title`` and drag and drop ``label_HP.png`` into its "
"``Texture`` slot. Select the ``Number`` node, click the field next to the "
"``Text`` property and type ``10``. This way, we can see both nodes in the "
"viewport. They should stack up in the top-left corner of their parent "
"``MarginContainer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:161
msgid "If you select both nodes, you should see something like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:163
msgid ""
"As they have a container as their direct parent, we cannot move them freely: "
"the ``Count`` node will always reset their anchors, their size and position. "
"Try to move and resize the nodes in the viewport. Then, select any of the "
"three textures and press :kbd:`Ctrl + Up` or :kbd:`Ctrl + Down` to reorder "
"them in the Scene dock. They'll snap back to their previous size and "
"position."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:170
msgid ""
"Parent containers control the size, the scale, the margins, and the anchors "
"of their direct children. To modify the nodes, you must nest them inside a "
"regular Control or another UI element. We'll use the ``Background`` as a "
"parent for the ``Title`` and ``Number``. Select both the ``Title`` and "
"``Number``, and drag and drop them onto ``Background``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:179
msgid ""
"By using the Background node as the two textures' parent, we take control "
"away from the Count MarginContainer"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:182
msgid ""
"Select the ``Title`` and in the Inspector, change its ``Stretch Mode`` "
"property to ``Keep Centered``. Next find the ``Rect`` category in the "
"Inspector and change the ``Size`` property to (50, 40) so it only takes the "
"left half of the background.  Next, select the ``Number`` node. In the "
"viewport, click the ``Layout`` menu and click ``Full Rect``. The node will "
"resize to fit the ``Background``. Head to the Inspector and change its "
"``Align`` property to ``Right``, and the ``Valign`` property to ``Center``. "
"The text should snap to the center of the ``Background``'s right edge. "
"Resize the node horizontally, so it takes the right half of the "
"``Background`` and there's a bit of padding with the right edge."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:195
msgid ""
"Here's how the nodes' bounding boxes should look in the viewport. Keep it "
"rough, you don't need to place them too precisely for now."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:199
msgid "Replace the Label's font"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:201
msgid ""
"The label's font is too small. We need to replace it. Select the ``Number`` "
"node and in the Inspector, scroll down to the ``Control`` class, and find "
"the ``Custom Font`` category. Click the field next to the ``Font`` property "
"and click on ``New Dynamic Font``. Click on the field again and select Edit."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:207
msgid ""
"You will enter the ``Dynamic Font`` resource. Unfold the ``Font`` category "
"and click the field next to ``Font Data``. Click the ``Load`` button. In the "
"file browser, navigate down to the assets/font folder and double click "
"``Comfortaa-Bold.ttf`` to open it. You should see the font update in the "
"viewport. Unfold the settings category to change the font size. Set the "
"``Size`` property to a higher value, like ``24`` or ``28``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:215
msgid ""
"We now need the text's baseline, the number's lower edge, to align with the "
"HP texture on the left. To do so, still in the ``DynamicFont`` resource, you "
"can tweak the ``Bottom`` property under the ``Extra Spacing`` category. It "
"adds some bottom padding to the text. Click the ``Number`` node in the Scene "
"tab to go back to the node's properties and change the ``Valign`` to "
"``Bottom``. To adjust the text's baseline, click on the font field under the "
"``Custom Font`` category again and tweak the ``Bottom`` property until the "
"text aligns with the ``Title`` node. I used a value of ``2`` pixels."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:227
msgid "With a Bottom value of 2 pixels, the Number aligns with the Title"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:229
msgid ""
"With this, we finished the hardest part of the GUI. Congratulations! Let's "
"move on to the simpler nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:233
msgid "Add the progress bar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:235
msgid ""
"We need one last element to complete our life bar: the gauge itself. Godot "
"ships with a ``TextureProgress`` node that has everything we need."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:238
msgid ""
"Select the Bar node and add a ``TextureProgress`` inside of it. Name it "
"``Gauge``. In the inspector unfold the ``Textures`` section. Head to the "
"FileSystem dock and drag and drop the ``lifebar_bg.png`` texture onto the "
"``Under`` slot. Do the same with the ``lifebar_fill.png`` image and drop it "
"onto the ``Progress`` slot. Under the ``Range`` class in the inspector, "
"change the ``Value`` property to ``50`` to see the gauge fill up."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:246
msgid "With only five ``Control`` nodes, our first bar is ready to use."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:250
msgid ""
"That's it, our life bar is ready. This last part was quick, wasn't it? "
"That's thanks to our robust container setup."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:254
msgid "Design the bomb and emerald counters"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:256
msgid ""
"The bomb and emerald counters are like the bar's ``Count`` node. So we'll "
"duplicate it and use it as a template."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:259
msgid ""
"Under the ``Bar`` node, select ``Count`` and press :kbd:`Ctrl + D` to "
"duplicate it. Drag and drop the new node under the ``Counters`` "
"``HBoxContainer`` at the bottom of the scene tree. You should see it resize "
"automatically. Don't worry about this for now, we'll fix the size soon."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:264
msgid ""
"Rename the ``Count2`` node to ``Counter``. Unlike the bars, we want the "
"number to be on the left, and an icon to sit on the right. The setup is the "
"same: we need a background (a ``NinePatchRect``), the title, and the number "
"nodes. The ``Title`` node is a ``TextureRect``, so it's what we need to "
"display the icon. In the scene tree, select the ``Title`` node, and rename "
"it to ``Icon``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:273
msgid "Here's how your node tree should look so far"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:275
msgid ""
"With the ``Icon`` node selected, in the inspector, scroll to the top to see "
"the ``Texture`` slot. Head to the FileSystem dock on the left and select the "
"``bombs_icon.png``. Drag and drop it onto the ``Texture`` slot. In the Scene "
"Tab select both the ``Icon`` and the ``Number`` nodes. Click the Layout menu "
"in the toolbar at the top of the viewport and select ``Full Rect``. Both "
"nodes will update to fit the size of the ``Background``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:285
msgid "The nodes anchor to the entire Background, but their position is off"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:287
msgid ""
"Let's change the ``Number``'s align properties to move it to the left and "
"center of the ``Background``. Select the ``Number`` node, change its "
"``Align`` property to left and the ``Valign`` property to centre. Then "
"resize its left edge a bit to add some padding between the left edge of the "
"``Background`` and the text."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:295
msgid "The Number node aligned to the left and centre"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:297
msgid ""
"To overlap the Icon and the background, we need a few tweaks. First, our "
"background is a bit too tall. It's because it's inside a margin container "
"that is controlled by the top-most GUI node. Select the GUI node at the top "
"of the scene tree and downsize it vertically so that it's as thin as "
"possible. You'll see the gauge prevents you from making it too small. A "
"container cannot be smaller than the minimal size of its children. The "
"container's margins also weigh in."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:305
msgid ""
"Select the Icon, click the Layout menu, and select ``Full Rect`` to re-"
"center it. We need it to anchor to the ``Background``'s right edge. Open the "
"Layout menu again and select ``Center Right``. Move the icon up so it is "
"centered vertically with the ``Background``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:313
msgid ""
"The bomb icon anchors to the Background's right edge. Resize the Counter "
"container to see the Icon node stick to its right side"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:316
msgid ""
"Because we duplicated the ``Counter`` from the bar's ``Count``, the "
"``Number`` node's font is off. Select the ``Number`` node again, head to the "
"``Font`` property, and click it to access the ``DynamicFont`` resource. In "
"the ``Extra Spacing`` section, change the ``Bottom`` value to ``0`` to reset "
"the font's baseline. Our counter now works as expected."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:323
msgid ""
"Let's make the ``Counters`` anchor to the right edge of the viewport. To do "
"so, we need to set the ``Bars`` container take all the available horizontal "
"space it can. Select the ``Bars`` node and scroll down to the ``Size Flags`` "
"category. In the ``Horizontal`` category, check the ``Expand`` value. The "
"``Bars`` node should resize and push the counter to the right side of the "
"screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:331
msgid ""
"An expanding container eats all the space it can from its parent, pushing "
"everything else along the way"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:335
msgid "Turn the bar and counter into reusable UI components"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:337
msgid ""
"We have one bar and one counter widget. But we need two of each. We may need "
"to change the bars' design or their functionality later on. It'd be great if "
"we could have a single scene to store a UI element's template, and child "
"scenes to work on variations. Godot lets us do this with Inherited Scenes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:343
msgid ""
"Let's save both the ``Counter`` and the ``Bar`` branches as separate scenes "
"that we'll reduce to create the ``LifeBar``, the ``EnergyBar``, the "
"``BombCounter``, and the ``EmeraldCounter``. Select the ``Bar`` "
"HBoxContainer. Right click on it and click on ``Save Branch as Scene``. Save "
"the scene as ``Bar.tscn``. You should see the node branch turn it to a "
"single ``Bar`` node."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:352
msgid ""
"A scene is a tree of nodes. The topmost node is the tree's **root**, and the "
"children at the bottom of the hierarchy are **leaves**. Any node other than "
"the root along with one or more children is a **branch**. We can encapsulate "
"node branches into separate scenes, or load and merge them from other scenes "
"into the active one. Right click on any node in the Scene dock and select "
"``Save Branch as Scene`` or ``Merge from Scene``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:360
msgid ""
"Then, select the ``Counter`` node and do the same. Right click, ``Save "
"Branch as Scene``, and save it as ``Counter.tscn``. A new edit scene icon "
"appears to the right of the nodes in the scene tree. Click on the one next "
"to ``Bar`` to open the corresponding scene. Resize the ``Bar`` node so that "
"its bounding box fits its content. The way we named and placed the Control "
"nodes, we're ready to inherit this template and create the life bar. It's "
"the same for the ``Counter``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:370
msgid "With no extra changes, our Bar is ready to use"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:373
msgid "Use scene inheritance to create the remaining elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:375
msgid ""
"We need two bars that work the same way: they should feature a label on the "
"left, with some value, and a horizontal gauge on the right. The only "
"difference is that one has the HP label and is green, while the other is "
"called EP and is yellow. Godot gives us a powerful tool to create a common "
"base to reuse for all bars in the game: **inherited scenes**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:383
msgid ""
"Inherited scenes help us keep the GUI scene clean. In the end, we will only "
"have containers and one node for each UI component."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:386
msgid ""
"On an inherited scene, you can change any property of every node in the "
"inspector, aside from its name. If you modify and save the parent scene, all "
"the inherited scenes update to reflect the changes. If you change a value in "
"the inherited scene, it will always override the parent's property. It's "
"useful for UIs, as they often require variations of the same elements. In "
"general, in UI design, buttons, panels etc. share a common base style and "
"interactions. We don't want to copy it over to all variations manually."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:395
msgid ""
"A reload icon will appear next to the properties you override. Click it to "
"reset the value to the parent scene's default."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:400
msgid ""
"Think of scene inheritance like the node tree, or the ``extends`` keyword in "
"GDScript. An inherited scene does everything like its parent, but you can "
"override properties, resources and add extra nodes and scripts to extend its "
"functionality."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:406
msgid "Inherit the Bar Scene to build the LifeBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:408
msgid ""
"Go to ``Scene -> New Inherited Scene`` to create a new type of ``Bar``. "
"Select the Bar scene and open it. You should see a new [unsaved] tab, that's "
"like your ``Bar``, but with all nodes except the root in grey. Press :kbd:"
"`Ctrl + S` (:kbd:`Cmd + S` on macOS) to save the new inherited scene and "
"name it ``LifeBar``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:416
msgid "You can't rename grey nodes. This tells you they have a parent scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:418
msgid ""
"First, rename the root or top level node to ``LifeBar``. We always want the "
"root to describe exactly what this UI component is. The name differentiates "
"this bar from the ``EnergyBar`` we'll create next. The other nodes inside "
"the scene should describe the component's structure with broad terms, so it "
"works with all inherited scenes. Like our ``TextureProgress`` and ``Number`` "
"nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:427
msgid ""
"If you've ever done web design, it's the same spirit as working with CSS: "
"you create a base class, and add variations with modifier classes. From a "
"base button class, you'll have button-green and button-red variations for "
"the user to accept and refuse prompts. The new class contains the name of "
"the parent element and an extra keyword to explain how it modifies it. When "
"we create an inherited scene and change the name of the top level node, "
"we're doing the same thing."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:436
msgid "Design the EnergyBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:438
msgid ""
"We already setup the ``LifeBar``'s design with the main ``Bar`` scene. Now "
"we need the ``EnergyBar``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:441
msgid ""
"Let's create a new inherited scene, and once again select the ``Bar.tscn`` "
"scene and open it. Double-click on the ``Bar`` root node and rename it to "
"``EnergyBar``. Save the new scene as ``EnergyBar.tscn``. We need to replace "
"the HP texture with EP one, and to change the textures on the gauge."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:447
msgid ""
"Head to the FileSystem dock on the left, select the ``Title`` node in the "
"Scene tree and drag and drop the ``label_EP.png`` file onto the texture "
"slot. Select the ``Number`` node and change the ``Text`` property to a "
"different value like ``14``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:452
msgid ""
"You'll notice the EP texture is smaller than the HP one. We should update "
"the ``Number``'s font size to better fit it. A font is a resource. All the "
"nodes in the entire project that use this resource will be affected by any "
"property we change. You can try to change the size to a huge value like "
"``40`` and switch back to the ``LifeBar`` or the ``Bar`` scenes. You will "
"see the text increased in size."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:461
msgid "If we change the font resource, all the nodes that use it are affected"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:464
msgid ""
"To change the font size on this node only, we must create a copy of the font "
"resource. Select the ``Number`` node again and click on the wrench and "
"screwdriver icon on the top right of the inspector. In the drop-down menu, "
"select the ``Make Sub-Resources Unique`` option. Godot will find all the "
"resources this node uses and create unique copies for us."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:472
msgid "Use this option to create unique copies of the resources for one node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:476
msgid ""
"When you duplicate a node from the Scene tree, with :kbd:`Ctrl + D` (:kbd:"
"`Cmd + D` on macOS), it shares its resources with the original node. You "
"need to use ``Make Sub-Resources Unique`` before you can tweak the resources "
"without affecting the source node."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:481
msgid ""
"Scroll down to the ``Custom Font`` section and open ``Font``. Lower the "
"``Size`` to a smaller value like ``20`` or ``22``. You may also need to "
"adjust the ``Bottom`` spacing value to align the text's baseline with the EP "
"label on the left."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:488
msgid "The EP Count widget, with a smaller font than its HP counterpart"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:490
msgid ""
"Now, select the ``TextureProgress`` node. Drag the ``energy_bar_bg.png`` "
"file onto the ``Under`` slot and do the same for ``energy_bar_fill.png`` and "
"drop it onto the ``Progress`` texture slot."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:494
msgid ""
"You can resize the node vertically so that its bounding rectangle fits the "
"gauge. Do the same with the ``Count`` node until its size aligns with that "
"of the bar. Because the minimal size of ``TextureProgress`` is set based on "
"its textures, you won't be able to downsize the ``Count`` node below that. "
"That is also the size the ``Bar`` container will have. You may downscale "
"this one as well."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:501
msgid ""
"Last but not least, the ``Background`` container has a minimum size that "
"makes it a bit large. Select it and in the ``Rect`` section, change the "
"``Min Size`` property down to ``80`` pixels. It should resize automatically "
"and the ``Title`` and ``Number`` nodes should reposition as well."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:509
msgid "The Count looks better now it's a bit smaller"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:513
msgid ""
"The Count node's size affects the position of the TextureProgress. As we'll "
"align our bars vertically in a moment, we're better off using the Counter's "
"left margin to resize our EP label. This way both the EnergyBar's Count and "
"the LifeBar's Count nodes are one hundred pixels wide, so both gauges will "
"align perfectly."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:520
msgid "Prepare the bomb and emerald counters"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:522
msgid ""
"Let us now take care of the counters. Go to ``Scene -> New Inherited Scene`` "
"and select the ``Counter.tscn`` as a base. Rename the root node as "
"``BombCounter`` too. Save the new scene as ``BombCounter.tscn``. That's all "
"for this scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:529
msgid "The bomb counter is the same as the original Counter scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:531
msgid ""
"Go to ``Scene -> New Inherited Scene`` again and select ``Counter.tscn`` "
"once more. Rename the root node ``EmeraldCounter`` and save the scene as "
"``EmeraldCounter.tscn``. For this one, we mainly need to replace the bomb "
"icon with the emerald icon. In the FileSystem tab, drag the ``emeralds_icon."
"png`` onto the ``Icon`` node's ``Texture`` slot. ``Icon`` already anchors to "
"the right edge of the ``Background`` node so we can change its position and "
"it will scale and reposition with the ``EmeraldCounter`` container. Shift "
"the emerald icon a bit to the right and down. Use the Arrow Keys on the "
"keyboard to nudge its position. Save, and we're done with all the UI "
"elements."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:544
msgid "The emerald counter should look something like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:547
msgid "Add the UI components to the final GUI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:549
msgid ""
"Time to add all the UI elements to the main GUI scene. Open the ``GUI.tscn`` "
"scene again, and delete the ``Bar`` and ``Counter`` nodes. In the FileSystem "
"dock, find the ``LifeBar.tscn`` and drag and drop it onto the ``Bars`` "
"container in the scene tree. Do the same for the ``EnergyBar``. You should "
"see them align vertically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:557
msgid "The LifeBar and the EnergyBar align automatically"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:559
msgid ""
"Now, drag and drop the ``BombCounter.tscn`` and ``EmeraldCounter.tscn`` "
"scenes onto the ``Counters`` node. They'll resize automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:564
msgid "The nodes resize to take all the available vertical space"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:566
msgid ""
"To let the ``EmeraldCounter`` and ``BombCounter`` use the size we defined in "
"``Counter.tscn``, we need to change the ``Size Flags`` on the ``Counters`` "
"container. Select the ``Counters`` node and unfold the ``Size Flags`` "
"section in the Inspector. Uncheck the ``Fill`` tag for the ``Vertical`` "
"property, and check ``Shrink Center`` so the container centers inside the "
"``HBoxContainer``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:575
msgid "Now both counters have a decent size"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:579
msgid ""
"Change the ``Min Size`` property of the ``Counters`` container to control "
"the height of the counters' background."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:582
msgid ""
"We have one small issue left with the EP label on the EnergyBar: the 2 bars "
"should align vertically. Click the icon next to the ``EnergyBar`` node to "
"open its scene. Select the ``Count`` node and scroll down to the ``Custom "
"Constants`` section. Add a ``Margin Left`` of ``20``. In the ``Rect`` "
"section set the node's ``Min Size`` back to 100, the same value as on the "
"LifeBar. The ``Count`` should now have some margin on the left. If you save "
"and go back to the GUI scene, it will be aligned vertically with the "
"``LifeBar``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:593
msgid "The 2 bars align perfectly"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:597
msgid ""
"We could have set up the ``EnergyBar`` this way a few moments ago. But this "
"shows you that you can go back to any scene anytime, tweak it, and see the "
"changes propagate through the project!"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:602
msgid "Place the GUI onto the game's mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:604
msgid ""
"To wrap up the tutorial we're going to insert the GUI onto the game's mockup "
"scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:607
msgid "Head to the FileSystem dock and open ``LevelMockup.tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:609
msgid ""
"Drag-and-drop the ``GUI.tscn`` scene right below the ``bg`` node and above "
"the ``Characters``. The GUI will scale to fit the entire viewport. Head to "
"the Layout menu and select the ``Center Top`` option so it anchors to the "
"top edge of the game window. Then resize the GUI to make it as small as "
"possible vertically. Now you can see how the interface looks in the context "
"of the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:616
msgid ""
"Congratulations for getting to the end of this long tutorial. You can find "
"the final project here: :download:`ui_gui_design.zip <files/ui_gui_design."
"zip>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:625
msgid ""
"**A final note about Responsive Design**. If you resize the GUI, you'll see "
"the nodes move, but the textures and text won't scale. The GUI also has a "
"minimum size, based on the textures inside of it. In games, we don't need "
"the interface to be as flexible as that of a website. You almost never want "
"to support both landscape and portrait screen orientations. It's one or the "
"other. In landscape orientation, the most common ratios range from 4:3 to "
"16:9. They are close to one another. That's why it's enough for the GUI "
"elements to only move horizontally when we change the window size."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:4
msgid "Control the game's UI with code"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:7
#: ../../docs/tutorials/2d/particle_systems_2d.rst:7
msgid "Intro"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:9
msgid ""
"In this tutorial, you will connect a character to a life bar and animate the "
"health loss."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:14
msgid ""
"Here's what you'll create: the bar and the counter animate when the "
"character takes a hit. They fade when it dies."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:18
msgid "You will learn:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:20
msgid "How to **connect** a character to a GUI with signals"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:21
msgid "How to **control** a GUI with GDscript"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:22
msgid "How to **animate** a life bar with the :ref:`Tween <class_Tween>` node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:25
msgid ""
"If you want to learn how to set up the interface instead, check out the step-"
"by-step UI tutorials:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:28
msgid ":doc:`ui_main_menu`"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:29
msgid ":doc:`ui_game_user_interface`"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:32
msgid ""
"When you code a game, you want to build the core gameplay first: the main "
"mechanics, player input, win and loss conditions. The UI comes a bit later. "
"You want to keep all the elements that make up your project separate if "
"possible. Each character should be in its own scene, with its own scripts, "
"and so should the UI elements. This prevents bugs, keeps your project "
"manageable, and allows different team members to work on different parts of "
"the game."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:40
msgid ""
"Once the core gameplay and the UI are ready, you'll need to connect them "
"somehow. In our example, we have the Enemy who attacks the Player at "
"constant time intervals. We want the life bar to update when the Player "
"takes damage."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:45
msgid "To do this, we will use **signals**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:49
msgid ""
"Signals are Godot's version of the Observer pattern. They allow us to send "
"out some message. Other nodes can connect to the object that **emits** the "
"signal and receive the information. It's a powerful tool we use a lot for "
"User Interface and achievement systems. You don't want to use them "
"everywhere, though. Connecting two nodes adds some coupling between them. "
"When there's a lot of connections, they become hard to manage. For more "
"information, check out the `signals video tutorial <https://youtu.be/"
"l0BkQxF7X3E>`_ on GDquest."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:53
msgid "Download and explore the start project"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:55
msgid ""
"Download the Godot project: :download:`ui_code_life_bar.zip <files/"
"ui_code_life_bar.zip>`. It contains all the assets and scripts you need to "
"get started. Extract the .zip archive to get two folders: `start` and `end`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:58
msgid ""
"Load the ``start`` project in Godot. In the ``FileSystem`` dock, double "
"click on LevelMockup.tscn to open it. It's an RPG game's mockup where 2 "
"characters face each other. The pink enemy attacks and damages the green "
"square at regular time intervals, until its death. Feel free to try out the "
"game: the basic combat mechanics already work. But as the character isn't "
"connected to the life bar, the ``GUI`` doesn't do anything."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:68
msgid ""
"This is typical of how you'd code a game: you implement the core gameplay "
"first, handle the player's death, and only then you'll add the interface. "
"That's because the UI listens to what's happening in the game. So it can't "
"work if other systems aren't in place yet. If you design the UI before you "
"prototype and test the gameplay, chances are it won't work well and you'll "
"have to re-create it from scratch."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:71
msgid "The scene contains a background sprite, a GUI, and two characters."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:75
msgid "The scene tree, with the GUI scene set to display its children"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:77
msgid ""
"The GUI scene encapsulates all of the game's Graphical User Interface. It "
"comes with a barebones script where we get the path to nodes that exist "
"inside the scene:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:105
msgid ""
"``number_label`` displays a life count as a number. It's a ``Label`` node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:107
msgid "``bar`` is the life bar itself. It's a ``TextureProgress`` node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:108
msgid ""
"``tween`` is a component-style node that can animate and control any value "
"or method from any other node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:113
msgid ""
"The project uses a simple organization that works for game jams and tiny "
"games."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:115
msgid ""
"At the root of the project, in the `res://` folder, you will find the "
"`LevelMockup`. That's the main game scene and the one we will work with. All "
"the components that make up the game are in the `scenes/` folder. The "
"`assets/` folder contains the game sprites and the font for the HP counter. "
"In the `scripts/` folder you will find the enemy, the player, and the GUI "
"controller scripts."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:117
msgid ""
"Click the edit scene icon to the right of the node in the scene tree to open "
"the scene in the editor. You'll see the LifeBar and EnergyBar are sub-scenes "
"themselves."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:121
msgid "The scene tree, with the Player scene set to display its children"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:124
msgid "Set up the Lifebar with the Player's max\\_health"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:126
msgid ""
"We have to tell the GUI somehow what the player's current health is, to "
"update the lifebar's texture, and to display the remaining health in the HP "
"counter in the top left corner of the screen. To do this we send the "
"player's health to the GUI every time they take damage. The GUI will then "
"update the ``Lifebar`` and ``Number`` nodes with this value."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:132
msgid ""
"We could stop here to display the number, but we need to initialize the "
"bar's ``max_value`` for it to update in the right proportions. The first "
"step is thus to tell the ``GUI`` what the green character's ``max_health`` "
"is."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:139
msgid ""
"The bar, a `TextureProgress`, has a `max_value` of `100` by default. If you "
"don't need to display the character's health with a number, you don't need "
"to change its `max_value` property. You send a percentage from the `Player` "
"to the `GUI` instead:  `health / max_health * 100`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:143
msgid ""
"Click the script icon to the right of the ``GUI`` in the Scene dock to open "
"its script. In the ``_ready`` function, we're going to store the "
"``Player``'s ``max_health`` in a new variable and use it to set the "
"``bar``'s ``max_value``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:164
msgid ""
"Let's break it down. ``$\"../Characters/Player\"`` is a shorthand that goes "
"one node up in the scene tree, and retrieves the ``Characters/Player`` node "
"from there. It gives us access to the node. The second part of the "
"statement, ``.max_health``, accesses the ``max_health`` on the Player node."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:170
msgid ""
"The second line assigns this value to ``bar.max_value``. You could combine "
"the two lines into one, but we'll need to use ``player_max_health`` again "
"later in the tutorial."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:174
msgid ""
"``Player.gd`` sets the ``health`` to ``max_health`` at the start of the "
"game, so we could work with this. Why do we still use ``max_health``? There "
"are two reasons:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:178
msgid ""
"We don't have the guarantee that ``health`` will always equal "
"``max_health``: a future version of the game may load a level where the "
"player already lost some health."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:184
msgid ""
"When you open a scene in the game, Godot creates nodes one by one, following "
"the order in your Scene dock, from top to bottom. `GUI` and `Player` are not "
"part of the same node branch. To make sure they both exist when we access "
"each other, we have to use the `_ready` function. Godot calls `_ready` right "
"after it loaded all nodes, before the game starts. It's the perfect function "
"to set everything up and prepare the game session. Learn more about _ready: :"
"doc:`scripting_continued`"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:188
msgid "Update health with a signal when the player takes a hit"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:190
msgid ""
"Our GUI is ready to receive the ``health`` value updates from the "
"``Player``. To achieve this we're going to use **signals**."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:195
msgid ""
"There are many useful built-in signals like `enter_tree` and `exit_tree`, "
"that all nodes emit when they are respectively created and destroyed. You "
"can also create your own using the `signal` keyword. On the `Player` node, "
"you'll find two signals we created for you: `died` and `health_changed`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:197
msgid ""
"Why don't we directly get the ``Player`` node in the ``_process`` function "
"and look at the health value? Accessing nodes this way creates tight "
"coupling between them. If you did it sparingly it may work. As your game "
"grows bigger, you may have many more connections. If you get nodes this way "
"it gets complex quickly. Not only that: you need to listen to the state "
"change constantly in the ``_process`` function. This check happens 60 times "
"a second and you'll likely break the game because of the order in which the "
"code runs."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:206
msgid ""
"On a given frame you may look at another node's property *before* it was "
"updated: you get a value from the last frame. This leads to obscure bugs "
"that are hard to fix. On the other hand, a signal is emitted right after a "
"change happened. It **guarantees** you're getting a fresh piece of "
"information. And you will update the state of your connected node *right "
"after* the change happened."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:215
msgid ""
"The Observer pattern, that signals derive from, still adds a bit of coupling "
"between node branches. But it's generally lighter and more secure than "
"accessing nodes directly to communicate between two separate classes. It can "
"be okay for a parent node to get values from its children. But you'll want "
"to favor signals if you're working with two separate branches. Read Game "
"Programming Patterns for more information on the `Observer pattern <https://"
"gameprogrammingpatterns.com/observer.html>`_. The `full book <https://"
"gameprogrammingpatterns.com/contents.html>`_ is available online for free."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:219
msgid ""
"With this in mind, let's connect the ``GUI`` to the ``Player``. Click on the "
"``Player`` node in the scene dock to select it. Head down to the Inspector "
"and click on the Node tab. This is the place to connect nodes to listen to "
"the one you selected."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:224
msgid "The first section lists custom signals defined in ``Player.gd``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:226
msgid ""
"``died`` is emitted when the character died. We will use it in a moment to "
"hide the UI."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:228
msgid "``health_changed`` is emitted when the character got hit."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:232
msgid "We're connecting to the health\\_changed signal"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:234
msgid ""
"Select ``health_changed`` and click on the Connect button in the bottom "
"right corner to open the Connect Signal window. On the left side you can "
"pick the node that will listen to this signal. Select the ``GUI`` node. The "
"right side of the screen lets you pack optional values with the signal. We "
"already took care of it in ``Player.gd``. In general I recommend not to add "
"too many arguments using this window as they're less convenient than doing "
"it from the code."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:244
msgid "The Connect Signal window with the GUI node selected"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:248
msgid ""
"You can optionally connect nodes from the code. However doing it from the "
"editor has two advantages:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:250
msgid "Godot can write new callback functions for you in the connected script"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:251
msgid ""
"An emitter icon appears next to the node that emits the signal in the Scene "
"dock"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:253
msgid ""
"At the bottom of the window you will find the path to the node you selected. "
"We're interested in the second row called \"Method in Node\". This is the "
"method on the ``GUI`` node that gets called when the signal is emitted. This "
"method receives the values sent with the signal and lets you process them. "
"If you look to the right, there is a \"Make Function\" radio button that is "
"on by default. Click the connect button at the bottom of the window. Godot "
"creates the method inside the ``GUI`` node. The script editor opens with the "
"cursor inside a new ``_on_Player_health_changed`` function."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:265
msgid ""
"When you connect nodes from the editor, Godot generates a method name with "
"the following pattern: ``_on_EmitterName_signal_name``. If you wrote the "
"method already, the \"Make Function\" option will keep it. You may replace "
"the name with anything you'd like."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:272
msgid "Godot writes the callback method for you and takes you to it"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:274
msgid ""
"Inside the parentheses after the function name, add a ``player_health`` "
"argument. When the player emits the ``health_changed`` signal, it will send "
"its current ``health`` alongside it. Your code should look like:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:292
msgid ""
"The engine does not convert PascalCase to snake_case, for C# examples we'll "
"be using PascalCase for method names & camelCase for method parameters, "
"which follows the official `C# naming conventions. <https://docs.microsoft."
"com/en-us/dotnet/standard/design-guidelines/capitalization-conventions>`_"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:299
msgid ""
"In Player.gd, when the Player emits the health\\_changed signal, it also "
"sends its health value"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:302
msgid ""
"Inside ``_on_Player_health_changed``, let's call a second function called "
"``update_health`` and pass it the ``player_health`` variable."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:307
msgid ""
"We could directly update the health value on `LifeBar` and `Number`. There "
"are two reasons to use this method instead:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:309
msgid ""
"The name makes it clear for our future selves and teammates that when the "
"player took damage, we update the health count on the GUI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:310
msgid "We will reuse this method a bit later"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:312
msgid ""
"Create a new ``update_health`` method below ``_on_Player_health_changed``. "
"It takes a new\\_value as its only argument:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327
msgid "This method needs to:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:329
msgid ""
"set the ``Number`` node's ``text`` to ``new_value`` converted to a string"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:331
msgid "set the ``TextureProgress``'s ``value`` to ``new_value``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:350
msgid ""
"``str`` is a built-in function that converts about any value to text. "
"``Number``'s ``text`` property requires a string, so we can't assign it to "
"``new_value`` directly"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:354
msgid ""
"Also call ``update_health`` at the end of the ``_ready`` function to "
"initialize the ``Number`` node's ``text`` with the right value at the start "
"of the game. Press :kbd:`F5` to test the game: the life bar updates with "
"every attack!"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:361
msgid ""
"Both the Number node and the TextureProgress update when the Player takes a "
"hit"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:365
msgid "Animate the loss of life with the Tween node"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:367
msgid ""
"Our interface is functional, but it could use some animation. That's a good "
"opportunity to introduce the ``Tween`` node, an essential tool to animate "
"properties. ``Tween`` animates anything you'd like from a start to an end "
"state over a certain duration. For example, it can animate the health on the "
"``TextureProgress`` from its current level to the ``Player``'s new "
"``health`` when the character takes damage."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:374
msgid ""
"The ``GUI`` scene already contains a ``Tween`` child node stored in the "
"``tween`` variable. Let's now use it. We have to make some changes to "
"``update_health``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:378
msgid ""
"We will use the ``Tween`` node's ``interpolate_property`` method. It takes "
"seven arguments:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:381
msgid "A reference to the node who owns the property to animate"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:382
msgid "The property's identifier as a string"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:383
msgid "The starting value"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:384
msgid "The end value"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:385
msgid "The animation's duration in seconds"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:386
msgid "The type of the transition"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:387
msgid "The easing to use in combination with the equation."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:389
msgid ""
"The last two arguments combined correspond to an easing equation. This "
"controls how the value evolves from the start to the end point."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:393
msgid ""
"Click the script icon next to the ``GUI`` node to open it again. The "
"``Number`` node needs text to update itself, and the ``Bar`` needs a float "
"or an integer. We can use ``interpolate_property`` to animate a number, but "
"not to animate text directly. We're going to use it to animate a new ``GUI`` "
"variable named ``animated_health``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:399
msgid ""
"At the top of the script, define a new variable, name it "
"``animated_health``, and set its value to 0. Navigate back to the "
"``update_health`` method and clear its content. Let's animate the "
"``animated_health`` value. Call the ``Tween`` node's "
"``interpolate_property`` method:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:421
msgid "Let's break down the call:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:427
msgid ""
"We target ``animated_health`` on ``self``, that is to say the ``GUI`` node. "
"``Tween``'s interpolate\\_property takes the property's name as a string. "
"That's why we write it as ``\"animated_health\"``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:435
msgid ""
"The starting point is the current value the bar's at. We still have to code "
"this part, but it's going to be ``animated_health``. The end point of the "
"animation is the ``Player``'s ``health`` after the ``health_changed``: "
"that's ``new_value``. And ``0.6`` is the animation's duration in seconds."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:441
msgid ""
"The animation will not play until we activated the ``Tween`` node with "
"``tween.start()``. We only have to do this once if the node is not active. "
"Add this code after the last line:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:460
msgid ""
"Although we could animate the `health` property on the `Player`, we "
"shouldn't. Characters should lose life instantly when they get hit. It makes "
"it a lot easier to manage their state, like to know when one died. You "
"always want to store animations in a separate data container or node. The "
"`tween` node is perfect for code-controlled animations. For hand-made "
"animations, check out `AnimationPlayer`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:463
msgid "Assign the animated\\_health to the LifeBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:465
msgid ""
"Now the ``animated_health`` variable animates but we don't update the actual "
"``Bar`` and ``Number`` nodes anymore. Let's fix this."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:468
msgid "So far, the update\\_health method looks like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:492
msgid ""
"In this specific case, because ``number_label`` takes text, we need to use "
"the ``_process`` method to animate it. Let's now update the ``Number`` and "
"``TextureProgress`` nodes like before, inside of ``_process``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:514
msgid ""
"`number_label` and `bar` are variables that store references to the `Number` "
"and `TextureProgress` nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:516
msgid ""
"Play the game to see the bar animate smoothly. But the text displays decimal "
"number and looks like a mess. And considering the style of the game, it'd be "
"nice for the life bar to animate in a choppier fashion."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:522
msgid "The animation is smooth, but the number is broken"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:524
msgid ""
"We can fix both problems by rounding out ``animated_health``. Use a local "
"variable named ``round_value`` to store the rounded ``animated_health``. "
"Then assign it to ``number_label.text`` and ``bar.value``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:546
msgid "Try the game again to see a nice blocky animation."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:550
msgid "By rounding out animated\\_health, we kill two birds with one stone"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:554
msgid ""
"Every time the player takes a hit, the ``GUI`` calls "
"``_on_Player_health_changed``, which in turn calls ``update_health``. This "
"updates the animation and the ``number_label`` and ``bar`` follow in "
"``_process``. The animated life bar that shows the health going down "
"gradually is a trick. It makes the GUI feel alive. If the ``Player`` takes 3 "
"damage, it happens in an instant."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:562
msgid "Fade the bar when the Player dies"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:564
msgid ""
"When the green character dies, it plays a death animation and fades out. At "
"this point, we shouldn't show the interface anymore. Let's fade the bar as "
"well when the character died. We will reuse the same ``Tween`` node as it "
"manages multiple animations in parallel for us."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:569
msgid ""
"First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to "
"know when it died. Press :kbd:`F1` to jump back to the 2D Workspace. Select "
"the ``Player`` node in the Scene dock and click on the Node tab next to the "
"Inspector."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:574
msgid "Find the ``died`` signal, select it, and click the Connect button."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:578
msgid "The signal should already have the Enemy connected to it"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:580
msgid ""
"In the Connecting Signal window, connect to the ``GUI`` node again. The Path "
"to Node should be ``../../GUI`` and the Method in Node should show "
"``_on_Player_died``. Leave the Make Function option on and click Connect at "
"the bottom of the window. This will take you to the ``GUI.gd`` file in the "
"Script Workspace."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:588
msgid "You should get these values in the Connecting Signal window"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:592
msgid ""
"You should see a pattern by now: every time the GUI needs a new piece of "
"information, we emit a new signal. Use them wisely: the more connections you "
"add, the harder they are to track."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:594
msgid ""
"To animate a fade on a UI element, we have to use its ``modulate`` property. "
"``modulate`` is a ``Color`` that multiplies the colors of our textures."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:600
msgid ""
"`modulate` comes from the `CanvasItem` class, All 2D and UI nodes inherit "
"from it. It lets you toggle the visibility of the node, assign a shader to "
"it, and modify it using a color with `modulate`."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:602
msgid ""
"``modulate`` takes a ``Color`` value with 4 channels: red, green, blue and "
"alpha. If we darken any of the first three channels it darkens the "
"interface. If we lower the alpha channel, our interface fades out."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:606
msgid ""
"We're going to tween between two color values: from a white with an alpha of "
"``1``, that is to say at full opacity, to a pure white with an alpha value "
"of ``0``, completely transparent. Let's add two variables at the top of the "
"``_on_Player_died`` method and name them ``start_color`` and ``end_color``. "
"Use the ``Color()`` constructor to build two ``Color`` values."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:628
msgid ""
"``Color(1.0, 1.0, 1.0)`` corresponds to white. The fourth argument, "
"respectively ``1.0`` and ``0.0`` in ``start_color`` and ``end_color``, is "
"the alpha channel."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:632
msgid ""
"We then have to call the ``interpolate_property`` method of the ``Tween`` "
"node again:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:645
msgid ""
"This time, we change the ``modulate`` property and have it animate from "
"``start_color`` to the ``end_color``. The duration is of one second, with a "
"linear transition. Here's the complete ``_on_Player_died`` method:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:669
msgid "And that is it. You may now play the game to see the final result!"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:673
msgid "The final result. Congratulations for getting there!"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:677
msgid ""
"Using the exact same techniques, you can change the color of the bar when "
"the Player gets poisoned, turn the bar red when its health drops low, shake "
"the UI when they take a critical hit... the principle is the same: emit a "
"signal to forward the information from the `Player` to the `GUI` and let the "
"`GUI` process it."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:4
msgid "Splash screen"
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:7
msgid "Tutorial"
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:9
msgid ""
"This is a simple tutorial to establish the basic idea of how the GUI "
"subsystem works. The goal is to create a simple, static splash screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:15
msgid ""
"Following is a file with the assets that will be used. The extracted files "
"can be placed directly in your project folder and Godot will import them "
"automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:18
msgid ":download:`robisplash_assets.zip <files/robisplash_assets.zip>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:21
#: ../../docs/tutorials/3d/reflection_probes.rst:21
#: ../../docs/tutorials/3d/gi_probes.rst:36
#: ../../docs/tutorials/3d/baked_lightmaps.rst:40
#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:53
msgid "Setting up"
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:23
msgid ""
"Set the display resolution to 800x450 in Project Settings, and set up a new "
"scene like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:27
msgid ""
"The nodes \"background\" and \"logo\" are of :ref:`TextureRect "
"<class_TextureRect>` type. To display an image, drag the corresponding asset "
"to the texture property."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:32
msgid ""
"The node \"start\" is a :ref:`TextureButton <class_TextureButton>`. It takes "
"several images for different states, but only the normal and pressed will be "
"supplied in this example:"
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:38
msgid "Finally, the node \"copyright\" is a :ref:`Label <class_Label>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:40
msgid "Your final scene should look something like this."
msgstr ""

#: ../../docs/getting_started/step_by_step/splash_screen.rst:44
msgid ""
"Go ahead and run the project.  If you're satisfied with the results, "
"continue to the next tutorial."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:4
msgid "Animations"
msgstr "אנימציות"

#: ../../docs/getting_started/step_by_step/animations.rst:9
msgid "Godot's animation system is extremely powerful and flexible."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:11
msgid ""
"To begin, let's use the scene from the previous tutorial (:ref:"
"`doc_splash_screen`). The goal is to add a \"fade-in\" animation to the "
"splash image. Here's a copy just in case: :download:`robisplash.zip <files/"
"robisplash.zip>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:16
msgid "Add an animation player"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:18
msgid ""
"First of all, add an :ref:`AnimationPlayer <class_AnimationPlayer>` node to "
"the scene as a child of \"background\" (the root node):"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:23
msgid ""
"When a node of this type is selected, the animation editor panel will appear:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:28
msgid "The animation editor panel stays visible until manually hidden."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:31
msgid "Creating the animation"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:33
msgid ""
"It's time to create a new animation! Press the Animation button then select "
"new from the menu. Name the animation \"intro\" when the dialog appears."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:40
msgid ""
"Now that we have an animation, the property editor enters \"animation editing"
"\" mode. In this mode, a key icon appears next to every property of the "
"property editor. In Godot, any property of an object can be animated:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:48
msgid "Editing the animation"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:50
msgid "The logo will appear from the top of the screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:52
msgid ""
"With the animation editor panel open, select the \"logo\" node and set the "
"\"Rect / Position\" property to ``(118, -400)`` and press the key button "
"next to the property to add a keyframe:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:58
msgid "When the dialog appears, confirm that you are creating a new track."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:60
msgid "The keyframe will be added in the animation player editor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:64
msgid "Move the editor cursor forward in time by clicking here:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:68
msgid ""
"Change the logo position to ``(118, 0)`` and add a keyframe again. With two "
"keyframes with different values, the animation happens."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:73
msgid ""
"Pressing \"Play selected animation from start\" button on the animation "
"panel (or :kbd:`Shift + D` on keyboard) will make the logo descend."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:78
msgid ""
"Click the \"Autoplay on Load\" button to set the animation to start "
"automatically when the scene starts."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:83
msgid ""
"And finally, when running the scene, the animation should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:4
#: ../../docs/tutorials/threads/thread_safe_apis.rst:58
#: ../../docs/development/file_formats/tscn.rst:257
#: ../../docs/community/tutorials.rst:53
msgid "Resources"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:7
msgid "Nodes and resources"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:9
msgid ""
"Up to this tutorial, we focused on the :ref:`Node <class_Node>` class in "
"Godot as that's the one you use to code behavior and most of the engine's "
"features rely on it. There is another datatype that is just as important: :"
"ref:`Resource <class_Resource>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:15
msgid ""
"*Nodes* give you functionality: they draw sprites, 3D models, simulate "
"physics, arrange user interfaces, etc. **Resources** are **data "
"containers**. They don't do anything on their own: instead, nodes use the "
"data contained in resources."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:19
msgid ""
"Anything Godot saves or loads from disk is a resource. Be it a scene (a ``."
"tscn`` or an ``.scn`` file), an image, a script... Here are some "
"``Resource`` examples: :ref:`Texture <class_Texture>`, :ref:`Script "
"<class_Script>`, :ref:`Mesh <class_Mesh>`, :ref:`Animation "
"<class_Animation>`, :ref:`AudioStream <class_AudioStream>`, :ref:`Font "
"<class_Font>`, :ref:`Translation <class_Translation>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:26
msgid ""
"When the engine loads a resource from disk, **it only loads it once**. If a "
"copy of that resource is already in memory, trying to load the resource "
"again will return the same copy every time. As resources only contain data, "
"there is no need to duplicate them."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:31
msgid ""
"Every object, be it a Node or a Resource, can export properties. There are "
"many types of Properties, like String, integer, Vector2, etc., and any of "
"these types can become a resource. This means that both nodes and resources "
"can contain resources as properties:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:39
msgid "External vs built-in"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:41
msgid "There are two ways to save resources. They can be:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:43
msgid "**External** to a scene, saved on the disk as individual files."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:44
msgid ""
"**Built-in**, saved inside the ``.tscn`` or the ``.scn`` file they're "
"attached to."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:46
msgid ""
"To be more specific, here's a :ref:`Texture <class_Texture>` in a :ref:"
"`Sprite <class_Sprite>` node:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:51
msgid ""
"Clicking the resource preview allows us to view and edit the resource's "
"properties."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:55
msgid ""
"The path property tells us where the resource comes from. In this case, it "
"comes from a PNG image called ``robi.png``. When the resource comes from a "
"file like this, it is an external resource. If you erase the path or this "
"path is empty, it becomes a built-in resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:60
msgid ""
"The switch between built-in and external resources happens when you save the "
"scene. In the example above, if you erase the path ``\"res://robi.png\"`` "
"and save, Godot will save the image inside the ``.tscn`` scene file."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:66
msgid ""
"Even if you save a built-in resource, when you instance a scene multiple "
"times, the engine will only load one copy of it."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:70
msgid "Loading resources from code"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:72
msgid ""
"There are two ways to load resources from code. First, you can use the "
"``load()`` function anytime:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:90
msgid ""
"You can also ``preload`` resources. Unlike ``load``, this function will read "
"the file from disk and load it at compile-time. As a result, you cannot call "
"preload with a variable path: you need to use a constant string."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:106
msgid "Loading scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:108
msgid ""
"Scenes are also resources, but there is a catch. Scenes saved to disk are "
"resources of type :ref:`PackedScene <class_PackedScene>`. The scene is "
"packed inside a resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:112
msgid ""
"To get an instance of the scene, you have to use the :ref:`PackedScene."
"instance() <class_PackedScene_method_instance>` method."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:133
msgid ""
"This method creates the nodes in the scene's hierarchy, configures them, and "
"returns the root node of the scene. You can then add it as a child of any "
"other node."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:137
msgid ""
"The approach has several advantages. As the :ref:`PackedScene.instance() "
"<class_PackedScene_method_instance>` function is fast, you can create new "
"enemies, bullets, effects, etc. without having to load them again from disk "
"each time. Remember that, as always, images, meshes, etc. are all shared "
"between the scene instances."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:144
msgid "Freeing resources"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:146
msgid ""
"When a ``Resource`` is no longer in use, it will automatically free itself. "
"Since, in most cases, Resources are contained in Nodes, when you free a "
"node, the engine frees all the resources it owns as well if no other node "
"uses them."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:151
msgid "Creating your own resources"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:153
msgid ""
"Like any Object in Godot, users can also script Resources. Resource scripts "
"inherit the ability to freely translate between object properties and "
"serialized text or binary data (\\*.tres, \\*.res). They also inherit the "
"reference-counting memory management from the Reference type."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:158
msgid ""
"This comes with many distinct advantages over alternative data structures, "
"such as JSON, CSV, or custom TXT files. Users can only import these assets "
"as a :ref:`Dictionary <class_Dictionary>` (JSON) or as a :ref:`File "
"<class_File>` to parse. What sets Resources apart is their inheritance of :"
"ref:`Object <class_Object>`, :ref:`Reference <class_Reference>`, and :ref:"
"`Resource <class_Resource>` features:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:165
msgid ""
"They can define constants, so constants from other data fields or objects "
"are not needed."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:167
msgid ""
"They can define methods, including setter/getter methods for properties. "
"This allows for abstraction and encapsulation of the underlying data. If the "
"Resource script's structure needs to change, the game using the Resource "
"need not also change."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:169
msgid ""
"They can define signals, so Resources can trigger responses to changes in "
"the data they manage."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:171
msgid ""
"They have defined properties, so users know 100% that their data will exist."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:173
msgid ""
"Resource auto-serialization and deserialization is a built-in Godot Engine "
"feature. Users do not need to implement custom logic to import/export a "
"resource file's data."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:175
msgid ""
"Resources can even serialize sub-Resources recursively, meaning users can "
"design even more sophisticated data structures."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:177
msgid ""
"Users can save Resources as version-control-friendly text files (\\*.tres). "
"Upon exporting a game, Godot serializes resource files as binary files (\\*."
"res) for increased speed and compression."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:179
msgid ""
"Godot Engine's Inspector renders and edits Resource files out-of-the-box. As "
"such, users often do not need to implement custom logic to visualize or edit "
"their data. To do so, double-click the resource file in the FileSystem dock "
"or click the folder icon in the Inspector and open the file in the dialog."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:181
msgid ""
"They can extend **other** resource types besides just the base Resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:183
msgid "Godot makes it easy to create custom Resources in the Inspector."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:185
msgid ""
"Create a plain Resource object in the Inspector. This can even be a type "
"that derives Resource, so long as your script is extending that type."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:186
msgid "Set the ``script`` property in the Inspector to be your script."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:188
msgid ""
"The Inspector will now display your Resource script's custom properties. If "
"one edits those values and saves the resource, the Inspector serializes the "
"custom properties too! To save a resource from the Inspector, click the "
"Inspector's tools menu (top right), and select \"Save\" or \"Save As...\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:193
msgid ""
"If the script's language supports :ref:`script classes "
"<doc_scripting_continued_class_name>`, then it streamlines the process. "
"Defining a name for your script alone will add it to the Inspector's "
"creation dialog. This will auto-add your script to the Resource object you "
"create."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:198
msgid "Let's see some examples."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:271
msgid ""
"Resource scripts are similar to Unity's ScriptableObjects. The Inspector "
"provides built-in support for custom resources. If desired though, users can "
"even design their own Control-based tool scripts and combine them with an :"
"ref:`EditorPlugin <class_EditorPlugin>` to create custom visualizations and "
"editors for their data."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:277
msgid ""
"Unreal Engine 4's DataTables and CurveTables are also easy to recreate with "
"Resource scripts. DataTables are a String mapped to a custom struct, similar "
"to a Dictionary mapping a String to a secondary custom Resource script."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:313
msgid ""
"Instead of just inlining the Dictionary values, one could also, "
"alternatively..."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:315
msgid ""
"Import a table of values from a spreadsheet and generate these key-value "
"pairs, or..."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:317
msgid ""
"Design a visualization within the editor and create a simple plugin that "
"adds it to the Inspector when you open these types of Resources."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:320
msgid ""
"CurveTables are the same thing, except mapped to an Array of float values or "
"a :ref:`Curve <class_Curve>`/:ref:`Curve2D <class_Curve2D>` resource object."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:325
msgid ""
"Beware that resource files (\\*.tres/\\*.res) will store the path of the "
"script they use in the file. When loaded, they will fetch and load this "
"script as an extension of their type. This means that trying to assign a "
"subclass, i.e. an inner class of a script (such as using the ``class`` "
"keyword in GDScript) won't work. Godot will not serialize the custom "
"properties on the script subclass properly."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:331
msgid ""
"In the example below, Godot would load the ``Node`` script, see that it "
"doesn't extend ``Resource``, and then determine that the script failed to "
"load for the Resource object since the types are incompatible."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:4
msgid "File system"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:9
msgid ""
"A file system manages how assets are stored and how they are accessed. A "
"well-designed file system also allows multiple developers to edit the same "
"source files and assets while collaborating. Godot stores all assets as "
"files in its file system."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:15
msgid "Implementation"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:17
msgid ""
"The file system stores resources on disk. Anything, from a script, to a "
"scene or a PNG image is a resource to the engine. If a resource contains "
"properties that reference other resources on disk, the paths to those "
"resources are also included. If a resource has sub-resources that are built-"
"in, the resource is saved in a single file together with all the bundled sub-"
"resources. For example, a font resource is often bundled together with the "
"font textures."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:24
msgid ""
"The Godot file system avoids using metadata files. Existing asset managers "
"and VCSs are better than anything we can implement, so Godot tries its best "
"to play along with SVN, Git, Mercurial, Perforce, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:28
msgid "Example of file system contents:"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:39
msgid "project.godot"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:41
msgid ""
"The ``project.godot`` file is the project description file, and it is always "
"found at the root of the project. In fact, its location defines where the "
"root is. This is the first file that Godot looks for when opening a project."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:45
msgid ""
"This file contains the project configuration in plain text, using the win."
"ini format. Even an empty ``project.godot`` can function as a basic "
"definition of a blank project."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:50
msgid "Path delimiter"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:52
msgid ""
"Godot only supports ``/`` as a path delimiter. This is done for portability "
"reasons. All operating systems support this, even Windows, so a path such as "
"``C:\\project\\project.godot`` needs to be typed as ``C:/project/project."
"godot``."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:58
#: ../../docs/tutorials/io/data_paths.rst:16
msgid "Resource path"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:60
msgid ""
"When accessing resources, using the host OS file system layout can be "
"cumbersome and non-portable. To solve this problem, the special path ``res://"
"`` was created."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:64
msgid ""
"The path ``res://`` will always point at the project root (where ``project."
"godot`` is located, so ``res://project.godot`` is always valid)."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:68
msgid ""
"This file system is read-write only when running the project locally from "
"the editor. When exported or when running on different devices (such as "
"phones or consoles, or running from DVD), the file system will become read-"
"only and writing will no longer be permitted."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:74
msgid "User path"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:76
msgid ""
"Writing to disk is still needed for tasks such as saving game state or "
"downloading content packs. To this end, the engine ensures that there is a "
"special path ``user://`` that is always writable. This path resolves "
"differently depending on the OS the project is running on. Local path "
"resolution is further explained in :ref:`doc_data_paths`."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:83
msgid "Host file system"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:85
msgid ""
"Alternatively host file system paths can also be used, but this is not "
"recommended for a released product as these paths are not guaranteed to work "
"on all platforms. However, using host file system paths can be useful when "
"writing development tools in Godot."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:91
msgid "Drawbacks"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:93
msgid ""
"There are some drawbacks to this simple file system design. The first issue "
"is that moving assets around (renaming them or moving them from one path to "
"another inside the project) will break existing references to these assets. "
"These references will have to be re-defined to point at the new asset "
"location."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:98
msgid ""
"To avoid this, do all your move, delete and rename operations from within "
"Godot, on the FileSystem dock. Never move assets from outside Godot, or "
"dependencies will have to be fixed manually (Godot detects this and helps "
"you fix them anyway, but why go the hard route?)."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:103
msgid ""
"The second is that, under Windows and macOS, file and path names are case "
"insensitive. If a developer working in a case insensitive host file system "
"saves an asset as ``myfile.PNG``, but then references it as ``myfile.png``, "
"it will work fine on their platform, but not on other platforms, such as "
"Linux, Android, etc. This may also apply to exported binaries, which use a "
"compressed package to store all files."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:109
msgid ""
"It is recommended that your team clearly define a naming convention for "
"files when working with Godot. One simple fool-proof convention is to only "
"allow lowercase file and path names."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:4
#: ../../docs/getting_started/step_by_step/scene_tree.rst:33
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:288
msgid "SceneTree"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:9
msgid ""
"In previous tutorials, everything revolved around the concept of nodes. "
"Scenes are collections of nodes. They become active once they enter the "
"*scene tree*."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:14
msgid "MainLoop"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:16
msgid ""
"The way Godot works internally is as follows. There is the :ref:`OS "
"<class_OS>` class, which is the only instance that runs at the beginning. "
"Afterwards, all drivers, servers, scripting languages, scene system, etc are "
"loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:21
msgid ""
"When initialization is complete, :ref:`OS <class_OS>` needs to be supplied "
"a :ref:`MainLoop <class_MainLoop>` to run. Up to this point, all this is "
"internals working (you can check main/main.cpp file in the source code if "
"you are ever interested to see how this works internally)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:27
msgid ""
"The user program, or game, starts in the MainLoop. This class has a few "
"methods, for initialization, idle (frame-synchronized callback), fixed "
"(physics-synchronized callback), and input. Again, this is low level and "
"when making games in Godot, writing your own MainLoop seldom makes sense."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:35
msgid ""
"One of the ways to explain how Godot works is that it's a high level game "
"engine over a low level middleware."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:38
msgid ""
"The scene system is the game engine, while the :ref:`OS <class_OS>` and "
"servers are the low level API."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:41
msgid ""
"The scene system provides its own main loop to OS, :ref:`SceneTree "
"<class_SceneTree>`. This is automatically instanced and set when running a "
"scene, no need to do any extra work."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:46
msgid ""
"It's important to know that this class exists because it has a few important "
"uses:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:49
msgid ""
"It contains the root :ref:`Viewport <class_Viewport>`, to which a scene is "
"added as a child when it's first opened to become part of the *Scene Tree* "
"(more on that next)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:52
msgid ""
"It contains information about the groups and has the means to call all nodes "
"in a group or get a list of them."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:54
msgid ""
"It contains some global state functionality, such as setting pause mode or "
"quitting the process."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:57
msgid ""
"When a node is part of the Scene Tree, the :ref:`SceneTree "
"<class_SceneTree>` singleton can be obtained by calling :ref:`Node."
"get_tree() <class_Node_method_get_tree>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:63
msgid "Root viewport"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:65
msgid ""
"The root :ref:`Viewport <class_Viewport>` is always at the top of the scene. "
"From a node, it can be obtained in two different ways:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:80
msgid ""
"This node contains the main viewport. Anything that is a child of a :ref:"
"`Viewport <class_Viewport>` is drawn inside of it by default, so it makes "
"sense that the top of all nodes is always a node of this type otherwise "
"nothing would be seen."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:85
msgid ""
"While other viewports can be created in the scene (for split-screen effects "
"and such), this one is the only one that is never created by the user. It's "
"created automatically inside SceneTree."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:90
#: ../../docs/tutorials/threads/thread_safe_apis.rst:22
msgid "Scene tree"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:92
msgid ""
"When a node is connected, directly or indirectly, to the root viewport, it "
"becomes part of the *scene tree*."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:95
msgid ""
"This means that as explained in previous tutorials, it will get the "
"_enter_tree() and _ready() callbacks (as well as _exit_tree())."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:100
msgid ""
"When nodes enter the *Scene Tree*, they become active. They get access to "
"everything they need to process, get input, display 2D and 3D visuals, "
"receive and send notifications, play sounds, etc. When they are removed from "
"the *scene tree*, they lose these abilities."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:106
msgid "Tree order"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:108
msgid ""
"Most node operations in Godot, such as drawing 2D, processing, or getting "
"notifications are done in tree order. This means that parents and siblings "
"with a lower rank in the tree order will get notified before the current "
"node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:116
msgid "\"Becoming active\" by entering the *Scene Tree*"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:118
msgid "A scene is loaded from disk or created by scripting."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:119
msgid ""
"The root node of that scene (only one root, remember?) is added as either a "
"child of the \"root\" Viewport (from SceneTree), or to any child or "
"grandchild of it."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:122
msgid ""
"Every node of the newly added scene, will receive the \"enter_tree\" "
"notification ( _enter_tree() callback in GDScript) in top-to-bottom order."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:125
msgid ""
"An extra notification, \"ready\" ( _ready() callback in GDScript) is "
"provided for convenience, when a node and all its children are inside the "
"active scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:128
msgid ""
"When a scene (or part of it) is removed, they receive the \"exit scene\" "
"notification ( _exit_tree() callback in GDScript) in bottom-to-top order"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:133
msgid "Changing current scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:135
msgid ""
"After a scene is loaded, it is often desired to change this scene for "
"another one. The simple way to do this is to use the :ref:`SceneTree."
"change_scene() <class_SceneTree_method_change_scene>` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:153
msgid ""
"Rather than using file paths, one can also use ready-made :ref:`PackedScene "
"<class_PackedScene>` resources using the equivalent function :ref:`SceneTree."
"change_scene_to(PackedScene scene) <class_SceneTree_method_change_scene_to>`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:174
msgid ""
"These are quick and useful ways to switch scenes but have the drawback that "
"the game will stall until the new scene is loaded and running. At some point "
"in the development of your game, it may be preferable to create proper "
"loading screens with progress bar, animated indicators or thread "
"(background) loading. This must be done manually using autoloads (see next "
"chapter) and :ref:`doc_background_loading`."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:4
msgid "Singletons (AutoLoad)"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:9
msgid ""
"Godot's scene system, while powerful and flexible, has a drawback: there is "
"no method for storing information (e.g. a player's score or inventory) that "
"is needed by more than one scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:13
msgid ""
"It's possible to address this with some workarounds, but they come with "
"their own limitations:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:16
msgid ""
"You can use a \"master\" scene that loads and unloads other scenes as its "
"children. However, this means you can no longer run those scenes "
"individually and expect them to work correctly."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:19
msgid ""
"Information can be stored to disk in ``user://`` and then loaded by scenes "
"that require it, but frequently saving and loading data is cumbersome and "
"may be slow."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:23
msgid ""
"The `Singleton Pattern <https://en.wikipedia.org/wiki/Singleton_pattern>`_ "
"is a useful tool for solving the common use case where you need to store "
"persistent information between scenes. In our case it is possible re-use the "
"same scene or class for multiple singletons, so long as they have different "
"names."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:29
msgid "Using this concept, you can create objects that:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:31
msgid "Are always loaded, no matter which scene is currently running"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:32
msgid "Can store global variables, such as player information"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:33
msgid "Can handle switching scenes and between-scene transitions"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:34
msgid ""
"Act like a singleton, since GDScript does not support global variables by "
"design"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:36
msgid "Autoloading nodes and scripts can give us these characteristics."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:39
msgid "AutoLoad"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:41
msgid ""
"You can use AutoLoad to load a scene or a script that inherits from :ref:"
"`Node <class_Node>`. Note: when autoloading a script, a Node will be created "
"and the script will be attached to it. This node will be added to the root "
"viewport before any other scenes are loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:48
msgid ""
"To autoload a scene or script, select ``Project -> Project Settings`` from "
"the menu and switch to the \"AutoLoad\" tab."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:53
msgid ""
"Here you can add any number of scenes or scripts. Each entry in the list "
"requires a name, which is assigned as the node's ``name`` property. The "
"order of the entries as they are added to the global scene tree can be "
"manipulated using the up/down arrow keys."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:60
msgid ""
"This means that any node can access a singleton named \"PlayerVariables\" "
"with:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:73
msgid ""
"If the \"Enable\" column is checked (default ``true``) then the singleton "
"can simply be accessed directly:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:86
msgid ""
"Note that autoload objects (scripts and/or scenes) are accessed just like "
"any other node in the scene tree. In fact, if you look at the running scene "
"tree, you'll see the autoloaded nodes appear:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:93
msgid "Custom scene switcher"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:95
msgid ""
"This tutorial will demonstrate building a scene switcher using autoload. For "
"basic scene switching, you can use the :ref:`SceneTree.change_scene() "
"<class_SceneTree_method_change_scene>` method (see :ref:`doc_scene_tree` for "
"details). However, if you need more complex behavior when changing scenes, "
"this method provides more functionality."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:101
msgid ""
"To begin, download the template from here: :download:`autoload.zip <files/"
"autoload.zip>` and open it in Godot."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:104
msgid ""
"The project contains two scenes: ``Scene1.tscn`` and ``Scene2.tscn``. Each "
"scene contains a label displaying the scene name and a button with its "
"``pressed()`` signal connected. When you run the project, it starts in "
"``Scene1.tscn``. However, pressing the button does nothing."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:110
msgid "Global.gd"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:112
msgid ""
"Switch to the \"Script\" tab and create a new script called Global.gd. Make "
"sure it inherits from ``Node``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:117
msgid ""
"The next step is to add this script to the autoLoad list. Open ``Project > "
"Project Settings`` from the menu, switch to the \"AutoLoad\" tab and select "
"the script by clicking the browse button or typing its path: ``res://Global."
"gd``. Press \"Add\" to add it to the autoload list:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:124
msgid ""
"Now whenever we run any scene in the project, this script will always be "
"loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:126
msgid ""
"Returning to the script, it needs to fetch the current scene in the "
"`_ready()` function. Both the current scene (the one with the button) and "
"``global.gd`` are children of root, but autoloaded nodes are always first. "
"This means that the last child of root is always the loaded scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:158
msgid ""
"Now we need a function for changing the scene. This function needs to free "
"the current scene and replace it with the requested one."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:227
msgid ""
"Using :ref:`Object.call_deferred() <class_Object_method_call_deferred>`, the "
"second function will only run once all code from the current scene has "
"completed. Thus, the current scene will not be removed while it is still "
"being used (i.e. its code is still running)."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:232
msgid ""
"Finally, we need to fill the empty callback functions in the two scenes:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:252
#: ../../docs/tutorials/math/vector_math.rst:264
msgid "and"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:272
msgid ""
"Run the project and test that you can switch between scenes by pressing the "
"button."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:275
msgid ""
"Note: When scenes are small, the transition is instantaneous. However, if "
"your scenes are more complex, they may take a noticeable amount of time to "
"appear. To learn how to handle this, see the next tutorial: :ref:"
"`doc_background_loading`"
msgstr ""

#: ../../docs/getting_started/editor/index.rst:2
msgid "Editor manual"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:8
#, fuzzy
msgid "From Unity to Godot Engine"
msgstr "על המנוע גודוט"

#: ../../docs/getting_started/editor/unity_to_godot.rst:10
msgid ""
"This guide provides an overview of Godot Engine from the viewpoint of a "
"Unity user, and aims to help you migrate your existing Unity experience into "
"the world of Godot."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:15
msgid ""
"This article talks about older versions of Unity. Nestable prefabs ('Nested "
"prefabs') were added to Unity 2018.3. Nestable prefabs are analogous to "
"Godot's scenes, and allow a more Godot-like approach to scene organization."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:18
msgid "Differences"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:21
msgid "Unity"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:21
msgid "Godot"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
#: ../../docs/community/contributing/documentation_guidelines.rst:133
msgid "License"
msgstr "רישיון"

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
msgid ""
"Proprietary, closed, free license with revenue caps and usage restrictions"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
msgid "MIT license, free and fully open source without any restriction"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:25
msgid "OS (editor)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:25
#, fuzzy
msgid "Windows, macOS, Linux"
msgstr "X11 (לינוקס, /*BSD)"

#: ../../docs/getting_started/editor/unity_to_godot.rst:25
#, fuzzy
msgid "Windows, macOS, X11 (Linux, \\*BSD)"
msgstr "X11 (לינוקס, /*BSD)"

#: ../../docs/getting_started/editor/unity_to_godot.rst:27
msgid "OS (export)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:27
msgid "**Desktop:** Windows, macOS, Linux"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:28
msgid "**Mobile:** Android, iOS, Windows Phone, Tizen"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:29
msgid "**Web:** WebAssembly or asm.js"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:30
msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:31
msgid ""
"**VR:** Oculus Rift, SteamVR, Google Cardboard, PlayStation VR, Gear VR, "
"HoloLens"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:32
msgid "**TV:** Android TV, Samsung SMART TV, tvOS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:27
msgid "**Desktop:** Windows, macOS, X11"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:28
msgid "**Mobile:** Android, iOS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:29
msgid "**Web:** WebAssembly"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:30
msgid "**Console:** See :ref:`doc_consoles`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:31
msgid "**VR:** Oculus Rift, SteamVR"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:34
msgid "Scene system"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:34
msgid "Component/Scene (GameObject > Component)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:35
msgid "Prefabs"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:34
msgid ""
":ref:`Scene tree and nodes <doc_scenes_and_nodes>`, allowing scenes to be "
"nested and/or inherit other scenes"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:37
msgid "Third-party tools"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:37
msgid "Visual Studio or VS Code"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:37
msgid ":ref:`External editors are possible <doc_external_editor>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:38
msgid ":ref:`Android SDK for Android export <doc_exporting_for_android>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:40
msgid "Notable advantages"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:40
msgid "Huge community"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:41
msgid "Large assets store"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:40
msgid "Scene System"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:41
msgid ":ref:`Animation Pipeline <doc_animations>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:42
msgid ":ref:`Easy to write Shaders <doc_shading_language>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:43
msgid "Debug on Device"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:50
msgid "The editor"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:52
msgid ""
"Godot Engine provides a rich-featured editor that allows you to build your "
"games. The pictures below display the default layouts of both editors with "
"colored blocks to indicate common functionalities."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:58
msgid ""
"While both editors may seem similar, there are many differences below the "
"surface. Both let you organize the project using the filesystem, but Godot's "
"approach is simpler with a single configuration file, minimalist text "
"format, and no metadata. This makes Godot more friendly to VCS systems, such "
"as Git, Subversion, or Mercurial."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:63
msgid ""
"Godot's Scene panel is similar to Unity's Hierarchy panel but, as each node "
"has a specific function, the approach used by Godot is more visually "
"descriptive. It's easier to understand what a scene does at a glance."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:67
msgid ""
"The Inspector in Godot is more minimal, it shows only properties. Thanks to "
"this, objects can expose more useful parameters to the user without having "
"to hide functionality in language APIs. As a plus, Godot allows animating "
"any of those properties visually. Changing colors, textures, enumerations, "
"or even links to resources in real-time is possible without needing to write "
"code."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:72
msgid ""
"The Toolbar at the top of the screen is similar in both editors, offering "
"control over project playback. Projects in Godot run in a separate window, "
"rather than inside the editor (but the tree and objects can still be "
"explored in the debugger window)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:76
msgid "This approach has several advantages:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:78
msgid ""
"Running the project and closing it is fast (Unity has to save, run the "
"project, close the project, and then reload the previous state)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:79
msgid ""
"Live editing is a lot more useful because changes done to the editor take "
"effect immediately in the game and are not lost (nor have to be synced) when "
"the game is closed. This allows fantastic workflows, like creating levels "
"while you play them."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:80
msgid "The editor is more stable because the game runs in a separate process."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:81
msgid ""
"The running game can be explored from different angles by toggling the "
"\"Camera Override\" button in the editor viewport, which will switch between "
"using the editor view and the game camera view."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:83
msgid ""
"Finally, Godot's top toolbar includes a menu for remote debugging. These "
"options allow deployment to a device (connected phone, tablet, or browser "
"via HTML5), and debugging/live editing on it after the game is exported."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:88
msgid "The scene system"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:90
msgid ""
"This is the most important difference between Unity and Godot and the "
"favorite feature of most Godot users."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:92
msgid ""
"Working on a 'level' in Unity usually means embedding all the required "
"assets in a scene and linking them together with components and scripts."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:95
msgid ""
"Godot's scene system is superficially similar to Unity. A 'level' consists "
"of a collection of nodes, each with its own purpose: Sprite, Mesh, Light, "
"etc. However, in Godot the nodes are arranged in a tree. Each node can have "
"multiple children, which makes each a subscene of the main scene. This means "
"you can compose a whole scene with different scenes stored in different "
"files."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:98
msgid ""
"For example, think of a platformer level. You would compose it with multiple "
"elements:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:100
msgid "Bricks"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:101
msgid "Coins"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:102
msgid "The player"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:103
msgid "The enemies"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:105
msgid ""
"In Unity, you would put all the GameObjects in the scene: the player, "
"multiple instances of enemies, bricks everywhere to form the ground of the "
"level and then multiple instances of coins all over the level. You would "
"then add various components to each element to link them and add logic in "
"the level: For example, you'd add a BoxCollider2D to all the elements of the "
"scene so that they can collide. This principle is different in Godot."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:110
msgid ""
"In Godot, you would split your whole scene into three separate, smaller "
"scenes, and instance them in the main scene."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:112
msgid "**A scene for the Player alone.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:114
msgid ""
"Consider the player as an element we'd like to use in different parent "
"scenes (for instance 'level' scenes). In our case, the player element needs "
"at least an AnimatedSprite node. This node contains the sprite textures "
"necessary for various animations (for example, a walking animation)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:116
msgid "**A scene for the Enemy.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:118
msgid ""
"An enemy is also an element we'd like to use in several scenes. It's almost "
"the same as the Player node. The only differences are the script (it needs "
"'AI' routines to generate the enemy's behavior) and the sprite textures used "
"by the AnimatedSprite node."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:122
msgid "**A Level scene.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:124
msgid ""
"A Level scene is composed of Bricks (for platforms), Coins (for the player "
"to collect) and a number of instances of the Enemy scene. Each instance is a "
"node in the Level scene tree. These instances are separate enemies, which "
"initially have shared behavior and appearance as defined in the Enemy scene. "
"You can set different properties for each Enemy node (to change its color, "
"for example)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:128
msgid ""
"4. **A Main scene.** The Main scene would be composed of one root node with "
"2 children: a Player instance node, and a Level instance node. The root node "
"can be anything, generally a \"root\" type such as \"Node\" which is the "
"most global type, or \"Node2D\" (root type of all 2D-related nodes), "
"\"Spatial\" (root type of all 3D-related nodes) or \"Control\" (root type of "
"all GUI-related nodes)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:134
msgid ""
"As you can see, every scene is organized as a tree. The same goes for nodes' "
"properties: you don't *add* a collision component to a node to make it "
"collidable like Unity does. Instead, you make this node a *child* of a new "
"specific node that has collision properties. Godot features various "
"collision types nodes, depending on the usage (see the :ref:`Physics "
"introduction <doc_physics_introduction>`)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:139
msgid ""
"What are the advantages of this system? Wouldn't this system potentially "
"increase the depth of the scene tree? And doesn't Unity already allow you to "
"organize GameObjects by putting them inside empty GameObjects?"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:141
msgid ""
"Godot's system is closer to the well-known object-oriented paradigm: Godot "
"provides a number of nodes which are not clearly \"Game Objects\", but they "
"provide their children with their own capabilities: this is inheritance."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:142
msgid ""
"Godot allows the extraction of a subtree of a scene to make it a scene of "
"its own. So if a scene tree gets too deep, it can be split into smaller "
"subtrees. This is better for reusability, as you can include any subtree as "
"a child of any node. Putting multiple GameObjects in an empty GameObject in "
"Unity does not provide the same functionality."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:145
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4
msgid "Project organization"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:149
msgid ""
"There is no perfect project architecture. Any architecture can be made to "
"work in either Unity and Godot."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:152
msgid ""
"However, a common architecture for Unity projects is to have one Assets "
"folder in the root directory that contains various folders, one per type of "
"asset: Audio, Graphics, Models, Materials, Scripts, Scenes, and so on."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:155
msgid ""
"Since Godot allows splitting scenes into smaller scenes, each scene and "
"subscene existing as a file in the project, we recommend organizing your "
"project a bit differently. This wiki provides a page for this: :ref:"
"`doc_project_organization`."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:160
msgid "Where are my prefabs?"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:162
msgid ""
"A prefab as provided by Unity is a 'template' element of the scene. It is "
"reusable, and each instance of the prefab that exists in the scene has an "
"existence of its own, but all of them have the same properties as defined by "
"the prefab."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:166
msgid ""
"Godot does not provide prefabs as such, but the same functionality is "
"provided by its scene system: The scene system is organized as a tree. Godot "
"allows you to save any subtree of a scene as a scene file. This new scene "
"can then be instanced as many times as you want, as a child of any node. Any "
"change you make to this new, separate scene will be applied to its "
"instances. However, any change you make to the instance will not have any "
"impact on the 'template' scene."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:173
msgid ""
"To be precise, you can modify the parameters of an instance in the Inspector "
"panel. The nodes that compose this instance are initially locked. You can "
"unlock them if you need to by right-clicking the instance in the Scene tree "
"and selecting \"Editable children\" in the menu. You don't need to do this "
"to add *new* child nodes to this node. Remember that any new children will "
"belong to the instance, not to the 'template' scene on disk. If you want to "
"add new children to every instance of your 'template' scene, then you should "
"add them in the 'template' scene."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:183
msgid "Glossary correspondence"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:185
msgid "GameObject -> Node"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:186
msgid "Add a component -> Inheriting"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:187
msgid "Prefab -> Reusable Scene file"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:191
msgid "Scripting: GDScript, C# and Visual Script"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:194
msgid "Design"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:196
msgid ""
"Unity supports C#. C# benefits from its integration with Visual Studio and "
"has desirable features such as static typing."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:198
msgid ""
"Godot provides its own scripting language, :ref:`GDScript <doc_scripting>` "
"as well as support for :ref:`Visual Script <toc-learn-scripting-"
"visual_script>` and :ref:`C# <doc_c_sharp>`. GDScript borrows its syntax "
"from Python, but is not related to it. If you wonder about the reasoning for "
"a custom scripting language, please read the :ref:`doc_gdscript` and :ref:"
"`doc_faq` pages. GDScript is strongly attached to the Godot API and doesn't "
"take long to learn: Between one evening for an experienced programmer and a "
"week for a complete beginner."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:204
msgid ""
"Unity allows you to attach as many scripts as you want to a GameObject. Each "
"script adds a behavior to the GameObject: For example, you can attach a "
"script so that it reacts to the player's controls, and another that controls "
"its specific game logic."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:208
msgid ""
"In Godot, you can only attach one script per node. You can use either an "
"external GDScript file or include the script directly in the node. If you "
"need to attach more scripts to one node, then you may consider two "
"solutions, depending on your scene and on what you want to achieve:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:212
msgid ""
"either add a new node between your target node and its current parent, then "
"add a script to this new node."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:213
msgid ""
"or, you can split your target node into multiple children and attach one "
"script to each of them."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:215
msgid ""
"As you can see, it can be easy to turn a scene tree to a mess. Consider "
"splitting any complicated scene into multiple, smaller branches."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:218
msgid "Connections: groups and signals"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:220
msgid ""
"You can control nodes by accessing them via script and calling built-in or "
"user-defined functions on them. You can also place nodes in a group and call "
"functions on all nodes in this group. See more in the :ref:`scripting "
"documentation <doc_scripting_continued>`."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:225
msgid ""
"Nodes can send a signal when a specified action occurs. A signal can be set "
"to call any function. You can define custom signals and specify when they "
"are triggered. See more in the :ref:`signals documentation "
"<doc_gdscript_signals>`."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:230
#, fuzzy
msgid "Script serialization"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/unity_to_godot.rst:232
msgid "Unity can handle script serialization in two ways:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:234
msgid ""
"Implicit: All public fields in a class are automatically serialized if the "
"type is a serializable type (``Dictionary`` is not serializable)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:235
msgid ""
"Explicit: Non-public fields can be serialized using the ``[SerializeField]`` "
"attribute."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:237
msgid ""
"Godot also has a built-in script serialization system, but it works only "
"explicitly. You can serialize any serializable type (:ref:`built-in and "
"various engine types <doc_binary_serialization_api>`, including :ref:"
"`class_Array` and :ref:`class_Dictionary`) using the ``export`` keyword. See "
"the :ref:`exports documentation <doc_gdscript_exports>` for details."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:242
msgid ""
"Unity also has a data type called ``ScriptableObject`` used to serialize "
"custom asset objects. Its equivalent in Godot is the base class for all "
"resources: :ref:`class_Resource`. Creating a script that inherits :ref:"
"`class_Resource` will allow you to create custom serializable objects. More "
"information about resources can be found :ref:`here <doc_resources>`."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:247
msgid "Using Godot in C++"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:249
msgid ""
"Godot allows you to develop your project directly in C++ by using its API, "
"which is not possible with Unity at the moment. As an example, you can "
"consider Godot Engine's editor as a \"game\" written in C++ using the Godot "
"API."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:252
msgid ""
"If you are interested in using Godot in C++, you may want to start reading "
"the :ref:`Developing in C++ <doc_introduction_to_godot_development>` page."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:4
msgid "Command line tutorial"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:8
msgid ""
"Some developers like using the command line extensively. Godot is designed "
"to be friendly to them, so here are the steps for working entirely from the "
"command line. Given the engine relies on almost no external libraries, "
"initialization times are pretty fast, making it suitable for this workflow."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:15
msgid "Command line reference"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:17
msgid "**General options**"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:20
#: ../../docs/getting_started/editor/command_line_tutorial.rst:34
#: ../../docs/getting_started/editor/command_line_tutorial.rst:62
#: ../../docs/getting_started/editor/command_line_tutorial.rst:90
#: ../../docs/getting_started/editor/command_line_tutorial.rst:120
#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:59
msgid "Command"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:20
#: ../../docs/getting_started/editor/command_line_tutorial.rst:34
#: ../../docs/getting_started/editor/command_line_tutorial.rst:62
#: ../../docs/getting_started/editor/command_line_tutorial.rst:90
#: ../../docs/getting_started/editor/command_line_tutorial.rst:120
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:141
#: ../../docs/getting_started/scripting/creating_script_templates.rst:125
#: ../../docs/getting_started/workflow/assets/importing_images.rst:94
#: ../../docs/tutorials/inputs/inputevent.rst:130
#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:21
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:476
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:522
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:586
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:15
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:94
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:139
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:191
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:309
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:17
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:52
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:110
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:161
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:214
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:30
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:53
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:65
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:92
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:158
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:218
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:240
#: ../../docs/tutorials/misc/binary_serialization_api.rst:95
#: ../../docs/tutorials/misc/binary_serialization_api.rst:104
#: ../../docs/tutorials/misc/binary_serialization_api.rst:113
#: ../../docs/tutorials/misc/binary_serialization_api.rst:122
#: ../../docs/tutorials/misc/binary_serialization_api.rst:135
#: ../../docs/tutorials/misc/binary_serialization_api.rst:146
#: ../../docs/tutorials/misc/binary_serialization_api.rst:161
#: ../../docs/tutorials/misc/binary_serialization_api.rst:174
#: ../../docs/tutorials/misc/binary_serialization_api.rst:193
#: ../../docs/tutorials/misc/binary_serialization_api.rst:208
#: ../../docs/tutorials/misc/binary_serialization_api.rst:223
#: ../../docs/tutorials/misc/binary_serialization_api.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:267
#: ../../docs/tutorials/misc/binary_serialization_api.rst:298
#: ../../docs/tutorials/misc/binary_serialization_api.rst:313
#: ../../docs/tutorials/misc/binary_serialization_api.rst:322
#: ../../docs/tutorials/misc/binary_serialization_api.rst:333
#: ../../docs/tutorials/misc/binary_serialization_api.rst:343
#: ../../docs/tutorials/misc/binary_serialization_api.rst:362
#: ../../docs/tutorials/misc/binary_serialization_api.rst:374
#: ../../docs/tutorials/misc/binary_serialization_api.rst:386
#: ../../docs/tutorials/misc/binary_serialization_api.rst:399
#: ../../docs/tutorials/misc/binary_serialization_api.rst:410
#: ../../docs/tutorials/misc/binary_serialization_api.rst:421
#: ../../docs/tutorials/misc/binary_serialization_api.rst:429
#: ../../docs/tutorials/misc/binary_serialization_api.rst:442
#: ../../docs/tutorials/misc/binary_serialization_api.rst:455
#: ../../docs/tutorials/misc/binary_serialization_api.rst:470
msgid "Description"
msgstr "תיאור"

#: ../../docs/getting_started/editor/command_line_tutorial.rst:22
msgid "``-h``, ``--help``, ``/?``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:22
msgid "Display the list of command line options."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:24
msgid "``--version``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:24
msgid "Display the version string."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:26
msgid "``-v``, ``--verbose``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:26
msgid "Use verbose stdout mode."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:28
msgid "``--quiet``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:28
msgid "Quiet mode, silences stdout messages. Errors are still displayed."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:31
msgid "**Run options**"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:36
msgid "``-e``, ``--editor``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:36
msgid ""
"Start the editor instead of running the scene (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:38
msgid "``-p``, ``--project-manager``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:38
msgid ""
"Start the project manager, even if a project is auto-detected (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:40
msgid "``-q``, ``--quit``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:40
msgid "Quit after the first iteration."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:42
msgid "``-l <locale>``, ``--language <locale>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:42
msgid ""
"Use a specific locale (<locale> being a two-letter code). See :ref:"
"`doc_locales` for more details."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:44
msgid "``--path <directory>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:44
msgid "Path to a project (<directory> must contain a 'project.godot' file)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:46
msgid "``-u``, ``--upwards``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:46
msgid "Scan folders upwards for 'project.godot' file."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:48
msgid "``--main-pack <file>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:48
msgid "Path to a pack (.pck) file to load."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:50
msgid "``--render-thread <mode>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:50
msgid ""
"Render thread mode ('unsafe', 'safe', 'separate'). See :ref:`Thread Model "
"<class_ProjectSettings_property_rendering/threads/thread_model>` for more "
"details."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:52
msgid "``--remote-fs <address>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:52
msgid "Remote filesystem (``<host/IP>[:<port>]`` address)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:54
msgid "``--audio-driver <driver>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:54
msgid ""
"Audio driver. Use ``--help`` first to display the list of available drivers."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:56
msgid "``--video-driver <driver>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:56
msgid ""
"Video driver. Use ``--help`` first to display the list of available drivers."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:59
msgid "**Display options**"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:64
msgid "``-f``, ``--fullscreen``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:64
msgid "Request fullscreen mode."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:66
msgid "``-m``, ``--maximized``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:66
msgid "Request a maximized window."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:68
msgid "``-w``, ``--windowed``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:68
msgid "Request windowed mode."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:70
msgid "``-t``, ``--always-on-top``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:70
msgid "Request an always-on-top window."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:72
msgid "``--resolution <W>x<H>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:72
msgid "Request window resolution."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:74
msgid "``--position <X>,<Y>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:74
msgid "Request window position."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:76
msgid "``--low-dpi``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:76
msgid "Force low-DPI mode (macOS and Windows only)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:78
msgid "``--no-window``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:78
msgid ""
"Disable window creation (Windows only). Useful together with ``--script``."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:81
msgid "**Debug options**"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:85
msgid ""
"Debug options are only available in the editor and debug export templates "
"(they require ``debug`` or ``release_debug`` build targets, see :ref:"
"`doc_introduction_to_the_buildsystem_target` for more details)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:92
msgid "``-d``, ``--debug``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:92
msgid "Debug (local stdout debugger)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:94
msgid "``-b``, ``--breakpoints``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:94
msgid ""
"Breakpoint list as source::line comma-separated pairs, no spaces (use %%20 "
"instead)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:96
msgid "``--profiling``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:96
msgid "Enable profiling in the script debugger."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:98
msgid "``--remote-debug <address>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:98
msgid "Remote debug (``<host/IP>:<port>`` address)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:100
msgid "``--debug-collisions``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:100
msgid "Show collision shapes when running the scene."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:102
msgid "``--debug-navigation``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:102
msgid "Show navigation polygons when running the scene."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:104
msgid "``--frame-delay <ms>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:104
msgid "Simulate high CPU load (delay each frame by <ms> milliseconds)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:106
msgid "``--time-scale <scale>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:106
msgid "Force time scale (higher values are faster, 1.0 is normal speed)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:108
msgid "``--disable-render-loop``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:108
msgid ""
"Disable render loop so rendering only occurs when called explicitly from "
"script."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:110
msgid "``--disable-crash-handler``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:110
msgid "Disable crash handler when supported by the platform code."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:112
msgid "``--fixed-fps <fps>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:112
msgid ""
"Force a fixed number of frames per second. This setting disables real-time "
"synchronization."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:114
msgid "``--print-fps``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:114
msgid "Print the frames per second to the stdout."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:117
msgid "**Standalone tools**"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:122
msgid "``-s <script>``, ``--script <script>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:122
#, fuzzy
msgid "Run a script."
msgstr "יצירת תוכן"

#: ../../docs/getting_started/editor/command_line_tutorial.rst:124
msgid "``--check-only``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:124
msgid "Only parse for errors and quit (use with ``--script``)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:126
msgid "``--export <target>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:126
msgid ""
"Export the project using the given export target. Export only main pack if "
"path ends with .pck or .zip (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:128
msgid "``--export-debug <target>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:128
msgid ""
"Like ``--export``, but use debug template (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:130
msgid "``--doctool <path>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:130
msgid ""
"Dump the engine API reference to the given <path> in XML format, merging if "
"existing files are found (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:132
msgid "``--no-docbase``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:132
msgid ""
"Disallow dumping the base types (used with ``--doctool``, :ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:134
msgid "``--build-solutions``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:134
msgid ""
"Build the scripting solutions (e.g. for C# projects, :ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:136
msgid "``--gdnative-generate-json-api``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:136
msgid ""
"Generate JSON dump of the Godot API for GDNative bindings (:ref:`tools "
"<doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:138
msgid "``--test <test>``"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:138
msgid ""
"Run a unit test. Use ``--help`` first to display the list of tests. (:ref:"
"`tools <doc_introduction_to_the_buildsystem_tools>` must be enabled)."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:142
msgid "Path"
msgstr "נתיב"

#: ../../docs/getting_started/editor/command_line_tutorial.rst:144
msgid ""
"It is recommended that your Godot binary be in your PATH environment "
"variable, so it can be executed easily from any place by typing ``godot``. "
"You can do so on Linux by placing the Godot binary in ``/usr/local/bin`` and "
"making sure it is called ``godot``."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:150
msgid "Setting the project path"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:152
msgid ""
"Depending on where your Godot binary is located and what your current "
"working directory is, you may need to set the path to your project for any "
"of the following commands to work correctly."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:156
msgid ""
"This can be done by giving the path to the ``project.godot`` file of your "
"project as either the first argument, like this:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:163
msgid "Or by using the ``--path`` argument:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:169
msgid ""
"For example, the full command for exporting your game (as explained below) "
"might look like this:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:176
msgid "Creating a project"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:179
msgid ""
"Creating a project from the command line can be done by navigating the shell "
"to the desired place and making a project.godot file."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:190
msgid "The project can now be opened with Godot."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:194
msgid "Running the editor"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:196
msgid ""
"Running the editor is done by executing Godot with the ``-e`` flag. This "
"must be done from within the project directory or a subdirectory, otherwise "
"the command is ignored and the project manager appears."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:204
msgid ""
"If a scene has been created and saved, it can be edited later by running the "
"same code with that scene as argument."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:212
msgid "Erasing a scene"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:214
msgid ""
"Godot is friends with your filesystem and will not create extra metadata "
"files. Use ``rm`` to erase a scene file. Make sure nothing references that "
"scene or else an error will be thrown upon opening."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:223
msgid "Running the game"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:225
msgid ""
"To run the game, simply execute Godot within the project directory or "
"subdirectory."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:232
msgid ""
"When a specific scene needs to be tested, pass that scene to the command "
"line."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:240
#: ../../docs/tutorials/platform/customizing_html5_shell.rst:172
msgid "Debugging"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:242
msgid ""
"Catching errors in the command line can be a difficult task because they "
"just fly by. For this, a command line debugger is provided by adding ``-d``. "
"It works for running either the game or a simple scene."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:259
msgid ""
"Exporting the project from the command line is also supported. This is "
"especially useful for continuous integration setups. The version of Godot "
"that is headless (server build, no video) is ideal for this."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:268
msgid ""
"The platform names recognized by the ``--export`` switch are the same as "
"displayed in the export wizard of the editor. To get a list of supported "
"platforms from the command line, try exporting to a non-recognized platform "
"and the full listing of platforms your configuration supports will be shown."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:274
msgid ""
"To export a debug version of the game, use the ``--export-debug`` switch "
"instead of ``--export``. Their parameters and usage are the same."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:278
msgid "Running a script"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:280
msgid ""
"It is possible to run a simple ``.gd`` script from the command line. This "
"feature is especially useful in large projects, e.g. for batch conversion of "
"assets or custom import/export."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:284
msgid "The script must inherit from ``SceneTree`` or ``MainLoop``."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:286
msgid "Here is a simple example of how it works:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:297
msgid "And how to run it:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:304
msgid ""
"If no ``project.godot`` exists at the path, current path is assumed to be "
"the current working directory (unless ``--path`` is specified)."
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:4
msgid "Using an external text editor"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:6
msgid ""
"Godot can be used with an external text editor, such as Sublime Text or "
"Visual Studio Code. To enable an external text editor, browse to the "
"relevant editor settings via: ``Editor -> Editor Settings -> Text Editor -> "
"External``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:12
msgid ""
"There are two fields: the executable path and command line flags. The flags "
"allow you to integrate the editor with Godot, passing it the file path to "
"open and other relevant arguments. Godot will replace the following "
"placeholders in the flags string:"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:18
msgid "Field in Exec Flags"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:18
msgid "Is replaced with"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:20
msgid "``{project}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:20
msgid "The absolute path to the project directory"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:22
msgid "``{file}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:22
msgid "The absolute path to the file"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:24
msgid "``{col}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:24
msgid "The column number of the error"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:26
msgid "``{line}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:26
msgid "The line number of the error"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:29
msgid "Some example Exec Flags for various editors include:"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:32
msgid "Exec Flags"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:34
msgid "Geany/Kate"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:34
msgid "``{file} --line {line} --column {col}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:36
msgid "Atom/Sublime Text"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:36
msgid "``{file}:{line}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:38
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:111
msgid "JetBrains Rider"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:38
msgid "``--line {line} {file}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:40
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:108
#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:4
msgid "Visual Studio Code"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:40
msgid "``{project} --goto {file}:{line}:{col}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:42
msgid "Vim (gVim)"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:42
msgid "``\"+call cursor({line}, {col})\" {file}``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:45
msgid "For Visual Studio Code you will have to point to the ``code.cmd`` file."
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:4
msgid "Default editor shortcuts"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:5
msgid ""
"Many of Godot Editor functions can be executed with keyboard shortcuts. This "
"page lists functions which have associated shortcuts by default, but many "
"others are available for customization in editor settings as well. To change "
"keys associated with these and other actions navigate to ``Editor -> Editor "
"Settings -> Shortcuts``."
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:10
msgid ""
"While some actions are universal, a lot of shortcuts are specific to "
"individual tools. For this reason it is possible for some key combinations "
"to be assigned to more than one function. The correct action will be "
"performed depending on the context."
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:15
msgid ""
"While Windows and Linux builds of the editor share most of the default "
"settings, some shortcuts may differ for macOS version. This is done for "
"better integration of the editor into macOS ecosystem. Users fluent with "
"standard shortcuts on that OS should find Godot Editor's default key mapping "
"intuitive."
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:21
#, fuzzy
msgid "General Editor Actions"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:24
#: ../../docs/getting_started/editor/default_key_mapping.rst:89
#: ../../docs/getting_started/editor/default_key_mapping.rst:142
#: ../../docs/getting_started/editor/default_key_mapping.rst:217
#: ../../docs/getting_started/editor/default_key_mapping.rst:298
#: ../../docs/getting_started/editor/default_key_mapping.rst:345
#: ../../docs/getting_started/editor/default_key_mapping.rst:370
#: ../../docs/getting_started/editor/default_key_mapping.rst:381
#: ../../docs/getting_started/editor/default_key_mapping.rst:394
#: ../../docs/getting_started/editor/default_key_mapping.rst:425
#: ../../docs/getting_started/editor/default_key_mapping.rst:438
#: ../../docs/getting_started/editor/default_key_mapping.rst:461
#: ../../docs/getting_started/editor/default_key_mapping.rst:478
#: ../../docs/getting_started/editor/default_key_mapping.rst:513
msgid "Action name"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:24
#: ../../docs/getting_started/editor/default_key_mapping.rst:89
#: ../../docs/getting_started/editor/default_key_mapping.rst:142
#: ../../docs/getting_started/editor/default_key_mapping.rst:217
#: ../../docs/getting_started/editor/default_key_mapping.rst:298
#: ../../docs/getting_started/editor/default_key_mapping.rst:345
#: ../../docs/getting_started/editor/default_key_mapping.rst:370
#: ../../docs/getting_started/editor/default_key_mapping.rst:381
#: ../../docs/getting_started/editor/default_key_mapping.rst:394
#: ../../docs/getting_started/editor/default_key_mapping.rst:425
#: ../../docs/getting_started/editor/default_key_mapping.rst:438
#: ../../docs/getting_started/editor/default_key_mapping.rst:461
#: ../../docs/getting_started/editor/default_key_mapping.rst:478
#: ../../docs/getting_started/editor/default_key_mapping.rst:513
#, fuzzy
msgid "Windows, Linux"
msgstr "X11 (לינוקס, /*BSD)"

#: ../../docs/getting_started/editor/default_key_mapping.rst:24
#: ../../docs/getting_started/editor/default_key_mapping.rst:89
#: ../../docs/getting_started/editor/default_key_mapping.rst:142
#: ../../docs/getting_started/editor/default_key_mapping.rst:217
#: ../../docs/getting_started/editor/default_key_mapping.rst:298
#: ../../docs/getting_started/editor/default_key_mapping.rst:345
#: ../../docs/getting_started/editor/default_key_mapping.rst:370
#: ../../docs/getting_started/editor/default_key_mapping.rst:381
#: ../../docs/getting_started/editor/default_key_mapping.rst:394
#: ../../docs/getting_started/editor/default_key_mapping.rst:425
#: ../../docs/getting_started/editor/default_key_mapping.rst:438
#: ../../docs/getting_started/editor/default_key_mapping.rst:461
#: ../../docs/getting_started/editor/default_key_mapping.rst:478
#: ../../docs/getting_started/editor/default_key_mapping.rst:513
#, fuzzy
msgid "Editor setting"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:26
#, fuzzy
msgid "Open 2D Editor"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:26
msgid ":kbd:`F1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:26
msgid ":kbd:`Alt + 1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:26
msgid "``editor/editor_2d``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:28
#, fuzzy
msgid "Open 3D Editor"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:28
msgid ":kbd:`F2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:28
msgid ":kbd:`Alt + 2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:28
msgid "``editor/editor_3d``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:30
msgid "Open Script Editor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:30
#: ../../docs/getting_started/editor/default_key_mapping.rst:229
#: ../../docs/getting_started/editor/default_key_mapping.rst:302
msgid ":kbd:`F3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:30
msgid ":kbd:`Alt + 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:30
msgid "``editor/editor_script``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:32
msgid "Search Help"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:32
msgid ":kbd:`Shift + F1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:32
msgid ":kbd:`Alt + Space`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:32
msgid "``editor/editor_help``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:34
#, fuzzy
msgid "Distraction Free Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:34
msgid ":kbd:`Ctrl + Shift + F11`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:34
msgid ":kbd:`Cmd + Ctrl + D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:34
msgid "``editor/distraction_free_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:36
msgid "Next tab"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:36
msgid ":kbd:`Ctrl + Tab`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:36
msgid ":kbd:`Cmd + Tab`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:36
msgid "``editor/next_tab``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:38
msgid "Previous tab"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:38
msgid ":kbd:`Ctrl + Shift + Tab`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:38
msgid ":kbd:`Cmd + Shift + Tab`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:38
msgid "``editor/prev_tab``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:40
msgid "Filter Files"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:40
msgid ":kbd:`Ctrl + Alt + P`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:40
msgid ":kbd:`Cmd + Alt + P`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:40
msgid "``editor/filter_files``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:42
msgid "Open Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:42
msgid ":kbd:`Ctrl + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:42
msgid ":kbd:`Cmd + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:42
msgid "``editor/open_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:44
msgid "Close Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:44
msgid ":kbd:`Ctrl + Shift + W`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:44
msgid ":kbd:`Cmd + Shift + W`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:44
msgid "``editor/close_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:46
msgid "Reopen Closed Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:46
#: ../../docs/getting_started/editor/default_key_mapping.rst:316
msgid ":kbd:`Ctrl + Shift + T`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:46
#: ../../docs/getting_started/editor/default_key_mapping.rst:316
msgid ":kbd:`Cmd + Shift + T`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:46
msgid "``editor/reopen_closed_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:48
msgid "Save Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:48
msgid ":kbd:`Ctrl + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:48
msgid ":kbd:`Cmd + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:48
msgid "``editor/save_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:50
msgid "Save Scene As"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:50
msgid ":kbd:`Ctrl + Shift + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:50
msgid ":kbd:`Cmd + Shift + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:50
msgid "``editor/save_scene_as``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:52
msgid "Save All Scenes"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:52
#: ../../docs/getting_started/editor/default_key_mapping.rst:320
msgid ":kbd:`Ctrl + Shift + Alt + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:52
#: ../../docs/getting_started/editor/default_key_mapping.rst:320
msgid ":kbd:`Cmd + Shift + Alt + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:52
msgid "``editor/save_all_scenes``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:54
msgid "Quick Open"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:54
msgid ":kbd:`Shift + Alt + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:54
msgid "``editor/quick_open``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:56
msgid "Quick Open Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:56
msgid ":kbd:`Ctrl + Shift + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:56
msgid ":kbd:`Cmd + Shift + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:56
msgid "``editor/quick_open_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:58
msgid "Quick Open Script"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:58
msgid ":kbd:`Ctrl + Alt + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:58
msgid ":kbd:`Cmd + Alt + O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:58
msgid "``editor/quick_open_script``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:60
#: ../../docs/getting_started/editor/default_key_mapping.rst:239
msgid "Undo"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:60
#: ../../docs/getting_started/editor/default_key_mapping.rst:239
msgid ":kbd:`Ctrl + Z`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:60
#: ../../docs/getting_started/editor/default_key_mapping.rst:239
msgid ":kbd:`Cmd + Z`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:60
msgid "``editor/undo``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:62
#: ../../docs/getting_started/editor/default_key_mapping.rst:241
msgid "Redo"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:62
msgid ":kbd:`Ctrl + Shift + Z`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:62
msgid ":kbd:`Cmd + Shift + Z`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:62
msgid "``editor/redo``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:64
msgid "Quit"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:64
msgid ":kbd:`Ctrl + Q`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:64
msgid ":kbd:`Cmd + Q`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:64
msgid "``editor/file_quit``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:66
msgid "Quit to Project List"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:66
msgid ":kbd:`Ctrl + Shift + Q`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:66
msgid ":kbd:`Shift + Alt + Q`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:66
msgid "``editor/quit_to_project_list``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:68
msgid "Take Screenshot"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:68
msgid ":kbd:`Ctrl + F12`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:68
msgid ":kbd:`Cmd + F12`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:68
msgid "``editor/take_screenshot``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:70
msgid "Toggle Fullscreen"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:70
msgid ":kbd:`Shift + F11`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:70
msgid ":kbd:`Cmd + Ctrl + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:70
msgid "``editor/fullscreen_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:72
msgid "Play"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:72
#: ../../docs/getting_started/editor/default_key_mapping.rst:402
msgid ":kbd:`F5`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:72
#: ../../docs/getting_started/editor/default_key_mapping.rst:275
msgid ":kbd:`Cmd + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:72
msgid "``editor/play``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:74
msgid "Pause Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:74
msgid ":kbd:`F7`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:74
msgid ":kbd:`Cmd + Ctrl + Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:74
msgid "``editor/pause_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:76
msgid "Stop"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:76
msgid ":kbd:`F8`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:76
#: ../../docs/getting_started/editor/default_key_mapping.rst:287
msgid ":kbd:`Cmd + .`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:76
msgid "``editor/stop``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:78
msgid "Play Scene"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:78
msgid ":kbd:`F6`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:78
#: ../../docs/getting_started/editor/default_key_mapping.rst:361
msgid ":kbd:`Cmd + R`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:78
msgid "``editor/play_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:80
#, fuzzy
msgid "Play Custom Scene"
msgstr "אותות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:80
msgid ":kbd:`Ctrl + Shift + F5`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:80
#: ../../docs/getting_started/editor/default_key_mapping.rst:237
#: ../../docs/getting_started/editor/default_key_mapping.rst:322
msgid ":kbd:`Cmd + Shift + R`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:80
msgid "``editor/play_custom_scene``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:82
msgid "Expand Bottom Panel"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:82
msgid ":kbd:`Shift + F12`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:82
msgid "``editor/bottom_panel_expand``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:86
msgid "2D / Canvas Item Editor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:91
#: ../../docs/getting_started/editor/default_key_mapping.rst:334
msgid "Zoom In"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:91
#: ../../docs/getting_started/editor/default_key_mapping.rst:334
msgid ":kbd:`Ctrl + =`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:91
#: ../../docs/getting_started/editor/default_key_mapping.rst:334
msgid ":kbd:`Cmd + =`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:91
msgid "``canvas_item_editor/zoom_plus``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:93
#: ../../docs/getting_started/editor/default_key_mapping.rst:336
msgid "Zoom Out"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:93
#: ../../docs/getting_started/editor/default_key_mapping.rst:336
msgid ":kbd:`Ctrl + -`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:93
#: ../../docs/getting_started/editor/default_key_mapping.rst:336
msgid ":kbd:`Cmd + -`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:93
msgid "``canvas_item_editor/zoom_minus``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:95
msgid "Zoom Reset"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:95
#: ../../docs/getting_started/editor/default_key_mapping.rst:338
msgid ":kbd:`Ctrl + 0`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:95
#: ../../docs/getting_started/editor/default_key_mapping.rst:338
msgid ":kbd:`Cmd + 0`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:95
msgid "``canvas_item_editor/zoom_reset``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:97
msgid "Pan View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:97
msgid ":kbd:`Space`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:97
msgid "``canvas_item_editor/pan_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:99
#: ../../docs/getting_started/editor/default_key_mapping.rst:162
msgid "Select Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:99
#: ../../docs/getting_started/editor/default_key_mapping.rst:156
#: ../../docs/getting_started/editor/default_key_mapping.rst:162
msgid ":kbd:`Q`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:99
msgid "``canvas_item_editor/select_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:101
#: ../../docs/getting_started/editor/default_key_mapping.rst:164
msgid "Move Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:101
#: ../../docs/getting_started/editor/default_key_mapping.rst:150
#: ../../docs/getting_started/editor/default_key_mapping.rst:164
#: ../../docs/getting_started/editor/default_key_mapping.rst:498
msgid ":kbd:`W`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:101
msgid "``canvas_item_editor/move_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:103
#: ../../docs/getting_started/editor/default_key_mapping.rst:166
msgid "Rotate Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:103
#: ../../docs/getting_started/editor/default_key_mapping.rst:154
#: ../../docs/getting_started/editor/default_key_mapping.rst:166
msgid ":kbd:`E`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:103
msgid "``canvas_item_editor/rotate_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:105
#: ../../docs/getting_started/editor/default_key_mapping.rst:168
msgid "Scale Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:105
#: ../../docs/getting_started/editor/default_key_mapping.rst:152
#: ../../docs/getting_started/editor/default_key_mapping.rst:496
msgid ":kbd:`S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:105
msgid "``canvas_item_editor/scale_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:107
msgid "Ruler Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:107
#: ../../docs/getting_started/editor/default_key_mapping.rst:168
msgid ":kbd:`R`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:107
msgid "``canvas_item_editor/ruler_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:109
msgid "Use Smart Snap"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:109
msgid ":kbd:`Shift + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:109
msgid "``canvas_item_editor/use_smart_snap``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:111
msgid "Use Grid Snap"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:111
msgid ":kbd:`Shift + G`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:111
msgid "``canvas_item_editor/use_grid_snap``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:113
msgid "Multiply grid step by 2"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:113
msgid ":kbd:`Num *`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:113
msgid "``canvas_item_editor/multiply_grid_step``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:115
msgid "Divide grid step by 2"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:115
msgid ":kbd:`Num /`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:115
msgid "``canvas_item_editor/divide_grid_step``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:117
msgid "Always Show Grid"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:117
#: ../../docs/getting_started/editor/default_key_mapping.rst:486
msgid ":kbd:`G`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:117
msgid "``canvas_item_editor/show_grid``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:119
msgid "Show Helpers"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:119
msgid ":kbd:`H`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:119
msgid "``canvas_item_editor/show_helpers``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:121
msgid "Show Guides"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:121
#: ../../docs/getting_started/editor/default_key_mapping.rst:172
msgid ":kbd:`Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:121
msgid "``canvas_item_editor/show_guides``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:123
msgid "Center Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:123
#: ../../docs/getting_started/editor/default_key_mapping.rst:194
msgid ":kbd:`F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:123
msgid "``canvas_item_editor/center_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:125
msgid "Frame Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:125
#: ../../docs/getting_started/editor/default_key_mapping.rst:144
msgid ":kbd:`Shift + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:125
msgid "``canvas_item_editor/frame_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:127
msgid "Preview Canvas Scale"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:127
msgid ":kbd:`Ctrl + Shift + P`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:127
msgid ":kbd:`Cmd + Shift + P`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:127
msgid "``canvas_item_editor/preview_canvas_scale``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:129
msgid "Insert Key"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:129
msgid ":kbd:`Ins`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:129
msgid "``canvas_item_editor/anim_insert_key``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:131
msgid "Insert Key (Existing Tracks)"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:131
msgid ":kbd:`Ctrl + Ins`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:131
msgid ":kbd:`Cmd + Ins`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:131
msgid "``canvas_item_editor/anim_insert_key_existing_tracks``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:133
msgid "Make Custom Bones from Nodes"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:133
#: ../../docs/getting_started/editor/default_key_mapping.rst:277
msgid ":kbd:`Ctrl + Shift + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:133
#: ../../docs/getting_started/editor/default_key_mapping.rst:277
#: ../../docs/getting_started/editor/default_key_mapping.rst:283
msgid ":kbd:`Cmd + Shift + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:133
msgid "``canvas_item_editor/skeleton_make_bones``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:135
msgid "Clear Pose"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:135
msgid ":kbd:`Shift + K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:135
msgid "``canvas_item_editor/anim_clear_pose``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:139
msgid "3D / Spatial Editor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:144
msgid "Toggle Freelook"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:144
msgid "``spatial_editor/freelook_toggle``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:146
msgid "Freelook Left"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:146
#: ../../docs/getting_started/editor/default_key_mapping.rst:494
msgid ":kbd:`A`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:146
msgid "``spatial_editor/freelook_left``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:148
msgid "Freelook Right"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:148
msgid ":kbd:`D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:148
msgid "``spatial_editor/freelook_right``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:150
msgid "Freelook Forward"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:150
msgid "``spatial_editor/freelook_forward``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:152
msgid "Freelook Backwards"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:152
msgid "``spatial_editor/freelook_backwards``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:154
msgid "Freelook Up"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:154
msgid "``spatial_editor/freelook_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:156
msgid "Freelook Down"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:156
msgid "``spatial_editor/freelook_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:158
msgid "Freelook Speed Modifier"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:158
msgid ":kbd:`Shift`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:158
msgid "``spatial_editor/freelook_speed_modifier``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:160
msgid "Freelook Slow Modifier"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:160
msgid ":kbd:`Alt`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:160
msgid "``spatial_editor/freelook_slow_modifier``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:162
msgid "``spatial_editor/tool_select``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:164
msgid "``spatial_editor/tool_move``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:166
msgid "``spatial_editor/tool_rotate``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:168
msgid "``spatial_editor/tool_scale``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:170
msgid "Use Local Space"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:170
#: ../../docs/getting_started/editor/default_key_mapping.rst:488
msgid ":kbd:`T`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:170
msgid "``spatial_editor/local_coords``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:172
msgid "Use Snap"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:172
msgid "``spatial_editor/snap``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:174
msgid "Snap Object to Floor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:174
#: ../../docs/getting_started/editor/default_key_mapping.rst:515
msgid ":kbd:`PgDown`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:174
msgid "``spatial_editor/snap_to_floor``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:176
msgid "Top View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:176
msgid ":kbd:`Num 7`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:176
msgid "``spatial_editor/top_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:178
msgid "Bottom View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:178
msgid ":kbd:`Alt + Num 7`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:178
msgid "``spatial_editor/bottom_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:180
msgid "Front View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:180
msgid ":kbd:`Num 1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:180
msgid "``spatial_editor/front_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:182
msgid "Rear View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:182
msgid ":kbd:`Alt + Num 1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:182
msgid "``spatial_editor/rear_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:184
msgid "Right View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:184
msgid ":kbd:`Num 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:184
msgid "``spatial_editor/right_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:186
msgid "Left View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:186
msgid ":kbd:`Alt + Num 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:186
msgid "``spatial_editor/left_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:188
msgid "Switch Perspective/Orthogonal View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:188
msgid ":kbd:`Num 5`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:188
msgid "``spatial_editor/switch_perspective_orthogonal``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:190
#, fuzzy
msgid "Insert Animation Key"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:190
msgid ":kbd:`K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:190
msgid "``spatial_editor/insert_anim_key``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:192
msgid "Focus Origin"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:192
msgid ":kbd:`O`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:192
msgid "``spatial_editor/focus_origin``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:194
msgid "Focus Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:194
msgid "``spatial_editor/focus_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:196
msgid "Align Transform with View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:196
msgid ":kbd:`Ctrl + Alt + M`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:196
msgid ":kbd:`Cmd + Alt + M`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:196
msgid "``spatial_editor/align_transform_with_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:198
msgid "Align Rotation with View"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:198
#: ../../docs/getting_started/editor/default_key_mapping.rst:279
msgid ":kbd:`Ctrl + Alt + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:198
msgid ":kbd:`Cmd + Alt + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:198
msgid "``spatial_editor/align_rotation_with_view``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:200
msgid "1 Viewport"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:200
msgid ":kbd:`Ctrl + 1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:200
msgid ":kbd:`Cmd + 1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:200
msgid "``spatial_editor/1_viewport``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:202
msgid "2 Viewports"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:202
msgid ":kbd:`Ctrl + 2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:202
msgid ":kbd:`Cmd + 2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:202
msgid "``spatial_editor/2_viewports``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:204
msgid "2 Viewports (Alt)"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:204
msgid ":kbd:`Ctrl + Alt + 2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:204
msgid ":kbd:`Cmd + Alt + 2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:204
msgid "``spatial_editor/2_viewports_alt``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:206
msgid "3 Viewports"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:206
msgid ":kbd:`Ctrl + 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:206
msgid ":kbd:`Cmd + 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:206
msgid "``spatial_editor/3_viewports``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:208
msgid "3 Viewports (Alt)"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:208
msgid ":kbd:`Ctrl + Alt + 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:208
msgid ":kbd:`Cmd + Alt + 3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:208
msgid "``spatial_editor/3_viewports_alt``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:210
msgid "4 Viewports"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:210
msgid ":kbd:`Ctrl + 4`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:210
msgid ":kbd:`Cmd + 4`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:210
msgid "``spatial_editor/4_viewports``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:214
#, fuzzy
msgid "Text Editor"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:219
msgid "Cut"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:219
#: ../../docs/getting_started/editor/default_key_mapping.rst:351
#: ../../docs/getting_started/editor/default_key_mapping.rst:502
msgid ":kbd:`Ctrl + X`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:219
#: ../../docs/getting_started/editor/default_key_mapping.rst:351
#: ../../docs/getting_started/editor/default_key_mapping.rst:502
msgid ":kbd:`Cmd + X`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:219
msgid "``script_text_editor/cut``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:221
msgid "Copy"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:221
#: ../../docs/getting_started/editor/default_key_mapping.rst:349
#: ../../docs/getting_started/editor/default_key_mapping.rst:372
#: ../../docs/getting_started/editor/default_key_mapping.rst:427
#: ../../docs/getting_started/editor/default_key_mapping.rst:444
#: ../../docs/getting_started/editor/default_key_mapping.rst:504
msgid ":kbd:`Ctrl + C`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:221
#: ../../docs/getting_started/editor/default_key_mapping.rst:349
#: ../../docs/getting_started/editor/default_key_mapping.rst:372
#: ../../docs/getting_started/editor/default_key_mapping.rst:427
#: ../../docs/getting_started/editor/default_key_mapping.rst:444
#: ../../docs/getting_started/editor/default_key_mapping.rst:504
msgid ":kbd:`Cmd + C`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:221
msgid "``script_text_editor/copy``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:223
msgid "Paste"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:223
#: ../../docs/getting_started/editor/default_key_mapping.rst:353
msgid ":kbd:`Ctrl + V`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:223
#: ../../docs/getting_started/editor/default_key_mapping.rst:353
msgid ":kbd:`Cmd + V`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:223
msgid "``script_text_editor/paste``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:225
msgid "Select All"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:225
#: ../../docs/getting_started/editor/default_key_mapping.rst:440
msgid ":kbd:`Ctrl + A`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:225
#: ../../docs/getting_started/editor/default_key_mapping.rst:440
msgid ":kbd:`Cmd + A`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:225
msgid "``script_text_editor/select_all``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:227
#: ../../docs/getting_started/editor/default_key_mapping.rst:300
msgid "Find"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:227
#: ../../docs/getting_started/editor/default_key_mapping.rst:300
#: ../../docs/getting_started/editor/default_key_mapping.rst:347
#: ../../docs/getting_started/editor/default_key_mapping.rst:480
msgid ":kbd:`Ctrl + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:227
#: ../../docs/getting_started/editor/default_key_mapping.rst:300
#: ../../docs/getting_started/editor/default_key_mapping.rst:347
#: ../../docs/getting_started/editor/default_key_mapping.rst:480
msgid ":kbd:`Cmd + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:227
msgid "``script_text_editor/find``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:229
#: ../../docs/getting_started/editor/default_key_mapping.rst:302
msgid "Find Next"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:229
#: ../../docs/getting_started/editor/default_key_mapping.rst:357
msgid ":kbd:`Cmd + G`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:229
msgid "``script_text_editor/find_next``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:231
#: ../../docs/getting_started/editor/default_key_mapping.rst:304
msgid "Find Previous"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:231
#: ../../docs/getting_started/editor/default_key_mapping.rst:304
msgid ":kbd:`Shift + F3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:231
msgid ":kbd:`Cmd + Shift + G`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:231
msgid "``script_text_editor/find_previous``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:233
#: ../../docs/getting_started/editor/default_key_mapping.rst:306
#, fuzzy
msgid "Find in Files"
msgstr "Android"

#: ../../docs/getting_started/editor/default_key_mapping.rst:233
#: ../../docs/getting_started/editor/default_key_mapping.rst:306
msgid ":kbd:`Ctrl + Shift + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:233
#: ../../docs/getting_started/editor/default_key_mapping.rst:306
msgid ":kbd:`Cmd + Shift + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:233
msgid "``script_text_editor/find_in_files``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:235
msgid "Replace"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:235
#: ../../docs/getting_started/editor/default_key_mapping.rst:361
msgid ":kbd:`Ctrl + R`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:235
msgid ":kbd:`Alt + Cmd + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:235
msgid "``script_text_editor/replace``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:237
msgid "Replace in Files"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:237
#: ../../docs/getting_started/editor/default_key_mapping.rst:322
msgid ":kbd:`Ctrl + Shift + R`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:237
msgid "``script_text_editor/replace_in_files``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:239
msgid "``script_text_editor/undo``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:241
msgid ":kbd:`Ctrl + Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:241
msgid ":kbd:`Cmd + Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:241
msgid "``script_text_editor/redo``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:243
#: ../../docs/getting_started/editor/default_key_mapping.rst:308
#: ../../docs/getting_started/editor/default_key_mapping.rst:452
msgid "Move Up"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:243
#: ../../docs/getting_started/editor/default_key_mapping.rst:400
msgid ":kbd:`Alt + Up Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:243
msgid "``script_text_editor/move_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:245
#: ../../docs/getting_started/editor/default_key_mapping.rst:310
#: ../../docs/getting_started/editor/default_key_mapping.rst:454
msgid "Move Down"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:245
msgid ":kbd:`Alt + Down Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:245
msgid "``script_text_editor/move_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:247
msgid "Delete Line"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:247
#: ../../docs/getting_started/editor/default_key_mapping.rst:374
msgid ":kbd:`Ctrl + Shift + K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:247
#: ../../docs/getting_started/editor/default_key_mapping.rst:374
msgid ":kbd:`Cmd + Shift + K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:247
msgid "``script_text_editor/delete_line``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:249
msgid "Toggle Comment"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:249
msgid ":kbd:`Ctrl + K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:249
msgid ":kbd:`Cmd + K`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:249
msgid "``script_text_editor/toggle_comment``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:251
msgid "Fold/Unfold Line"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:251
#: ../../docs/getting_started/editor/default_key_mapping.rst:406
msgid ":kbd:`Alt + F`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:251
msgid "``script_text_editor/toggle_fold_line``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:253
msgid "Clone Down"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:253
#: ../../docs/getting_started/editor/default_key_mapping.rst:414
#: ../../docs/getting_started/editor/default_key_mapping.rst:429
#: ../../docs/getting_started/editor/default_key_mapping.rst:450
#: ../../docs/getting_started/editor/default_key_mapping.rst:463
msgid ":kbd:`Ctrl + D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:253
msgid ":kbd:`Cmd + Shift + C`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:253
msgid "``script_text_editor/clone_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:255
msgid "Complete Symbol"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:255
msgid ":kbd:`Ctrl + Space`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:255
msgid "``script_text_editor/complete_symbol``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:257
msgid "Evaluate Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:257
msgid ":kbd:`Ctrl + Shift + E`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:257
msgid ":kbd:`Cmd + Shift + E`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:257
msgid "``script_text_editor/evaluate_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:259
msgid "Trim Trailing Whitespace"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:259
msgid ":kbd:`Ctrl + Alt + T`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:259
msgid ":kbd:`Cmd + Alt + T`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:259
msgid "``script_text_editor/trim_trailing_whitespace``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:261
msgid "Uppercase"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:261
msgid ":kbd:`Shift + F4`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:261
msgid "``script_text_editor/convert_to_uppercase``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:263
msgid "Lowercase"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:263
msgid ":kbd:`Shift + F5`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:263
msgid "``script_text_editor/convert_to_lowercase``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:265
msgid "Capitalize"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:265
msgid ":kbd:`Shift + F6`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:265
msgid "``script_text_editor/capitalize``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:267
msgid "Convert Indent to Spaces"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:267
msgid ":kbd:`Ctrl + Shift + Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:267
msgid ":kbd:`Cmd + Shift + Y`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:267
msgid "``script_text_editor/convert_indent_to_spaces``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:269
msgid "Convert Indent to Tabs"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:269
msgid ":kbd:`Ctrl + Shift + I`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:269
msgid ":kbd:`Cmd + Shift + I`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:269
msgid "``script_text_editor/convert_indent_to_tabs``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:271
msgid "Auto Indent"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:271
msgid ":kbd:`Ctrl + I`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:271
msgid ":kbd:`Cmd + I`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:271
msgid "``script_text_editor/auto_indent``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:273
msgid "Toggle Bookmark"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:273
msgid ":kbd:`Ctrl + Alt + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:273
msgid ":kbd:`Cmd + Alt + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:273
msgid "``script_text_editor/toggle_bookmark``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:275
msgid "Go to Next Bookmark"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:275
msgid ":kbd:`Ctrl + B`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:275
msgid "``script_text_editor/goto_next_bookmark``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:277
msgid "Go to Previous Bookmark"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:277
msgid "``script_text_editor/goto_previous_bookmark``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:279
#, fuzzy
msgid "Go to Function"
msgstr "מבוא"

#: ../../docs/getting_started/editor/default_key_mapping.rst:279
msgid ":kbd:`Ctrl + Cmd + J`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:279
msgid "``script_text_editor/goto_function``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:281
msgid "Go to Line"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:281
msgid ":kbd:`Ctrl + L`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:281
msgid ":kbd:`Cmd + L`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:281
msgid "``script_text_editor/goto_line``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:283
#: ../../docs/getting_started/editor/default_key_mapping.rst:363
msgid "Toggle Breakpoint"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:283
#: ../../docs/getting_started/editor/default_key_mapping.rst:363
msgid ":kbd:`F9`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:283
msgid "``script_text_editor/toggle_breakpoint``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:285
msgid "Remove All Breakpoints"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:285
msgid ":kbd:`Ctrl + Shift + F9`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:285
msgid ":kbd:`Cmd + Shift + F9`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:285
msgid "``script_text_editor/remove_all_breakpoints``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:287
msgid "Go to Next Breakpoint"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:287
msgid ":kbd:`Ctrl + .`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:287
msgid "``script_text_editor/goto_next_breakpoint``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:289
msgid "Go to Previous Breakpoint"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:289
msgid ":kbd:`Ctrl + ,`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:289
msgid ":kbd:`Cmd + ,`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:289
msgid "``script_text_editor/goto_previous_breakpoint``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:291
msgid "Contextual Help"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:291
msgid ":kbd:`Alt + F1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:291
msgid ":kbd:`Alt + Shift + Space`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:291
msgid "``script_text_editor/contextual_help``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:295
#, fuzzy
msgid "Script Editor"
msgstr "נתיב"

#: ../../docs/getting_started/editor/default_key_mapping.rst:300
msgid "``script_editor/find``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:302
msgid "``script_editor/find_next``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:304
msgid "``script_editor/find_previous``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:306
msgid "``script_editor/find_in_files``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:308
msgid ":kbd:`Shift + Alt + Up Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:308
msgid "``script_editor/window_move_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:310
msgid ":kbd:`Shift + Alt + Down Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:310
msgid "``script_editor/window_move_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:312
#, fuzzy
msgid "Next Script"
msgstr "תיאור"

#: ../../docs/getting_started/editor/default_key_mapping.rst:312
msgid ":kbd:`Ctrl + Shift + .`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:312
msgid ":kbd:`Cmd + Shift + .`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:312
msgid "``script_editor/next_script``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:314
msgid "Previous Script"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:314
msgid ":kbd:`Ctrl + Shift + ,`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:314
msgid ":kbd:`Cmd + Shift + ,`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:314
msgid "``script_editor/prev_script``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:316
msgid "Reopen Closed Script"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:316
msgid "``script_editor/reopen_closed_script``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:318
msgid "Save"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:318
msgid ":kbd:`Ctrl + Alt + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:318
msgid ":kbd:`Cmd + Alt + S`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:318
msgid "``script_editor/save``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:320
msgid "Save All"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:320
msgid "``script_editor/save_all``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:322
msgid "Soft Reload Script"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:322
msgid "``script_editor/reload_script_soft``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:324
msgid "History Previous"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:324
#: ../../docs/getting_started/editor/default_key_mapping.rst:396
msgid ":kbd:`Alt + Left Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:324
msgid "``script_editor/history_previous``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:326
msgid "History Next"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:326
#: ../../docs/getting_started/editor/default_key_mapping.rst:398
msgid ":kbd:`Alt + Right Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:326
msgid "``script_editor/history_next``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:328
msgid "Close"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:328
msgid ":kbd:`Ctrl + W`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:328
msgid ":kbd:`Cmd + W`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:328
msgid "``script_editor/close_file``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:330
#: ../../docs/development/compiling/compiling_for_ios.rst:70
msgid "Run"
msgstr "הרצה"

#: ../../docs/getting_started/editor/default_key_mapping.rst:330
msgid ":kbd:`Ctrl + Shift + X`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:330
msgid ":kbd:`Cmd + Shift + X`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:330
msgid "``script_editor/run_file``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:332
msgid "Toggle Scripts Panel"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:332
msgid ":kbd:`Ctrl + \\\\`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:332
msgid ":kbd:`Cmd + \\\\`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:332
msgid "``script_editor/toggle_scripts_panel``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:334
msgid "``script_editor/zoom_in``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:336
msgid "``script_editor/zoom_out``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:338
msgid "Reset Zoom"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:338
msgid "``script_editor/reset_zoom``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:342
msgid "Visual Script Editor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:347
msgid "Find Node Type"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:347
msgid "``visual_script_editor/find_node_type``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:349
msgid "Copy Nodes"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:349
msgid "``visual_script_editor/copy_nodes``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:351
msgid "Cut Nodes"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:351
msgid "``visual_script_editor/cut_nodes``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:353
msgid "Paste Nodes"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:353
msgid "``visual_script_editor/paste_nodes``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:355
msgid "Delete Selected"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:355
#: ../../docs/getting_started/editor/default_key_mapping.rst:412
#: ../../docs/getting_started/editor/default_key_mapping.rst:431
#: ../../docs/getting_started/editor/default_key_mapping.rst:446
#: ../../docs/getting_started/editor/default_key_mapping.rst:467
#: ../../docs/getting_started/editor/default_key_mapping.rst:506
msgid ":kbd:`Del`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:355
#: ../../docs/getting_started/editor/default_key_mapping.rst:412
#: ../../docs/getting_started/editor/default_key_mapping.rst:431
#: ../../docs/getting_started/editor/default_key_mapping.rst:446
#: ../../docs/getting_started/editor/default_key_mapping.rst:467
#: ../../docs/getting_started/editor/default_key_mapping.rst:506
msgid ":kbd:`Cmd + BkSp`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:355
msgid "``visual_script_editor/delete_selected``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:357
msgid "Make Function"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:357
msgid ":kbd:`Ctrl + G`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:357
msgid "``visual_script_editor/create_function``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:359
#, fuzzy
msgid "Edit Member"
msgstr "חברים"

#: ../../docs/getting_started/editor/default_key_mapping.rst:359
msgid ":kbd:`Ctrl + E`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:359
msgid ":kbd:`Cmd + E`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:359
msgid "``visual_script_editor/edit_member``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:361
msgid "Refresh Graph"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:361
msgid "``visual_script_editor/refresh_nodes``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:363
msgid "``visual_script_editor/toggle_breakpoint``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:367
#, fuzzy
msgid "Editor Output"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:372
#: ../../docs/getting_started/editor/default_key_mapping.rst:504
msgid "Copy Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:372
msgid "``editor/copy_output``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:374
msgid "Clear Output"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:374
msgid "``editor/clear_output``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:378
#: ../../docs/tutorials/debug/debugger_panel.rst:14
msgid "Debugger"
msgstr "ניפוי שגיאות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:383
msgid "Step Into"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:383
msgid ":kbd:`F11`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:383
msgid "``debugger/step_into``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:385
msgid "Step Over"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:385
msgid ":kbd:`F10`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:385
msgid "``debugger/step_over``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:387
msgid "Continue"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:387
msgid ":kbd:`F12`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:387
msgid "``debugger/continue``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:391
msgid "File Dialog"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:396
msgid "Go Back"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:396
msgid "``file_dialog/go_back``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:398
msgid "Go Forward"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:398
msgid "``file_dialog/go_forward``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:400
msgid "Go Up"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:400
msgid "``file_dialog/go_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:402
msgid "Refresh"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:402
msgid "``file_dialog/refresh``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:404
msgid "Toggle Hidden Files"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:404
msgid ":kbd:`Ctrl + H`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:404
msgid ":kbd:`Cmd + H`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:404
msgid "``file_dialog/toggle_hidden_files``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:406
msgid "Toggle Favorite"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:406
msgid "``file_dialog/toggle_favorite``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:408
msgid "Toggle Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:408
msgid ":kbd:`Alt + V`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:408
msgid "``file_dialog/toggle_mode``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:410
msgid "Create Folder"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:410
msgid ":kbd:`Ctrl + N`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:410
msgid ":kbd:`Cmd + N`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:410
msgid "``file_dialog/create_folder``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:412
#: ../../docs/getting_started/editor/default_key_mapping.rst:431
#: ../../docs/getting_started/editor/default_key_mapping.rst:446
msgid "Delete"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:412
msgid "``file_dialog/delete``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:414
msgid "Focus Path"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:414
#: ../../docs/getting_started/editor/default_key_mapping.rst:429
#: ../../docs/getting_started/editor/default_key_mapping.rst:450
#: ../../docs/getting_started/editor/default_key_mapping.rst:463
msgid ":kbd:`Cmd + D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:414
msgid "``file_dialog/focus_path``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:416
msgid "Move Favorite Up"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:416
#: ../../docs/getting_started/editor/default_key_mapping.rst:452
msgid ":kbd:`Ctrl + Up Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:416
#: ../../docs/getting_started/editor/default_key_mapping.rst:452
msgid ":kbd:`Cmd + Up Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:416
msgid "``file_dialog/move_favorite_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:418
msgid "Move Favorite Down"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:418
#: ../../docs/getting_started/editor/default_key_mapping.rst:454
msgid ":kbd:`Ctrl + Down Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:418
#: ../../docs/getting_started/editor/default_key_mapping.rst:454
msgid ":kbd:`Cmd + Down Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:418
msgid "``file_dialog/move_favorite_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:422
msgid "FileSystem Dock"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:427
#, fuzzy
msgid "Copy Path"
msgstr "נתיב"

#: ../../docs/getting_started/editor/default_key_mapping.rst:427
msgid "``filesystem_dock/copy_path``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:429
#: ../../docs/getting_started/editor/default_key_mapping.rst:450
msgid "Duplicate"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:429
msgid "``filesystem_dock/duplicate``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:431
msgid "``filesystem_dock/delete``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:435
msgid "Scene Tree Dock"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:440
msgid "Add Child Node"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:440
msgid "``scene_tree/add_child_node``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:442
msgid "Batch Rename"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:442
msgid ":kbd:`Ctrl + F2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:442
msgid ":kbd:`Cmd + F2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:442
msgid "``scene_tree/batch_rename``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:444
msgid "Copy Node Path"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:444
msgid "``scene_tree/copy_node_path``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:446
msgid "``scene_tree/delete``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:448
msgid "Force Delete"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:448
msgid ":kbd:`Shift + Del`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:448
msgid "``scene_tree/delete_no_confirm``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:450
msgid "``scene_tree/duplicate``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:452
msgid "``scene_tree/move_up``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:454
msgid "``scene_tree/move_down``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:458
#, fuzzy
msgid "Animation Track Editor"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:463
msgid "Duplicate Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:463
msgid "``animation_editor/duplicate_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:465
msgid "Duplicate Transposed"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:465
msgid ":kbd:`Ctrl + Shift + D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:465
msgid ":kbd:`Cmd + Shift + D`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:465
msgid "``animation_editor/duplicate_selection_transposed``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:467
msgid "Delete Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:467
msgid "``animation_editor/delete_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:469
msgid "Go to Next Step"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:469
msgid ":kbd:`Ctrl + Right Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:469
msgid ":kbd:`Cmd + Right Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:469
msgid "``animation_editor/goto_next_step``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:471
msgid "Go to Previous Step"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:471
msgid ":kbd:`Ctrl + Left Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:471
msgid ":kbd:`Cmd + Left Arrow`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:471
msgid "``animation_editor/goto_prev_step``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:475
msgid "Tile Map Editor"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:480
msgid "Find Tile"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:480
msgid "``tile_map_editor/find_tile``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:482
msgid "Pick Tile"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:482
msgid ":kbd:`I`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:482
msgid "``tile_map_editor/pick_tile``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:484
msgid "Paint Tile"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:484
msgid ":kbd:`P`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:484
msgid "``tile_map_editor/paint_tile``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:486
msgid "Bucket Fill"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:486
msgid "``tile_map_editor/bucket_fill``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:488
#, fuzzy
msgid "Transpose"
msgstr "התמרה"

#: ../../docs/getting_started/editor/default_key_mapping.rst:488
msgid "``tile_map_editor/transpose``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:490
msgid "Flip Horizontally"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:490
msgid ":kbd:`X`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:490
msgid "``tile_map_editor/flip_horizontal``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:492
msgid "Flip Vertically"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:492
msgid ":kbd:`Z`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:492
msgid "``tile_map_editor/flip_vertical``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:494
msgid "Rotate Left"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:494
msgid "``tile_map_editor/rotate_left``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:496
msgid "Rotate Right"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:496
msgid "``tile_map_editor/rotate_right``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:498
#, fuzzy
msgid "Clear Transform"
msgstr "התמרה"

#: ../../docs/getting_started/editor/default_key_mapping.rst:498
msgid "``tile_map_editor/clear_transform``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:500
msgid "Select"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:500
msgid ":kbd:`M`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:500
msgid "``tile_map_editor/select``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:502
msgid "Cut Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:502
msgid "``tile_map_editor/cut_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:504
msgid "``tile_map_editor/copy_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:506
msgid "Erase Selection"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:506
msgid "``tile_map_editor/erase_selection``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:510
#, fuzzy
msgid "Tileset Editor"
msgstr "עורך"

#: ../../docs/getting_started/editor/default_key_mapping.rst:515
msgid "Next Coordinate"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:515
msgid "``tileset_editor/next_shape``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:517
msgid "Previous Coordinate"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:517
msgid ":kbd:`PgUp`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:517
msgid "``tileset_editor/previous_shape``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:519
#, fuzzy
msgid "Region Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:519
msgid ":kbd:`1`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:519
msgid "``tileset_editor/editmode_region``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:521
#, fuzzy
msgid "Collision Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:521
msgid ":kbd:`2`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:521
msgid "``tileset_editor/editmode_collision``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:523
msgid "Occlusion Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:523
msgid ":kbd:`3`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:523
msgid "``tileset_editor/editmode_occlusion``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:525
#, fuzzy
msgid "Navigation Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:525
msgid ":kbd:`4`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:525
msgid "``tileset_editor/editmode_navigation``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:527
#, fuzzy
msgid "Bitmask Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:527
msgid ":kbd:`5`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:527
msgid "``tileset_editor/editmode_bitmask``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:529
msgid "Priority Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:529
msgid ":kbd:`6`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:529
msgid "``tileset_editor/editmode_priority``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:531
#, fuzzy
msgid "Icon Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/editor/default_key_mapping.rst:531
msgid ":kbd:`7`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:531
msgid "``tileset_editor/editmode_icon``"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:533
msgid "Z Index Mode"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:533
msgid ":kbd:`8`"
msgstr ""

#: ../../docs/getting_started/editor/default_key_mapping.rst:533
msgid "``tileset_editor/editmode_z_index``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:4
msgid "GDScript basics"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:9
msgid ""
"*GDScript* is a high-level, dynamically typed programming language used to "
"create content. It uses a syntax similar to `Python <https://en.wikipedia."
"org/wiki/Python_%28programming_language%29>`_ (blocks are indent-based and "
"many keywords are similar). Its goal is to be optimized for and tightly "
"integrated with Godot Engine, allowing great flexibility for content "
"creation and integration."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:17
msgid "History"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:21
msgid ""
"Documentation about GDScript's history has been moved to the :ref:"
"`Frequently Asked Questions <doc_faq_what_is_gdscript>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:25
msgid "Example of GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:27
msgid ""
"Some people can learn better by taking a look at the syntax, so here's a "
"simple example of how GDScript looks."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:110
msgid ""
"If you have previous experience with statically typed languages such as C, C+"
"+, or C# but never used a dynamically typed one before, it is advised you "
"read this tutorial: :ref:`doc_gdscript_more_efficiently`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:115
#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:12
msgid "Language"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:117
msgid ""
"In the following, an overview is given to GDScript. Details, such as which "
"methods are available to arrays or other objects, should be looked up in the "
"linked class descriptions."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:122
msgid "Identifiers"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:124
msgid ""
"Any string that restricts itself to alphabetic characters (``a`` to ``z`` "
"and ``A`` to ``Z``), digits (``0`` to ``9``) and ``_`` qualifies as an "
"identifier. Additionally, identifiers must not begin with a digit. "
"Identifiers are case-sensitive (``foo`` is different from ``FOO``)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:130
msgid "Keywords"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:132
msgid ""
"The following is the list of keywords supported by the language. Since "
"keywords are reserved words (tokens), they can't be used as identifiers. "
"Operators (like ``in``, ``not``, ``and`` or ``or``) and names of built-in "
"types as listed in the following sections are also reserved."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:137
msgid ""
"Keywords are defined in the `GDScript tokenizer <https://github.com/"
"godotengine/godot/blob/master/modules/gdscript/gdscript_tokenizer.cpp>`_ in "
"case you want to take a look under the hood."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:141
msgid "Keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:143
msgid "if"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:143
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:145
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:147
msgid "See `if/else/elif`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:145
msgid "elif"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:147
msgid "else"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:149
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:801
msgid "for"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:149
msgid "See for_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:151
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:790
msgid "while"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:151
msgid "See while_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:153
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:836
msgid "match"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:153
msgid "See match_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:155
msgid "break"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:155
msgid "Exits the execution of the current ``for`` or ``while`` loop."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:157
msgid "continue"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:157
msgid ""
"Immediately skips to the next iteration of the ``for`` or ``while`` loop."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:159
msgid "pass"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:159
msgid ""
"Used where a statement is required syntactically but execution of code is "
"undesired, e.g. in empty functions."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:161
msgid "return"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:161
msgid "Returns a value from a function."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:163
msgid "class"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:163
msgid "Defines a class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:165
msgid "extends"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:165
msgid "Defines what class to extend with the current class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:167
#: ../../docs/tutorials/i18n/locales.rst:360
msgid "is"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:167
msgid ""
"Tests whether a variable extends a given class, or is of a given built-in "
"type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:169
msgid "as"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:169
msgid "Cast the value to a given type if possible."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:171
msgid "self"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:171
msgid "Refers to current class instance."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:173
msgid "tool"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:173
msgid "Executes the script in the editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:175
msgid "signal"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:175
msgid "Defines a signal."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:177
msgid "func"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:177
msgid "Defines a function."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:179
msgid "static"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:179
msgid "Defines a static function. Static member variables are not allowed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:181
msgid "const"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:181
msgid "Defines a constant."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:183
msgid "enum"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:183
msgid "Defines an enum."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:185
msgid "var"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:185
msgid "Defines a variable."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:187
msgid "onready"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:187
msgid ""
"Initializes a variable once the Node the script is attached to and its "
"children are part of the scene tree."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:189
msgid "export"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:189
msgid ""
"Saves a variable along with the resource it's attached to and makes it "
"visible and modifiable in the editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:191
msgid "setget"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:191
msgid "Defines setter and getter functions for a variable."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:193
msgid "breakpoint"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:193
msgid "Editor helper for debugger breakpoints."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:195
msgid "preload"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:195
msgid "Preloads a class or variable. See `Classes as resources`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:197
msgid "yield"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:197
msgid "Coroutine support. See `Coroutines with yield`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:199
#, fuzzy
msgid "assert"
msgstr "מחלקות"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:199
msgid ""
"Asserts a condition, logs error on failure. Ignored in non-debug builds. See "
"`Assert keyword`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:201
msgid "remote"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:201
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:203
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:205
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:207
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:209
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:211
msgid ""
"Networking RPC annotation. See :ref:`high-level multiplayer docs "
"<doc_high_level_multiplayer>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:203
msgid "master"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:205
msgid "puppet"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:207
msgid "remotesync"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:209
msgid "mastersync"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:211
msgid "puppetsync"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:213
msgid "PI"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:213
#, fuzzy
msgid "PI constant."
msgstr "קבועים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:215
msgid "TAU"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:215
#, fuzzy
msgid "TAU constant."
msgstr "קבועים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:217
msgid "INF"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:217
msgid "Infinity constant. Used for comparisons."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:219
msgid "NAN"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:219
msgid "NAN (not a number) constant. Used for comparisons."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:223
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:470
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:294
msgid "Operators"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:225
msgid "The following is the list of supported operators and their precedence."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:228
msgid "**Operator**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:228
#: ../../docs/getting_started/workflow/export/feature_tags.rst:33
msgid "**Description**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:230
msgid "``x[index]``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:230
msgid "Subscription (highest priority)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:232
msgid "``x.attribute``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:232
msgid "Attribute reference"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:234
msgid "``foo()``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:234
msgid "Function call"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:236
msgid "``is``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:236
msgid "Instance type checker"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:238
msgid "``~``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:238
msgid "Bitwise NOT"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:240
msgid "``-x``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:240
msgid "Negative / Unary negation"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:242
msgid "``*`` ``/`` ``%``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:242
msgid "Multiplication / Division / Remainder"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:244
msgid ""
"These operators have the same behavior as C++. Integer division is truncated "
"rather than returning a fractional number, and the % operator is only "
"available for ints (\"fmod\" for floats)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:250
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:134
msgid "``+``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:250
msgid "Addition / Concatenation of arrays"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:252
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:143
msgid "``-``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:252
#, fuzzy
msgid "Subtraction"
msgstr "מבוא"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:254
msgid "``<<`` ``>>``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:254
msgid "Bit shifting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:256
msgid "``&``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:256
msgid "Bitwise AND"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:258
msgid "``^``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:258
msgid "Bitwise XOR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:260
msgid "``|``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:260
msgid "Bitwise OR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:262
msgid "``<`` ``>`` ``==`` ``!=`` ``>=`` ``<=``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:262
msgid "Comparisons"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:264
msgid "``in``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:264
msgid "Content test"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:266
msgid "``!`` ``not``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:266
msgid "Boolean NOT"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:268
msgid "``and`` ``&&``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:268
msgid "Boolean AND"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:270
msgid "``or`` ``||``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:270
msgid "Boolean OR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:272
msgid "``if x else``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:272
msgid "Ternary if/else"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:274
msgid "``as``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:274
msgid "Type casting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:276
msgid "``=`` ``+=`` ``-=`` ``*=`` ``/=`` ``%=`` ``&=`` ``|=``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:276
msgid "Assignment (lowest priority)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:280
msgid "Literals"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:283
msgid "**Literal**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:283
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:264
msgid "**Type**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:285
msgid "``45``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:285
msgid "Base 10 integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:287
msgid "``0x8F51``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:287
msgid "Base 16 (hexadecimal) integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:289
msgid "``0b101010``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:289
msgid "Base 2 (binary) integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:291
msgid "``3.14``, ``58.1e-10``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:291
msgid "Floating-point number (real)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:293
msgid "``\"Hello\"``, ``\"Hi\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:293
msgid "Strings"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:295
msgid "``\"\"\"Hello\"\"\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:295
msgid "Multiline string"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:297
msgid "``@\"Node/Label\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:297
msgid ":ref:`class_NodePath` or StringName"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:299
#, fuzzy
msgid "``$NodePath``"
msgstr "נתיב"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:299
msgid "Shorthand for ``get_node(\"NodePath\")``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:303
msgid "Comments"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:305
msgid ""
"Anything from a ``#`` to the end of the line is ignored and is considered a "
"comment."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:315
msgid "Built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:317
msgid ""
"Built-in types are stack-allocated. They are passed as values. This means a "
"copy is created on each assignment or when passing them as arguments to "
"functions. The only exceptions are ``Array``\\ s and ``Dictionaries``, which "
"are passed by reference so they are shared. (Pooled arrays such as "
"``PoolByteArray`` are still passed as values.)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:324
msgid "Basic built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:326
msgid "A variable in GDScript can be assigned to several built-in types."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:329
#: ../../docs/tutorials/misc/binary_serialization_api.rst:25
msgid "null"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:331
msgid ""
"``null`` is an empty data type that contains no information and can not be "
"assigned any other value."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:335
msgid ":ref:`bool <class_bool>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:337
msgid "Short for \"boolean\", it can only contain ``true`` or ``false``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:340
#, fuzzy
msgid ":ref:`int <class_int>`"
msgstr "אנימציות"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:342
msgid ""
"Short for \"integer\", it stores whole numbers (positive and negative). It "
"is stored as a 64-bit value, equivalent to \"int64_t\" in C++."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:346
msgid ":ref:`float <class_float>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:348
msgid ""
"Stores real numbers, including decimals, using floating-point values. It is "
"stored as a 64-bit value, equivalent to \"double\" in C++. Note: Currently, "
"data structures such as Vector2, Vector3, and PoolRealArray store 32-bit "
"single-precision \"float\" values."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:354
msgid ":ref:`String <class_String>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:356
msgid ""
"A sequence of characters in `Unicode format <https://en.wikipedia.org/wiki/"
"Unicode>`_. Strings can contain `standard C escape sequences <https://en."
"wikipedia.org/wiki/Escape_sequences_in_C>`_. GDScript also supports :ref:"
"`doc_gdscript_printf`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:362
msgid "Vector built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:365
msgid ":ref:`Vector2 <class_Vector2>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:367
msgid ""
"2D vector type containing ``x`` and ``y`` fields. Can also be accessed as an "
"array."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:371
msgid ":ref:`Rect2 <class_Rect2>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:373
msgid ""
"2D Rectangle type containing two vectors fields: ``position`` and ``size``. "
"Also contains an ``end`` field which is ``position + size``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:377
msgid ":ref:`Vector3 <class_Vector3>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:379
msgid ""
"3D vector type containing ``x``, ``y`` and ``z`` fields. This can also be "
"accessed as an array."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:383
msgid ":ref:`Transform2D <class_Transform2D>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:385
msgid "3×2 matrix used for 2D transforms."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:388
msgid ":ref:`Plane <class_Plane>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:390
msgid ""
"3D Plane type in normalized form that contains a ``normal`` vector field and "
"a ``d`` scalar distance."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:394
msgid ":ref:`Quat <class_Quat>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:396
msgid ""
"Quaternion is a datatype used for representing a 3D rotation. It's useful "
"for interpolating rotations."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:400
msgid ":ref:`AABB <class_AABB>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:402
msgid ""
"Axis-aligned bounding box (or 3D box) contains 2 vectors fields: "
"``position`` and ``size``. Also contains an ``end`` field which is "
"``position + size``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:407
msgid ":ref:`Basis <class_Basis>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:409
msgid ""
"3x3 matrix used for 3D rotation and scale. It contains 3 vector fields "
"(``x``, ``y`` and ``z``) and can also be accessed as an array of 3D vectors."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:414
msgid ":ref:`Transform <class_Transform>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:416
msgid ""
"3D Transform contains a Basis field ``basis`` and a Vector3 field ``origin``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:420
msgid "Engine built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:423
msgid ":ref:`Color <class_Color>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:425
msgid ""
"Color data type contains ``r``, ``g``, ``b``, and ``a`` fields. It can also "
"be accessed as ``h``, ``s``, and ``v`` for hue/saturation/value."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:429
msgid ":ref:`NodePath <class_NodePath>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:431
msgid ""
"Compiled path to a node used mainly in the scene system. It can be easily "
"assigned to, and from, a String."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:435
msgid ":ref:`RID <class_RID>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:437
msgid "Resource ID (RID). Servers use generic RIDs to reference opaque data."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:440
msgid ":ref:`Object <class_Object>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:442
msgid "Base class for anything that is not a built-in type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:445
msgid "Container built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:448
msgid ":ref:`Array <class_Array>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:450
msgid ""
"Generic sequence of arbitrary object types, including other arrays or "
"dictionaries (see below). The array can resize dynamically. Arrays are "
"indexed starting from index ``0``. Negative indices count from the end."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:464
msgid ""
"GDScript arrays are allocated linearly in memory for speed. Large arrays "
"(more than tens of thousands of elements) may however cause memory "
"fragmentation. If this is a concern, special types of arrays are available. "
"These only accept a single data type. They avoid memory fragmentation and "
"use less memory, but are atomic and tend to run slower than generic arrays. "
"They are therefore only recommended to use for large data sets:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:471
msgid ""
":ref:`PoolByteArray <class_PoolByteArray>`: An array of bytes (integers from "
"0 to 255)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:472
msgid ":ref:`PoolIntArray <class_PoolIntArray>`: An array of integers."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:473
msgid ":ref:`PoolRealArray <class_PoolRealArray>`: An array of floats."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:474
msgid ":ref:`PoolStringArray <class_PoolStringArray>`: An array of strings."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:475
msgid ""
":ref:`PoolVector2Array <class_PoolVector2Array>`: An array of :ref:`Vector2 "
"<class_Vector2>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:476
msgid ""
":ref:`PoolVector3Array <class_PoolVector3Array>`: An array of :ref:`Vector3 "
"<class_Vector3>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:477
msgid ""
":ref:`PoolColorArray <class_PoolColorArray>`: An array of :ref:`Color "
"<class_Color>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:480
msgid ":ref:`Dictionary <class_Dictionary>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:482
msgid "Associative container which contains values referenced by unique keys."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:495
msgid ""
"Lua-style table syntax is also supported. Lua-style uses ``=`` instead of ``:"
"`` and doesn't use quotes to mark string keys (making for slightly less to "
"write). However, keys written in this form can't start with a digit (like "
"any GDScript identifier)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:509
msgid ""
"To add a key to an existing dictionary, access it like an existing key and "
"assign to it::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:525
msgid ""
"The bracket syntax can be used to access properties of any :ref:"
"`class_Object`, not just Dictionaries. Keep in mind it will cause a script "
"error when attempting to index a non-existing property. To avoid this, use "
"the :ref:`Object.get() <class_Object_method_get>` and :ref:`Object.set() "
"<class_Object_method_set>` methods instead."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:532
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:228
msgid "Data"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:535
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:131
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:86
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:148
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:212
msgid "Variables"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:537
msgid ""
"Variables can exist as class members or local to functions. They are created "
"with the ``var`` keyword and may, optionally, be assigned a value upon "
"initialization."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:548
msgid ""
"Variables can optionally have a type specification. When a type is "
"specified, the variable will be forced to have always that same type, and "
"trying to assign an incompatible value will raise an error."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:552
msgid ""
"Types are specified in the variable declaration using a ``:`` (colon) symbol "
"after the variable name, followed by the type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:560
msgid ""
"If the variable is initialized within the declaration, the type can be "
"inferred, so it's possible to omit the type name::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:566
msgid ""
"Type inference is only possible if the assigned value has a defined type, "
"otherwise it will raise an error."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:569
#: ../../docs/tutorials/shading/shading_reference/shaders.rst:39
msgid "Valid types are:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:571
msgid "Built-in types (Array, Vector2, int, String, etc.)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:572
msgid "Engine classes (Node, Resource, Reference, etc.)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:573
msgid ""
"Constant names if they contain a script resource (``MyScript`` if you "
"declared ``const MyScript = preload(\"res://my_script.gd\")``)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:574
msgid ""
"Other classes in the same script, respecting scope (``InnerClass."
"NestedClass`` if you declared ``class NestedClass`` inside the ``class "
"InnerClass`` in the same scope)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:575
msgid "Script classes declared with the ``class_name`` keyword."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:578
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:85
msgid "Casting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:580
msgid ""
"Values assigned to typed variables must have a compatible type. If it's "
"needed to coerce a value to be of a certain type, in particular for object "
"types, you can use the casting operator ``as``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:584
msgid ""
"Casting between object types results in the same object if the value is of "
"the same type or a subtype of the cast type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:592
msgid ""
"If the value is not a subtype, the casting operation will result in a "
"``null`` value."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:599
msgid ""
"For built-in types, they will be forcibly converted if possible, otherwise "
"the engine will raise an error."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:608
msgid ""
"Casting is also useful to have better type-safe variables when interacting "
"with the scene tree::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:618
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:211
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:22
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:256
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:71
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:311
#: ../../docs/development/cpp/object_class.rst:94
msgid "Constants"
msgstr "קבועים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:620
msgid ""
"Constants are similar to variables, but must be constants or constant "
"expressions and must be assigned on initialization."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:634
msgid ""
"Although the type of constants is inferred from the assigned value, it's "
"also possible to add explicit type specification::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:640
msgid "Assigning a value of an incompatible type will raise an error."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:643
msgid "Enums"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:645
msgid ""
"Enums are basically a shorthand for constants, and are pretty useful if you "
"want to assign consecutive integers to some constant."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:648
msgid ""
"If you pass a name to the enum, it will put all the keys inside a constant "
"dictionary of that name."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:651
msgid ""
"In Godot 3.1 and later, keys in a named enum are not registered as global "
"constants. They should be accessed prefixed by the enum's name (``Name."
"KEY``); see an example below."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:671
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:391
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:383
msgid "Functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:673
msgid ""
"Functions always belong to a `class <Classes_>`_. The scope priority for "
"variable look-up is: local → class member → global. The ``self`` variable is "
"always available and is provided as an option for accessing class members, "
"but is not always required (and should *not* be sent as the function's first "
"argument, unlike Python)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:686
msgid ""
"A function can ``return`` at any point. The default return value is ``null``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:688
msgid ""
"Functions can also have type specification for the arguments and for the "
"return value. Types for arguments can be added in a similar way to "
"variables::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:694
msgid ""
"If a function argument has a default value, it's possible to infer the type::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:699
msgid ""
"The return type of the function can be specified after the arguments list "
"using the arrow token (``->``)::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:705
msgid ""
"Functions that have a return type **must** return a proper value. Setting "
"the type as ``void`` means the function doesn't return anything. Void "
"functions can return early with the ``return`` keyword, but they can't "
"return any value."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:714
msgid ""
"Non-void functions must **always** return a value, so if your code has "
"branching statements (such as an ``if``/``else`` construct), all the "
"possible paths must have a return. E.g., if you have a ``return`` inside an "
"``if`` block but not after it, the editor will raise an error because if the "
"block is not executed, the function won't have a valid value to return."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:722
msgid "Referencing functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:724
msgid ""
"Contrary to Python, functions are *not* first-class objects in GDScript. "
"This means they cannot be stored in variables, passed as an argument to "
"another function or be returned from other functions. This is for "
"performance reasons."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:728
msgid ""
"To reference a function by name at run-time, (e.g. to store it in a "
"variable, or pass it to another function as an argument) one must use the "
"``call`` or ``funcref`` helpers::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:742
msgid "Static functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:744
msgid ""
"A function can be declared static. When a function is static, it has no "
"access to the instance member variables or ``self``. This is mainly useful "
"to make libraries of helper functions::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:753
msgid "Statements and control flow"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:755
msgid ""
"Statements are standard and can be assignments, function calls, control flow "
"structures, etc (see below). ``;`` as a statement separator is entirely "
"optional."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:760
msgid "if/else/elif"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:762
msgid ""
"Simple conditions are created by using the ``if``/``else``/``elif`` syntax. "
"Parenthesis around conditions are allowed, but not required. Given the "
"nature of the tab-based indentation, ``elif`` can be used instead of "
"``else``/``if`` to maintain a level of indentation."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:776
msgid "Short statements can be written on the same line as the condition::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:783
msgid ""
"Sometimes, you might want to assign a different initial value based on a "
"boolean expression. In this case, ternary-if expressions come in handy::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:792
msgid ""
"Simple loops are created by using ``while`` syntax. Loops can be broken "
"using ``break`` or continued using ``continue``:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:803
msgid ""
"To iterate through a range, such as an array or table, a *for* loop is used. "
"When iterating over an array, the current array element is stored in the "
"loop variable. When iterating over a dictionary, the *index* is stored in "
"the loop variable."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:838
msgid ""
"A ``match`` statement is used to branch execution of a program. It's the "
"equivalent of the ``switch`` statement found in many other languages, but "
"offers some additional features."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:841
msgid "Basic syntax::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:852
msgid "**Crash-course for people who are familiar with switch statements**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:854
msgid "Replace ``switch`` with ``match``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:855
msgid "Remove ``case``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:856
msgid ""
"Remove any ``break``\\ s. If you don't want to ``break`` by default, you can "
"use ``continue`` for a fallthrough."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:857
msgid "Change ``default`` to a single underscore."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:860
msgid "**Control flow**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:862
msgid ""
"The patterns are matched from top to bottom. If a pattern matches, the first "
"corresponding block will be executed. After that, the execution continues "
"below the ``match`` statement. You can use ``continue`` to stop execution in "
"the current block and check for an additional match in the patterns below it."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:866
msgid "There are 6 pattern types:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:878
#, fuzzy
msgid "Constant pattern"
msgstr "קבועים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:869
msgid "Constant primitives, like numbers and strings::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:890
msgid "Variable pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:881
msgid "Matches the contents of a variable/enum::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:904
msgid "Wildcard pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:893
msgid "This pattern matches everything. It's written as a single underscore."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:895
msgid ""
"It can be used as the equivalent of the ``default`` in a ``switch`` "
"statement in other languages::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:917
#, fuzzy
msgid "Binding pattern"
msgstr "אותות"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:907
msgid ""
"A binding pattern introduces a new variable. Like the wildcard pattern, it "
"matches everything - and also gives that value a name. It's especially "
"useful in array and dictionary patterns::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:938
msgid "Array pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:920
msgid ""
"Matches an array. Every single element of the array pattern is a pattern "
"itself, so you can nest them."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:922
msgid ""
"The length of the array is tested first, it has to be the same size as the "
"pattern, otherwise the pattern doesn't match."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:924
msgid ""
"**Open-ended array**: An array can be bigger than the pattern by making the "
"last subpattern ``..``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:926
msgid "Every subpattern has to be comma-separated."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:965
msgid "Dictionary pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:941
msgid ""
"Works in the same way as the array pattern. Every key has to be a constant "
"pattern."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:943
msgid ""
"The size of the dictionary is tested first, it has to be the same size as "
"the pattern, otherwise the pattern doesn't match."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:945
msgid ""
"**Open-ended dictionary**: A dictionary can be bigger than the pattern by "
"making the last subpattern ``..``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:947
msgid "Every subpattern has to be comma separated."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:949
msgid ""
"If you don't specify a value, then only the existence of the key is checked."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:951
msgid "A value pattern is separated from the key pattern with a ``:``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:978
msgid "Multiple patterns"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:968
msgid ""
"You can also specify multiple patterns separated by a comma. These patterns "
"aren't allowed to have any bindings in them."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:981
msgid "Classes"
msgstr "מחלקות"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:983
msgid ""
"By default, all script files are unnamed classes. In this case, you can only "
"reference them using the file's path, using either a relative or an absolute "
"path. For example, if you name a script file ``character.gd``::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:996
msgid ""
"Instead, you can give your class a name to register it as a new type in "
"Godot's editor. For that, you use the ``class_name`` keyword. You can add an "
"optional comma followed by a path to an image, to use it as an icon. Your "
"class will then appear with its new icon in the editor::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1008
msgid "Here's a class file example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1030
msgid ""
"Godot's class syntax is compact: it can only contain member variables or "
"functions. You can use static functions, but not static member variables. In "
"the same way, the engine initializes variables every time you create an "
"instance, and this includes arrays and dictionaries. This is in the spirit "
"of thread safety, since scripts can be initialized in separate threads "
"without the user knowing."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1038
#: ../../docs/getting_started/scripting/cross_language_scripting.rst:204
msgid "Inheritance"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1040
msgid "A class (stored as a file) can inherit from:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1042
msgid "A global class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1043
msgid "Another class file."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1044
msgid "An inner class inside another class file."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1046
msgid "Multiple inheritance is not allowed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1048
msgid "Inheritance uses the ``extends`` keyword::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1060
msgid ""
"To check if a given instance inherits from a given class, the ``is`` keyword "
"can be used::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1072
msgid ""
"To call a function in a *parent class* (i.e. one ``extend``-ed in your "
"current class), prepend ``.`` to the function name::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1077
msgid ""
"This is especially useful because functions in extending classes replace "
"functions with the same name in their parent classes. If you still want to "
"call them, you can prefix them with ``.`` (like the ``super`` keyword in "
"other languages)::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1085
msgid ""
"Default functions like  ``_init``, and most notifications such as "
"``_enter_tree``, ``_exit_tree``, ``_process``, ``_physics_process``, etc. "
"are called in all parent classes automatically. There is no need to call "
"them explicitly when overloading them."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1092
msgid "Class Constructor"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1094
msgid ""
"The class constructor, called on class instantiation, is named ``_init``. As "
"mentioned earlier, the constructors of parent classes are called "
"automatically when inheriting a class. So, there is usually no need to call "
"``._init()`` explicitly."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1099
msgid ""
"Unlike the call of a regular function, like in the above example with ``."
"some_func``, if the constructor from the inherited class takes arguments, "
"they are passed like this::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1106
msgid "This is better explained through examples. Consider this scenario::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1129
#, fuzzy
msgid "There are a few things to keep in mind here:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1131
msgid ""
"If the inherited class (``State.gd``) defines a ``_init`` constructor that "
"takes arguments (``e`` in this case), then the inheriting class (``Idle."
"gd``) *must* define ``_init`` as well and pass appropriate parameters to "
"``_init`` from ``State.gd``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1134
msgid ""
"``Idle.gd`` can have a different number of arguments than the parent class "
"``State.gd``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1135
msgid ""
"In the example above, ``e`` passed to the ``State.gd`` constructor is the "
"same ``e`` passed in to ``Idle.gd``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1137
msgid ""
"If ``Idle.gd``'s ``_init`` constructor takes 0 arguments, it still needs to "
"pass some value to the ``State.gd`` parent class, even if it does nothing. "
"This brings us to the fact that you can pass literals in the base "
"constructor as well, not just variables. eg.::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1147
msgid "Inner classes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1149
msgid ""
"A class file can contain inner classes. Inner classes are defined using the "
"``class`` keyword. They are instanced using the ``ClassName.new()`` function."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1174
msgid "Classes as resources"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1176
msgid ""
"Classes stored as files are treated as :ref:`resources <class_GDScript>`. "
"They must be loaded from disk to access them in other classes. This is done "
"using either the ``load`` or ``preload`` functions (see below). Instancing "
"of a loaded class resource is done by calling the ``new`` function on the "
"class object::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1193
msgid "Exports"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1197
msgid ""
"Documentation about exports has been moved to :ref:`doc_gdscript_exports`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1200
msgid "Setters/getters"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1202
msgid ""
"It is often useful to know when a class' member variable changes for "
"whatever reason. It may also be desired to encapsulate its access in some "
"way."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1205
msgid ""
"For this, GDScript provides a *setter/getter* syntax using the ``setget`` "
"keyword. It is used directly after a variable definition:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1212
msgid ""
"Whenever the value of ``variable`` is modified by an *external* source (i.e. "
"not from local usage in the class), the *setter* function (``setterfunc`` "
"above) will be called. This happens *before* the value is changed. The "
"*setter* must decide what to do with the new value. Vice versa, when "
"``variable`` is accessed, the *getter* function (``getterfunc`` above) must "
"``return`` the desired value. Below is an example::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1228
msgid "Either of the *setter* or *getter* functions can be omitted::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1235
msgid ""
"Setters and getters are useful when :ref:`exporting variables "
"<doc_gdscript_exports>` to the editor in tool scripts or plugins, for "
"validating input."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1238
msgid ""
"As said, *local* access will *not* trigger the setter and getter. Here is an "
"illustration of this:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1255
msgid "Tool mode"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1257
msgid ""
"By default, scripts don't run inside the editor and only the exported "
"properties can be changed. In some cases, it is desired that they do run "
"inside the editor (as long as they don't execute game code or manually avoid "
"doing so). For this, the ``tool`` keyword exists and must be placed at the "
"top of the file::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1271
msgid "See :ref:`doc_running_code_in_the_editor` for more information."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1273
msgid ""
"Be cautious when freeing nodes with ``queue_free()`` or ``free()`` in a tool "
"script (especially the script's owner itself). As tool scripts run their "
"code in the editor, misusing them may lead to crashing the editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1279
msgid "Memory management"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1281
msgid ""
"If a class inherits from :ref:`class_Reference`, then instances will be "
"freed when no longer in use. No garbage collector exists, just reference "
"counting. By default, all classes that don't define inheritance extend "
"**Reference**. If this is not desired, then a class must inherit :ref:"
"`class_Object` manually and must call instance.free(). To avoid reference "
"cycles that can't be freed, a ``weakref`` function is provided for creating "
"weak references."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1289
msgid ""
"Alternatively, when not using references, the "
"``is_instance_valid(instance)`` can be used to check if an object has been "
"freed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1298
msgid ""
"Signals are a tool to emit messages from an object that other objects can "
"react to. To create custom signals for a class, use the ``signal`` keyword."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1311
msgid ""
"Signals are a `Callback <https://en.wikipedia.org/wiki/"
"Callback_(computer_programming)>`_ mechanism. They also fill the role of "
"Observers, a common programming pattern. For more information, read the "
"`Observer tutorial <https://gameprogrammingpatterns.com/observer.html>`_ in "
"the Game Programming Patterns ebook."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1318
msgid ""
"You can connect these signals to methods the same way you connect built-in "
"signals of nodes like :ref:`class_Button` or :ref:`class_RigidBody`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1321
msgid ""
"In the example below, we connect the ``health_depleted`` signal from a "
"``Character`` node to a ``Game`` node. When the ``Character`` node emits the "
"signal, the game node's ``_on_Character_health_depleted`` is called::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1335
msgid "You can emit as many arguments as you want along with a signal."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1337
msgid ""
"Here is an example where this is useful. Let's say we want a life bar on "
"screen to react to health changes with an animation, but we want to keep the "
"user interface separate from the player in our scene tree."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1341
msgid ""
"In our ``Character.gd`` script, we define a ``health_changed`` signal and "
"emit it with :ref:`Object.emit_signal() <class_Object_method_emit_signal>`, "
"and from a ``Game`` node higher up our scene tree, we connect it to the "
"``Lifebar`` using the :ref:`Object.connect() <class_Object_method_connect>` "
"method::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1382
msgid ""
"To use signals, your class has to extend the ``Object`` class or any type "
"extending it like ``Node``, ``KinematicBody``, ``Control``..."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1385
msgid ""
"In the ``Game`` node, we get both the ``Character`` and ``Lifebar`` nodes, "
"then connect the character, that emits the signal, to the receiver, the "
"``Lifebar`` node in this case."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1399
msgid ""
"This allows the ``Lifebar`` to react to health changes without coupling it "
"to the ``Character`` node."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1402
msgid ""
"You can write optional argument names in parentheses after the signal's "
"definition::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1408
msgid ""
"These arguments show up in the editor's node dock, and Godot can use them to "
"generate callback functions for you. However, you can still emit any number "
"of arguments when you emit signals; it's up to you to emit the correct "
"values."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1414
msgid ""
"GDScript can bind an array of values to connections between a signal and a "
"method. When the signal is emitted, the callback method receives the bound "
"values. These bound arguments are unique to each connection, and the values "
"will stay the same."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1419
msgid ""
"You can use this array of values to add extra constant information to the "
"connection if the emitted signal itself doesn't give you access to all the "
"data that you need."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1423
msgid ""
"Building on the example above, let's say we want to display a log of the "
"damage taken by each character on the screen, like ``Player1 took 22 damage."
"``. The ``health_changed`` signal doesn't give us the name of the character "
"that took damage. So when we connect the signal to the in-game console, we "
"can add the character's name in the binds array argument::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1437
msgid ""
"Our ``BattleLog`` node receives each element in the binds array as an extra "
"argument::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1450
msgid "Coroutines with yield"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1452
msgid ""
"GDScript offers support for `coroutines <https://en.wikipedia.org/wiki/"
"Coroutine>`_ via the :ref:`yield<class_@GDScript_method_yield>` built-in "
"function. Calling ``yield()`` will immediately return from the current "
"function, with the current frozen state of the same function as the return "
"value. Calling ``resume()`` on this resulting object will continue execution "
"and return whatever the function returns. Once resumed, the state object "
"becomes invalid. Here is an example::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1473
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1494
msgid "Will print::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1479
msgid ""
"It is also possible to pass values between ``yield()`` and ``resume()``, for "
"example::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1500
msgid ""
"Remember to save the new function state, when using multiple ``yield``\\s::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1515
msgid "Coroutines & signals"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1517
msgid ""
"The real strength of using ``yield`` is when combined with signals. "
"``yield`` can accept two arguments, an object and a signal. When the signal "
"is received, execution will recommence. Here are some examples::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1530
msgid ""
"Coroutines themselves use the ``completed`` signal when they transition into "
"an invalid state, for example::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1542
msgid ""
"``my_func`` will only continue execution once both buttons have been pressed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1544
msgid "You can also get the signal's argument once it's emitted by an object:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1551
msgid ""
"If you're unsure whether a function may yield or not, or whether it may "
"yield multiple times, you can yield to the ``completed`` signal "
"conditionally:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1573
msgid ""
"This ensures that the function returns whatever it was supposed to return "
"irregardless of whether coroutines were used internally. Note that using "
"``while`` would be redundant here as the ``completed`` signal is only "
"emitted when the function didn't yield anymore."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1579
msgid "Onready keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1581
msgid ""
"When using nodes, it's common to desire to keep references to parts of the "
"scene in a variable. As scenes are only warranted to be configured when "
"entering the active scene tree, the sub-nodes can only be obtained when a "
"call to ``Node._ready()`` is made."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1594
msgid ""
"This can get a little cumbersome, especially when nodes and external "
"references pile up. For this, GDScript has the ``onready`` keyword, that "
"defers initialization of a member variable until ``_ready()`` is called. It "
"can replace the above code with a single line::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1602
msgid "Assert keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1604
msgid ""
"The ``assert`` keyword can be used to check conditions in debug builds. "
"These assertions are ignored in non-debug builds. This means that the "
"expression passed as argument won't be evaluated in a project exported in "
"release mode. Due to this, assertions must **not** contain expressions that "
"have side effects. Otherwise, the behavior of the script would vary "
"depending on whether the project is run in a debug build."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1616
msgid ""
"When running a project from the editor, the project will be paused if an "
"assertion error occurs."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:4
msgid "GDScript: An introduction to dynamic languages"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:9
msgid ""
"This tutorial aims to be a quick reference for how to use GDScript more "
"efficiently. It focuses on common cases specific to the language, but also "
"covers a lot of information on dynamically typed languages."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:13
msgid ""
"It's meant to be especially useful for programmers with little or no "
"previous experience with dynamically typed languages."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:17
msgid "Dynamic nature"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:20
msgid "Pros & cons of dynamic typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:22
msgid ""
"GDScript is a Dynamically Typed language. As such, its main advantages are "
"that:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:25
msgid "The language is simple and easy to learn."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:26
msgid "Most code can be written and changed quickly and without hassle."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:27
msgid "Less code written means less errors & mistakes to fix."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:28
msgid "Easier to read the code (less clutter)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:29
msgid "No compilation is required to test."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:30
msgid "Runtime is tiny."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:31
msgid "Duck-typing and polymorphism by nature."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:33
msgid "While the main disadvantages are:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:35
msgid "Less performance than statically typed languages."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:36
msgid "More difficult to refactor (symbols can't be traced)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:37
msgid ""
"Some errors that would typically be detected at compile time in statically "
"typed languages only appear while running the code (because expression "
"parsing is more strict)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:40
msgid ""
"Less flexibility for code-completion (some variable types are only known at "
"run-time)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:43
msgid ""
"This, translated to reality, means that Godot+GDScript are a combination "
"designed to create games quickly and efficiently. For games that are very "
"computationally intensive and can't benefit from the engine built-in tools "
"(such as the Vector types, Physics Engine, Math library, etc), the "
"possibility of using C++ is present too. This allows you to still create "
"most of the game in GDScript and add small bits of C++ in the areas that "
"need a performance boost."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:52
msgid "Variables & assignment"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:54
msgid ""
"All variables in a dynamically typed language are \"variant\"-like. This "
"means that their type is not fixed, and is only modified through assignment. "
"Example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:58
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:80
msgid "Static:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:66
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:94
msgid "Dynamic:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:75
msgid "As function arguments:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:77
msgid ""
"Functions are of dynamic nature too, which means they can be called with "
"different arguments, for example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:107
msgid "Pointers & referencing:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:109
msgid ""
"In static languages, such as C or C++ (and to some extent Java and C#), "
"there is a distinction between a variable and a pointer/reference to a "
"variable. The latter allows the object to be modified by other functions by "
"passing a reference to the original one."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:114
msgid ""
"In C# or Java, everything not a built-in type (int, float, sometimes String) "
"is always a pointer or a reference. References are also garbage-collected "
"automatically, which means they are erased when no longer used. Dynamically "
"typed languages tend to use this memory model, too. Some Examples:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:120
msgid "C++:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:136
msgid "Java:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:154
msgid "GDScript:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:166
msgid ""
"In GDScript, only base types (int, float, string and the vector types) are "
"passed by value to functions (value is copied). Everything else (instances, "
"arrays, dictionaries, etc) is passed as reference. Classes that inherit :ref:"
"`class_Reference` (the default if nothing is specified) will be freed when "
"not used, but manual memory management is allowed too if inheriting manually "
"from :ref:`class_Object`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:174
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:195
msgid "Arrays"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:176
msgid ""
"Arrays in dynamically typed languages can contain many different mixed "
"datatypes inside and are always dynamic (can be resized at any time). "
"Compare for example arrays in statically typed languages:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:203
msgid "And in GDScript:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:212
msgid ""
"In dynamically typed languages, arrays can also double as other datatypes, "
"such as lists:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:222
msgid "Or unordered sets:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:231
msgid "Dictionaries"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:233
msgid ""
"Dictionaries are a powerful tool in dynamically typed languages. Most "
"programmers that come from statically typed languages (such as C++ or C#) "
"ignore their existence and make their life unnecessarily more difficult. "
"This datatype is generally not present in such languages (or only in limited "
"form)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:239
msgid ""
"Dictionaries can map any value to any other value with complete disregard "
"for the datatype used as either key or value. Contrary to popular belief, "
"they are efficient because they can be implemented with hash tables. They "
"are, in fact, so efficient that some languages will go as far as "
"implementing arrays as dictionaries."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:245
msgid "Example of Dictionary:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:252
msgid ""
"Dictionaries are also dynamic, keys can be added or removed at any point at "
"little cost:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:261
msgid ""
"In most cases, two-dimensional arrays can often be implemented more easily "
"with dictionaries. Here's a simple battleship game example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:294
msgid ""
"Dictionaries can also be used as data markup or quick structures. While "
"GDScript's dictionaries resemble python dictionaries, it also supports Lua "
"style syntax and indexing, which makes it useful for writing initial states "
"and quick structs:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:319
msgid "For & while"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:321
msgid "Iterating in some statically typed languages can be quite complex:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:341
msgid "This is usually greatly simplified in dynamically typed languages:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:348
msgid ""
"Container datatypes (arrays and dictionaries) are iterable. Dictionaries "
"allow iterating the keys:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:356
msgid "Iterating with indices is also possible:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:363
msgid "The range() function can take 3 arguments:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:371
msgid "Some statically typed programming language examples:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:381
msgid "Translate to:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:394
msgid "And backwards looping is done through a negative counter:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:400
msgid "Becomes:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:408
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:384
msgid "While"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:410
msgid "while() loops are the same everywhere:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:421
msgid "Custom iterators"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:422
msgid ""
"You can create custom iterators in case the default ones don't quite meet "
"your needs by overriding the Variant class's ``_iter_init``, ``_iter_next``, "
"and ``_iter_get`` functions in your script. An example implementation of a "
"forward iterator follows:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:454
msgid "And it can be used like any other iterator:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:462
msgid ""
"Make sure to reset the state of the iterator in ``_iter_init``, otherwise "
"nested for-loops that use custom iterators will not work as expected."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:466
msgid "Duck typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:468
msgid ""
"One of the most difficult concepts to grasp when moving from a statically "
"typed language to a dynamic one is duck typing. Duck typing makes overall "
"code design much simpler and straightforward to write, but it's not obvious "
"how it works."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:473
msgid ""
"As an example, imagine a situation where a big rock is falling down a "
"tunnel, smashing everything on its way. The code for the rock, in a "
"statically typed language would be something like:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:484
msgid ""
"This way, everything that can be smashed by a rock would have to inherit "
"Smashable. If a character, enemy, piece of furniture, small rock were all "
"smashable, they would need to inherit from the class Smashable, possibly "
"requiring multiple inheritance. If multiple inheritance was undesired, then "
"they would have to inherit a common class like Entity. Yet, it would not be "
"very elegant to add a virtual method ``smash()`` to Entity only if a few of "
"them can be smashed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:492
msgid ""
"With dynamically typed languages, this is not a problem. Duck typing makes "
"sure you only have to define a ``smash()`` function where required and "
"that's it. No need to consider inheritance, base classes, etc."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:501
msgid ""
"And that's it. If the object that hit the big rock has a smash() method, it "
"will be called. No need for inheritance or polymorphism. Dynamically typed "
"languages only care about the instance having the desired method or member, "
"not what it inherits or the class type. The definition of Duck Typing should "
"make this clearer:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:507
msgid ""
"*\"When I see a bird that walks like a duck and swims like a duck and quacks "
"like a duck, I call that bird a duck\"*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:510
msgid "In this case, it translates to:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:512
msgid ""
"*\"If the object can be smashed, don't care what it is, just smash it.\"*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:514
msgid "Yes, we should call it Hulk typing instead."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:516
msgid ""
"It's possible that the object being hit doesn't have a smash() function. "
"Some dynamically typed languages simply ignore a method call when it doesn't "
"exist (like Objective C), but GDScript is stricter, so checking if the "
"function exists is desirable:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:527
msgid ""
"Then, simply define that method and anything the rock touches can be smashed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:4
msgid "GDScript exports"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:7
#, fuzzy
msgid "Introduction to exports"
msgstr "מבוא"

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:9
msgid ""
"In Godot, class members can be exported. This means their value gets saved "
"along with the resource (such as the :ref:`scene <class_PackedScene>`) "
"they're attached to. They will also be available for editing in the property "
"editor. Exporting is done by using the ``export`` keyword::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:18
msgid ""
"An exported variable must be initialized to a constant expression or have an "
"export hint in the form of an argument to the ``export`` keyword (see the "
"*Examples* section below)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:22
msgid ""
"One of the fundamental benefits of exporting member variables is to have "
"them visible and editable in the editor. This way, artists and game "
"designers can modify values that later influence how the program runs. For "
"this, a special export syntax is provided."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:29
msgid ""
"Exporting properties can also be done in other languages such as C#. The "
"syntax varies depending on the language."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:33
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:184
#: ../../docs/tutorials/physics/using_area_2d.rst:132
#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:190
#: ../../docs/development/compiling/compiling_with_mono.rst:123
msgid "Examples"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:136
msgid ""
"It must be noted that even if the script is not being run while in the "
"editor, the exported properties are still editable. This can be used in "
"conjunction with a :ref:`script in \"tool\" mode <doc_gdscript_tool_mode>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:141
msgid "Exporting bit flags"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:143
msgid ""
"Integers used as bit flags can store multiple ``true``/``false`` (boolean) "
"values in one property. By using the export hint ``int, FLAGS``, they can be "
"set from the editor::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:150
msgid ""
"Restricting the flags to a certain number of named flags is also possible. "
"The syntax is similar to the enumeration syntax::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:156
msgid ""
"In this example, ``Fire`` has value 1, ``Water`` has value 2, ``Earth`` has "
"value 4 and ``Wind`` corresponds to value 8. Usually, constants should be "
"defined accordingly (e.g. ``const ELEMENT_WIND = 8`` and so on)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:161
msgid ""
"Export hints are also provided for the physics and render layers defined in "
"the project settings::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:168
msgid ""
"Using bit flags requires some understanding of bitwise operations. If in "
"doubt, boolean variables should be exported instead."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:172
msgid "Exporting arrays"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:174
msgid ""
"Exporting arrays works, but with an important caveat: while regular arrays "
"are created local to every class instance, exported arrays are *shared* "
"between all instances. This means that editing them in one instance will "
"cause them to change in all other instances. Exported arrays can have "
"initializers, but they must be constant expressions."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:180
msgid ""
"If the exported array specifies a type which inherits from Resource, the "
"array values can be set in the inspector by dragging and dropping multiple "
"files from the FileSystem dock at once."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:220
msgid "Setting exported variables from a tool script"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:222
msgid ""
"When changing an exported variable's value from a script in :ref:"
"`doc_gdscript_tool_mode`, the value in the inspector won't be updated "
"automatically. To update it, call :ref:`property_list_changed_notify() "
"<class_Object_method_property_list_changed_notify>` after setting the "
"exported variable's value."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:229
msgid "Advanced exports"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:231
msgid ""
"Not every type of export can be provided on the level of the language itself "
"to avoid unnecessary design complexity. The following describes some more or "
"less common exporting features which can be implemented with a low-level API."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:235
msgid ""
"Before reading further, you should get familiar with the way properties are "
"handled and how they can be customized with :ref:`_set() "
"<class_Object_method__get_property_list>`, :ref:`_get() "
"<class_Object_method__get_property_list>`, and :ref:`_get_property_list() "
"<class_Object_method__get_property_list>` methods as described in :ref:"
"`doc_accessing_data_or_logic_from_object`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:242
msgid ""
"For binding properties using the above methods in C++, see :ref:"
"`doc_binding_properties_using_set_get_property_list`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:245
msgid ""
"The script must operate in the ``tool`` mode so the above methods can work "
"from within the editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:249
#, fuzzy
msgid "Adding script categories"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:251
msgid ""
"For better visual distinguishing of properties, a special script category "
"can be embedded into the inspector to act as a separator. ``Script "
"Variables`` is one example of a built-in category."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:268
msgid "``name`` is the name of a category to be added to the inspector;"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:270
msgid ""
"``PROPERTY_USAGE_CATEGORY`` indicates that the property should be treated as "
"a script category specifically, so the type ``TYPE_NIL`` can be ignored as "
"it won't be actually used for the scripting logic, yet it must be defined "
"anyway."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:275
msgid "Grouping properties"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:277
msgid "A list of properties with similar names can be grouped."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:291
msgid ""
"``name`` is the name of a group which is going to be displayed as "
"collapsible list of properties;"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:294
msgid ""
"every successive property added after the group property will be collapsed "
"and shortened as determined by the prefix defined via the ``hint_string`` "
"key. For instance, ``rotate_speed`` is going to be shortened to ``speed`` in "
"this case."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_exports.rst:298
msgid ""
"``PROPERTY_USAGE_GROUP`` indicates that the property should be treated as a "
"script group specifically, so the type ``TYPE_NIL`` can be ignored as it "
"won't be actually used for the scripting logic, yet it must be defined "
"anyway."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:4
msgid "GDScript style guide"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:6
msgid ""
"This style guide lists conventions to write elegant GDScript. The goal is to "
"encourage writing clean, readable code and promote consistency across "
"projects, discussions, and tutorials. Hopefully, this will also support the "
"development of auto-formatting tools."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:11
msgid ""
"Since GDScript is close to Python, this guide is inspired by Python's `PEP 8 "
"<https://www.python.org/dev/peps/pep-0008/>`__ programming style guide."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:15
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:16
msgid ""
"Style guides aren't meant as hard rulebooks. At times, you may not be able "
"to apply some of the guidelines below. When that happens, use your best "
"judgment, and ask fellow developers for insights."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:19
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:20
msgid ""
"In general, keeping your code consistent in your projects and within your "
"team is more important than following this guide to a tee."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:22
msgid ""
"Godot's built-in script editor uses a lot of these conventions by default. "
"Let it help you."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:25
msgid "Here is a complete class example based on these guidelines:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:94
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:31
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:50
msgid "Formatting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:97
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:53
msgid "Encoding and special characters"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:99
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:55
msgid ""
"Use line feed (**LF**) characters to break lines, not CRLF or CR. *(editor "
"default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:100
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:56
msgid "Use one line feed character at the end of each file. *(editor default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:101
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:57
msgid ""
"Use **UTF-8** encoding without a `byte order mark <https://en.wikipedia.org/"
"wiki/Byte_order_mark>`_. *(editor default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:102
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:58
msgid "Use **Tabs** instead of spaces for indentation. *(editor default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:105
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:61
msgid "Indentation"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:107
msgid "Each indent level should be one greater than the block containing it."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:109
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:129
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:148
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:201
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:225
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:272
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:302
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:327
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:347
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:373
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:697
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:65
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:84
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:111
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:162
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:194
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:226
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:256
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:280
msgid "**Good**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:116
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:137
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:171
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:212
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:231
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:282
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:309
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:334
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:354
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:383
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:705
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:73
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:92
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:121
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:171
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:201
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:234
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:264
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:286
msgid "**Bad**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:126
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:81
msgid ""
"Use 2 indent levels to distinguish continuation lines from regular code "
"blocks."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:145
msgid ""
"Exceptions to this rule are arrays, dictionaries, and enums. Use a single "
"indentation level to distinguish continuation lines:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:195
msgid "Trailing comma"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:197
msgid ""
"Use a trailing comma on the last line in arrays, dictionaries, and enums. "
"This results in easier refactoring and better diffs in version control as "
"the last line doesn't need to be modified when adding new elements."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:223
msgid ""
"Trailing commas are unnecessary in single-line lists, so don't add them in "
"this case."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:238
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:132
msgid "Blank lines"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:240
msgid "Surround functions and class definitions with two blank lines:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:255
msgid "Use one blank line inside functions to separate logical sections."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:258
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:149
msgid "Line length"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:260
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:151
msgid "Keep individual lines of code under 100 characters."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:262
msgid ""
"If you can, try to keep lines under 80 characters. This helps to read the "
"code on small displays and with two scripts opened side-by-side in an "
"external text editor. For example, when looking at a differential revision."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:267
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:158
msgid "One statement per line"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:269
msgid ""
"Never combine multiple statements on a single line. No, C programmers, not "
"even with a single line conditional statement."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:290
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:179
msgid "The only exception to that rule is the ternary operator:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:297
msgid "Avoid unnecessary parentheses"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:299
msgid ""
"Avoid parentheses in expressions and conditional statements. Unless "
"necessary for order of operations, they only reduce readability."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:317
msgid "Boolean operators"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:319
msgid ""
"Prefer the plain English versions of boolean operators, as they are the most "
"accessible:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:321
msgid "Use ``and`` instead of ``&&``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:322
msgid "Use ``or`` instead of ``||``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:324
msgid ""
"You may also use parentheses around boolean operators to clear any "
"ambiguity. This can make long expressions easier to read."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:342
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:189
msgid "Comment spacing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:344
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:191
msgid ""
"Regular comments should start with a space, but not code that you comment "
"out. This helps differentiate text comments from disabled code."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:363
msgid ""
"In the script editor, to toggle the selected code commented, press :kbd:"
"`Ctrl + K`. This feature adds a single # sign at the start of the selected "
"lines."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:368
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:221
msgid "Whitespace"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:370
msgid ""
"Always use one space around operators and after commas. Also, avoid extra "
"spaces in dictionary references and function calls."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:393
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:242
msgid "Don't use spaces to align expressions vertically:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:402
msgid "Quotes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:404
msgid ""
"Use double quotes unless single quotes make it possible to escape fewer "
"characters in a given string. See the examples below:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:424
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:197
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:293
msgid "Naming conventions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:426
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:295
msgid ""
"These naming conventions follow the Godot Engine style. Breaking these will "
"make your code clash with the built-in naming conventions, leading to "
"inconsistent code."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:431
msgid "File names"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:433
msgid ""
"Use snake_case for file names. For named classes, convert the PascalCase "
"class name to snake_case::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:446
msgid ""
"This is consistent with how C++ files are named in Godot's source code. This "
"also avoids case sensitivity issues that can crop up when exporting a "
"project from Windows to other platforms."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:451
msgid "Classes and nodes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:453
msgid "Use PascalCase for class and node names:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:459
msgid "Also use PascalCase when loading a class into a constant or a variable:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:466
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:300
msgid "Functions and variables"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:468
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:302
msgid "Use snake\\_case to name functions and variables:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:475
msgid ""
"Prepend a single underscore (\\_) to virtual methods functions the user must "
"override, private functions, and private variables:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:486
msgid "Use the past tense to name signals:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:494
#, fuzzy
msgid "Constants and enums"
msgstr "קבועים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:496
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:313
msgid ""
"Write constants with CONSTANT\\_CASE, that is to say in all caps with an "
"underscore (\\_) to separate words:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:503
msgid ""
"Use PascalCase for enum *names* and CONSTANT\\_CASE for their members, as "
"they are constants:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:517
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:321
msgid "Code order"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:519
msgid ""
"This first section focuses on code order. For formatting, see :ref:"
"`formatting`. For naming conventions, see :ref:`naming_conventions`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:522
msgid "We suggest to organize GDScript code this way:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:545
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:340
msgid ""
"We optimized the order to make it easy to read the code from top to bottom, "
"to help developers reading the code for the first time understand how it "
"works, and to avoid errors linked to the order of variable declarations."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:549
msgid "This code order follows four rules of thumb:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:551
msgid "Properties and signals come first, followed by methods."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:552
msgid "Public comes before private."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:553
msgid "Virtual callbacks come before the class's interface."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:554
msgid ""
"The object's construction and initialization functions, ``_init`` and "
"``_ready``, come before functions that modify the object at runtime."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:559
msgid "Class declaration"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:561
msgid ""
"If the code is meant to run in the editor, place the ``tool`` keyword on the "
"first line of the script."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:564
msgid ""
"Follow with the `class_name` if necessary. You can turn a GDScript file into "
"a global type in your project using this feature. For more information, see :"
"ref:`doc_gdscript`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:568
msgid "Then, add the `extends` keyword if the class extends a built-in type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:570
msgid ""
"Following that, you should have the class's optional docstring as comments. "
"You can use that to explain the role of your class to your teammates, how it "
"works, and how other developers should use it, for example."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:582
msgid "Signals and properties"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:584
msgid ""
"Write signal declarations, followed by properties, that is to say, member "
"variables, after the docstring."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:587
msgid ""
"Enums should come after signals, as you can use them as export hints for "
"other properties."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:590
msgid ""
"Then, write constants, exported variables, public, private, and onready "
"variables, in that order."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:615
msgid ""
"The GDScript compiler evaluates onready variables right before the "
"``_ready`` callback. You can use that to cache node dependencies, that is to "
"say, to get child nodes in the scene that your class relies on. This is what "
"the example above shows."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:621
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:268
#, fuzzy
msgid "Member variables"
msgstr "חברים"

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:623
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:270
msgid ""
"Don't declare member variables if they are only used locally in a method, as "
"it makes the code more difficult to follow. Instead, declare them as local "
"variables in the method's body."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:628
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:275
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:351
#, fuzzy
msgid "Local variables"
msgstr "נקודות ציון מקומיות"

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:630
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:277
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:353
msgid ""
"Declare local variables as close as possible to their first use. This makes "
"it easier to follow the code, without having to scroll too much to find "
"where the variable was declared."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:635
msgid "Methods and static functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:637
msgid "After the class's properties come the methods."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:639
msgid ""
"Start with the ``_init()`` callback method, that the engine will call upon "
"creating the object in memory. Follow with the ``_ready()`` callback, that "
"Godot calls when it adds a node to the scene tree."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:643
msgid ""
"These function should come first because they show how the object is "
"initialized."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:646
msgid ""
"Other built-in virtual callbacks, like ``_unhandled_input()`` and "
"``_physics_process``, should come next. These control the object's main loop "
"and interactions with the game engine."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:650
msgid ""
"The rest of the class's interface, public and private methods, come after "
"that, in that order."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:687
msgid "Static typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:689
msgid ""
"Since Godot 3.1, GDScript supports :ref:`optional static "
"typing<doc_gdscript_static_typing>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:692
msgid "Type hints"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:694
msgid ""
"Place the colon right after the variable's name, without a space, and let "
"the GDScript compiler infer the variable's type when possible."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:713
msgid ""
"When you let the compiler infer the type hint, write the colon and equal "
"signs together: ``:=``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:719
msgid ""
"Add a space on either sides of the return type arrow when defining functions."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:4
msgid "Static typing in GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:6
#: ../../docs/tutorials/physics/physics_introduction.rst:16
msgid "In this guide, you will learn:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:8
msgid "**How to use types in GDScript**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:9
msgid "That **static types can help you avoid bugs**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:11
msgid ""
"Where and how you use this new language feature is entirely up to you: you "
"can use it only in some sensitive GDScript files, use it everywhere, or "
"write code like you always did!"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:15
msgid ""
"Static types can be used on variables, constants, functions, parameters, and "
"return types."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:20
msgid "Typed GDScript is available since Godot 3.1."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:23
msgid "A brief look at static typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:25
msgid ""
"With typed GDScript, Godot can detect even more errors as you write code! It "
"gives you and your teammates more information as you're working, as the "
"arguments' types show up when you call a method."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:29
msgid ""
"Imagine you're programming an inventory system. You code an ``Item`` node, "
"then an ``Inventory``. To add items to the inventory, the people who work "
"with your code should always pass an ``Item`` to the ``Inventory.add`` "
"method. With types, you can enforce this:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:49
msgid ""
"Another significant advantage of typed GDScript is the new **warning "
"system**. From version 3.1, Godot gives you warnings about your code as you "
"write it: the engine identifies sections of your code that may lead to "
"issues at runtime, but lets you decide whether or not you want to leave the "
"code as it is. More on that in a moment."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:55
msgid ""
"Static types also give you better code completion options. Below, you can "
"see the difference between a dynamic and a static typed completion options "
"for a class called ``PlayerController``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:59
msgid ""
"You've probably stored a node in a variable before, and typed a dot to be "
"left with no autocomplete suggestions:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:65
msgid ""
"This is due to dynamic code. Godot cannot know what node or value type "
"you're passing to the function. If you write the type explicitly however, "
"you will get all public methods and variables from the node:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:72
msgid ""
"In the future, typed GDScript will also increase code performance: Just-In-"
"Time compilation and other compiler improvements are already on the roadmap!"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:76
msgid ""
"Overall, typed programming gives you a more structured experience. It helps "
"prevent errors and improves the self-documenting aspect of your scripts. "
"This is especially helpful when you're working in a team or on a long-term "
"project: studies have shown that developers spend most of their time reading "
"other people's code, or scripts they wrote in the past and forgot about. The "
"clearer and the more structured the code, the faster it is to understand, "
"the faster you can move forward."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:85
msgid "How to use static typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:87
msgid ""
"To define the type of a variable or a constant, write a colon after the "
"variable's name, followed by its type. E.g. ``var health: int``. This forces "
"the variable's type to always stay the same:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:96
msgid ""
"Godot will try to infer types if you write a colon, but you omit the type:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:105
msgid "Currently you can use three types of… types:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:107
msgid ":ref:`Built-in <doc_gdscript_builtin_types>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:108
msgid ""
"Core classes and nodes (``Object``, ``Node``, ``Area2D``, ``Camera2D``, etc.)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:110
msgid ""
"Your own, custom classes. Look at the new :ref:`class_name "
"<doc_scripting_continued_class_name>` feature to register types in the "
"editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:115
msgid ""
"You don't need to write type hints for constants, as Godot sets it "
"automatically from the assigned value. But you can still do so to make the "
"intent of your code clearer."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:118
msgid "Custom variable types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:120
msgid ""
"You can use any class, including your custom classes, as types. There are "
"two ways to use them in scripts. The first method is to preload the script "
"you want to use as a type in a constant:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:129
msgid ""
"The second method is to use the ``class_name`` keyword when you create. For "
"the example above, your Rifle.gd would look like this:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:137
msgid ""
"If you use ``class_name``, Godot registers the Rifle type globally in the "
"editor, and you can use it anywhere, without having to preload it into a "
"constant:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:146
msgid "Variable casting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:148
msgid ""
"Type casting is a key concept in typed languages. Casting is the conversion "
"of a value from one type to another."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:151
msgid ""
"Imagine an Enemy in your game, that ``extends Area2D``. You want it to "
"collide with the Player, a ``KinematicBody2D`` with a script called "
"``PlayerController`` attached to it. You use the ``on_body_entered`` signal "
"to detect the collision. With typed code, the body you detect is going to be "
"a generic ``PhysicsBody2D``, and not your ``PlayerController`` on the "
"``_on_body_entered`` callback."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:158
msgid ""
"You can check if this ``PhysicsBody2D`` is your Player with the ``as`` "
"casting keyword, and using the colon ``:`` again to force the variable to "
"use this type. This forces the variable to stick to the ``PlayerController`` "
"type:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:172
msgid ""
"As we're dealing with a custom type, if the ``body`` doesn't extend "
"``PlayerController``, the ``player``\\ variable will be set to ``null``. We "
"can use this to check if the body is the player or not. We will also get "
"full autocompletion on the player variable thanks to that cast."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:179
msgid ""
"If you try to cast with a built-in type and it fails, Godot will throw an "
"error."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:182
msgid "Safe lines"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:184
msgid ""
"You can also use casting to ensure safe lines. Safe lines are a new tool in "
"Godot 3.1 to tell you when ambiguous lines of code are type-safe. As you can "
"mix and match typed and dynamic code, at times, Godot doesn't have enough "
"information to know if an instruction will trigger an error or not at "
"runtime."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:190
msgid ""
"This happens when you get a child node. Let's take a timer for example: with "
"dynamic code, you can get the node with ``$Timer``. GDScript supports `duck-"
"typing <https://stackoverflow.com/a/4205163/8125343>`__, so even if your "
"timer is of type ``Timer``, it is also a ``Node`` and an ``Object``, two "
"classes it extends. With dynamic GDScript, you also don't care about the "
"node's type as long as it has the methods you need to call."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:198
msgid ""
"You can use casting to tell Godot the type you expect when you get a node: "
"``($Timer as Timer)``, ``($Player as KinematicBody2D)``, etc. Godot will "
"ensure the type works and if so, the line number will turn green at the left "
"of the script editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:206
msgid "Unsafe line (line 7) vs Safe Lines (line 6 and 8)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:210
msgid ""
"You can turn off safe lines or change their color in the editor settings."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:213
msgid "Define the return type of a function with the arrow ->"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:215
msgid ""
"To define the return type of a function, write a dash and a right angle "
"bracket ``->`` after its declaration, followed by the return type:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:223
msgid ""
"The type ``void`` means the function does not return anything. You can use "
"any type, as with variables:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:232
msgid "You can also use your own nodes as return types:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:248
msgid "Typed or dynamic: stick to one style"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:250
msgid ""
"Typed GDScript and dynamic GDScript can coexist in the same project. But I "
"recommended to stick to either style for consistency in your codebase, and "
"for your peers. It's easier for everyone to work together if you follow the "
"same guidelines, and faster to read and understand other people's code."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:256
msgid ""
"Typed code takes a little more writing, but you get the benefits we "
"discussed above. Here's an example of the same, empty script, in a dynamic "
"style:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:272
msgid "And with static typing:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:286
msgid ""
"As you can see, you can also use types with the engine's virtual methods. "
"Signal callbacks, like any methods, can also use types. Here's a "
"``body_entered`` signal in a dynamic style:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:295
msgid "And the same callback, with type hints:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:302
msgid ""
"You're free to replace, e.g. the ``CollisionObject2D``, with your own type, "
"to cast parameters automatically:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:313
msgid ""
"The ``bullet`` variable could hold any ``CollisionObject2D`` here, but we "
"make sure it is our ``Bullet``, a node we created for our project. If it's "
"anything else, like an ``Area2D``, or any node that doesn't extend "
"``Bullet``, the ``bullet`` variable will be ``null``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:319
msgid "Warning system"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:323
msgid ""
"Documentation about the GDScript warning system has been moved to :ref:"
"`doc_gdscript_warning_system`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:327
msgid "Cases where you can't specify types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:329
msgid ""
"To wrap up this introduction, let's cover a few cases where you can't use "
"type hints. All the examples below **will trigger errors**."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:332
msgid "You can't use Enums as types:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:339
msgid ""
"You can't specify the type of individual members in an array. This will give "
"you an error:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:346
msgid ""
"You can't force the assignment of types in a ``for`` loop, as each element "
"the ``for`` keyword loops over already has a different type. So you "
"**cannot** write:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:356
msgid "Two scripts can't depend on each other in a cyclic fashion:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:379
#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:132
#: ../../docs/tutorials/2d/2d_movement.rst:355
#: ../../docs/tutorials/2d/2d_sprite_animation.rst:213
msgid "Summary"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/static_typing.rst:381
msgid ""
"Typed GDScript is a powerful tool. Available as of version 3.1 of Godot, it "
"helps you write more structured code, avoid common errors, and create "
"scalable systems. In the future, static types will also bring you a nice "
"performance boost thanks to upcoming compiler optimizations."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:4
msgid "GDScript warning system"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:6
msgid ""
"The GDScript warning system complements :ref:`static typing "
"<doc_gdscript_static_typing>` (but it can work without static typing too). "
"It's here to help you avoid mistakes that are hard to spot during "
"development, and that may lead to runtime errors."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:11
msgid ""
"You can configure warnings in the Project Settings under the section called "
"**Gdscript**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:17
#, fuzzy
msgid "Warning system project settings"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:19
msgid ""
"You can find a list of warnings for the active GDScript file in the script "
"editor's status bar. The example below has 3 warnings:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:25
msgid "Warning system example"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:27
msgid ""
"To ignore specific warnings in one file, insert a special comment of the "
"form ``# warning-ignore:warning-id``, or click on the ignore link to the "
"right of the warning's description. Godot will add a comment above the "
"corresponding line and the code won't trigger the corresponding warning "
"anymore:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:36
msgid "Warning system ignore example"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:38
msgid ""
"You can also choose to ignore not just one but all warnings of a certain "
"type in this file with ``# warning-ignore-all:warning-id``. To ignore all "
"warnings of all types in a file add the comment ``# warnings-disable`` to it."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:42
msgid ""
"Warnings won't prevent the game from running, but you can turn them into "
"errors if you'd like. This way your game won't compile unless you fix all "
"warnings. Head to the ``GDScript`` section of the Project Settings to turn "
"on this option. Here's the same file as the previous example with warnings "
"as errors turned on:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/warning_system.rst:51
msgid "Warnings as errors"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:4
msgid "GDScript format strings"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:6
msgid ""
"GDScript offers a feature called *format strings*, which allows reusing text "
"templates to succinctly create different but similar strings."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:9
msgid ""
"Format strings are just like normal strings, except they contain certain "
"placeholder character-sequences. These placeholders can then easily be "
"replaced by parameters handed to the format string."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:13
msgid ""
"As an example, with ``%s`` as a placeholder, the format string ``\"Hello %s, "
"how are you?`` can easily be changed to ``\"Hello World, how are you?\"``. "
"Notice the placeholder is in the middle of the string; modifying it without "
"format strings could be cumbersome."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:20
msgid "Usage in GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:22
msgid "Examine this concrete GDScript example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:35
msgid ""
"Placeholders always start with a ``%``, but the next character or "
"characters, the *format specifier*, determines how the given value is "
"converted to a string."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:39
msgid ""
"The ``%s`` seen in the example above is the simplest placeholder and works "
"for most use cases: it converts the value by the same method by which an "
"implicit String conversion or ``str()`` would convert it. Strings remain "
"unchanged, Booleans turn into either ``\"True\"`` or ``\"False\"``, an "
"integral or real number becomes a decimal, other types usually return their "
"data in a human-readable string."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:46
msgid ""
"There is also another way to format text in GDScript, namely the ``String."
"format()`` method. It replaces all occurrences of a key in the string with "
"the corresponding value. The method can handle arrays or dictionaries for "
"the key/value pairs."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:50
msgid ""
"Arrays can be used as key, index, or mixed style (see below examples). Order "
"only matters when the index or mixed style of Array is used."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:53
msgid "A quick example in GDScript:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:66
msgid ""
"There are other `format specifiers`_, but they are only applicable when "
"using the ``%`` operator."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:71
msgid "Multiple placeholders"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:73
msgid ""
"Format strings may contain multiple placeholders. In such a case, the values "
"are handed in the form of an array, one value per placeholder (unless using "
"a format specifier with ``*``, see `dynamic padding`_):"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:85
msgid ""
"Note the values are inserted in order. Remember all placeholders must be "
"replaced at once, so there must be an appropriate number of values."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:90
msgid "Format specifiers"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:92
msgid ""
"There are format specifiers other than ``s`` that can be used in "
"placeholders. They consist of one or more characters. Some of them work by "
"themselves like ``s``, some appear before other characters, some only work "
"with certain values or characters."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:99
msgid "Placeholder types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:101
msgid ""
"One and only one of these must always appear as the last character in a "
"format specifier. Apart from ``s``, these require certain types of "
"parameters."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:105
msgid "``s``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:105
msgid ""
"**Simple** conversion to String by the same method as implicit String "
"conversion."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:108
msgid "``c``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:108
msgid ""
"A single **Unicode character**. Expects an unsigned 8-bit integer (0-255) "
"for a code point or a single-character string."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:111
msgid "``d``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:111
msgid ""
"A **decimal integral** number. Expects an integral or real number (will be "
"floored)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:114
msgid "``o``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:114
msgid ""
"An **octal integral** number. Expects an integral or real number (will be "
"floored)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:117
msgid "``x``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:117
msgid ""
"A **hexadecimal integral** number with **lower-case** letters. Expects an "
"integral or real number (will be floored)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:120
msgid "``X``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:120
msgid ""
"A **hexadecimal integral** number with **upper-case** letters. Expects an "
"integral or real number (will be floored)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:123
msgid "``f``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:123
msgid "A **decimal real** number. Expects an integral or real number."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:128
msgid "Placeholder modifiers"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:130
msgid ""
"These characters appear before the above. Some of them work only under "
"certain conditions."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:134
msgid "In number specifiers, **show + sign** if positive."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:136
#: ../../docs/tutorials/misc/binary_serialization_api.rst:97
#: ../../docs/tutorials/misc/binary_serialization_api.rst:106
#: ../../docs/tutorials/misc/binary_serialization_api.rst:124
#: ../../docs/tutorials/misc/binary_serialization_api.rst:315
#: ../../docs/tutorials/misc/binary_serialization_api.rst:335
#: ../../docs/tutorials/misc/binary_serialization_api.rst:337
#: ../../docs/tutorials/misc/binary_serialization_api.rst:345
#: ../../docs/tutorials/misc/binary_serialization_api.rst:364
#: ../../docs/tutorials/misc/binary_serialization_api.rst:376
#: ../../docs/tutorials/misc/binary_serialization_api.rst:388
#: ../../docs/tutorials/misc/binary_serialization_api.rst:401
#: ../../docs/tutorials/misc/binary_serialization_api.rst:403
#: ../../docs/tutorials/misc/binary_serialization_api.rst:412
#: ../../docs/tutorials/misc/binary_serialization_api.rst:414
#: ../../docs/tutorials/misc/binary_serialization_api.rst:423
#: ../../docs/tutorials/misc/binary_serialization_api.rst:431
#: ../../docs/tutorials/misc/binary_serialization_api.rst:444
#: ../../docs/tutorials/misc/binary_serialization_api.rst:457
#: ../../docs/tutorials/misc/binary_serialization_api.rst:472
msgid "Integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:136
msgid ""
"Set **padding**. Padded with spaces or with zeroes if integer starts with "
"``0`` in an integer placeholder. When used after ``.``, see ``.``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:140
msgid "``.``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:140
msgid ""
"Before ``f``, set **precision** to 0 decimal places. Can be followed up with "
"numbers to change. Padded with zeroes."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:143
msgid "**Pad to the right** rather than the left."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:145
msgid "``*``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:145
msgid ""
"**Dynamic padding**, expect additional integral parameter to set padding or "
"precision after ``.``, see `dynamic padding`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:151
msgid "Padding"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:153
msgid ""
"The ``.`` (*dot*), ``*`` (*asterisk*), ``-`` (*minus sign*) and digit (``0``-"
"``9``) characters are used for padding. This allows printing several values "
"aligned vertically as if in a column, provided a fixed-width font is used."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:158
msgid "To pad a string to a minimum length, add an integer to the specifier:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:166
msgid ""
"If the integer starts with ``0``, integral values are padded with zeroes "
"instead of white space:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:174
msgid ""
"Precision can be specified for real numbers by adding a ``.`` (*dot*) with "
"an integer following it. With no integer after ``.``, a precision of 0 is "
"used, rounding to integral value. The integer to use for padding must appear "
"before the dot."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:186
msgid ""
"The ``-`` character will cause padding to the right rather than the left, "
"useful for right text alignment:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:197
msgid "Dynamic padding"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:199
msgid ""
"By using the ``*`` (*asterisk*) character, the padding or precision can be "
"set without modifying the format string. It is used in place of an integer "
"in the format specifier. The values for padding and precision are then "
"passed when formatting:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:212
msgid ""
"It is still possible to pad with zeroes in integer placeholders by adding "
"``0`` before ``*``:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:222
msgid "Escape sequence"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:224
msgid ""
"To insert a literal ``%`` character into a format string, it must be escaped "
"to avoid reading it as a placeholder. This is done by doubling the character:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:235
msgid "Format method examples"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:237
msgid ""
"The following are some examples of how to use the various invocations of the "
"``String.format``  method."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
msgid "**Style**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:264
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:277
msgid "**Example**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:264
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:277
msgid "**Result**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:246
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:288
msgid "Dictionary"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
msgid "key"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
msgid ""
"``\"Hi, {name} v{version}!\".format({\"name\":\"Godette\", \"version\":"
"\"3.0\"})``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:246
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:252
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:254
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:256
msgid "Hi, Godette v3.0!"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:246
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:252
msgid "index"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:246
msgid "``\"Hi, {0} v{1}!\".format({\"0\":\"Godette\", \"1\":\"3.0\"})``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:254
msgid "mix"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
msgid ""
"``\"Hi, {0} v{version}!\".format({\"0\":\"Godette\", \"version\":\"3.0\"})``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:252
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:254
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:256
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:267
msgid "Array"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
msgid ""
"``\"Hi, {name} v{version}!\".format([[\"version\",\"3.0\"], [\"name\","
"\"Godette\"]])``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:252
msgid "``\"Hi, {0} v{1}!\".format([\"Godette\",\"3.0\"])``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:254
msgid "``\"Hi, {name} v{0}!\".format([3.0, [\"name\",\"Godette\"]])``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:256
msgid "no index"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:256
msgid "``\"Hi, {} v{}!\".format([\"Godette\", 3.0], \"{}\")``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:259
msgid ""
"Placeholders can also be customized when using ``String.format``, here's "
"some examples of that functionality."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
msgid "Infix (default)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
msgid "``\"Hi, {0} v{1}\".format([\"Godette\", \"3.0\"], \"{_}\")``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:270
msgid "Hi, Godette v3.0"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
msgid "Postfix"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
msgid "``\"Hi, 0% v1%\".format([\"Godette\", \"3.0\"], \"_%\")``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:270
msgid "Prefix"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:270
msgid "``\"Hi, %0 v%1\".format([\"Godette\", \"3.0\"], \"%_\")``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:273
msgid ""
"Combining both the ``String.format`` method and the ``%`` operator could be "
"useful, as ``String.format`` does not have a way to manipulate the "
"representation of numbers."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:279
msgid ""
"``\"Hi, {0} v{version}\".format({0:\"Godette\", \"version\":\"%0.2f\" % "
"3.114})``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:279
msgid "Hi, Godette v3.11"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:4
msgid "What is Visual Scripting"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:6
msgid ""
"Visual Scripting is a tool designed to make the entry barrier to programming "
"much lower. As code is more visual, it needs less abstract thinking to be "
"understood. Any artist, animator, game designer, etc. can look at it and "
"quickly grasp the flow of logic."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:11
msgid ""
"The reason it does not make existing programming obsolete is, simply, that "
"it does not scale as well. It takes considerably more time to create code "
"with it, and it's often more difficult to modify than just writing a few "
"characters."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:15
msgid ""
"With the misunderstanding cleared up, the question that remains is what are "
"the practical uses for Visual Scripting."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:18
msgid "The most common use cases are as follows:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:20
msgid ""
"Game development beginners who want to learn an engine but have no "
"programming experience yet."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:21
msgid ""
"Artists and Game Designers who have no experience in programming and want to "
"create quick prototypes or simple games."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:22
msgid ""
"Programmers working in a team that want to make part of the game logic "
"available to Artists or Game Designers in order to offload some of their "
"work."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/what_is_visual_scripting.rst:24
msgid ""
"These scenarios are far more common than one might think, so this is why "
"Godot has added this feature."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:4
msgid "Getting started with Visual Scripting"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:6
msgid ""
"As with everything in Godot, we prioritize a good experience over copying or "
"integrating third party solutions which might not fit nicely in the current "
"workflow. This led us to write our own version of how we believe this "
"feature would work best with the engine."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:10
msgid ""
"In Godot, a Visual Script fits smoothly together with regular scripts in the "
"Editor tab"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:15
msgid ""
"In fact, Visual Scripting integrates so well to Godot that it's hard to "
"believe it was added only in version 3.0. This is because, when editing, the "
"rest of Godot panels and docks act like a palette from where you can drag "
"and drop all sorts of information to the script canvas:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:23
#, fuzzy
msgid "Creating a script"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:25
msgid ""
"Creating scripts works the same as with other scripting languages: Select "
"any node in the scene and push the \"New Script\" button at the top right "
"corner of the Scene Tree dock:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:31
msgid ""
"Once it opens, the script type \"Visual Script\" must be selected from the "
"drop down list. The script extension must be \".vs\" (for Visual Script!)."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:37
msgid ""
"Finally, the Script Editor will open, allowing you to start editing the "
"visual script:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:43
msgid "Adding a function"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:45
msgid ""
"Unlike other visual scripting implementations, Visual Scripting in Godot is "
"heavily based on functions. This happens because it uses the same interface "
"to communicate with the engine as other scripting engines. In Godot, the "
"scripting interface is universal and all implementations conform to it."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:49
msgid "A function is an individual canvas with nodes connected."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:51
msgid ""
"A single script can contain many functions, each of which will have a canvas "
"of its own, allowing for more organization."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:53
msgid "There are three main ways to add functions in a script:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:56
msgid "Overriding a virtual function"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:58
msgid ""
"Most types of nodes and other types of objects in Godot contain virtual "
"functions. These are functions that will be called (run your code) when "
"something happens and can be looked up in the reference. Virtual functions "
"are listed when pressing the \"Override\" icon in the member panel:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:65
msgid ""
"In the following example, a function will be executed when the node is "
"loaded and added to the running scene. For this, the _ready() virtual method "
"will be overridden:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:71
msgid "Finally, a canvas appears for this function, showing the override:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:76
msgid ""
"As some functions expect you to return a value, they will also add a return "
"node where such value is supposed to be provided:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:83
msgid "Connecting a signal to a function"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:85
msgid ""
"Nodes in a tree emit signals when something happens. Godot uses signals for "
"all sorts of things. A typical example would be a button that emits a "
"\"pressed\" signal when actually pressed."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:88
msgid ""
"For this, a node must be selected and the Node tab opened. This will allow "
"inspecting the signals. Once they are displayed, connect the \"pressed\" "
"signal:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:94
msgid ""
"This will open the connection dialog. In this dialog, you must select the "
"node where the signal will be connected to, and the function that will "
"receive the signal:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:100
msgid ""
"If this is done right, a new function will be created in our script and a "
"signal will automatically be connected to it:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:107
msgid "Creating a function manually"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:109
msgid ""
"The last way to create functions is to do it manually. In general, this is "
"not as common unless you really need it. Custom functions work when another "
"(or the same) script calls them manually. The main use cases for this are "
"breaking a larger function up into several manageable chunks and reusing "
"your visual code."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:113
msgid ""
"To create a function manually, push the big \"Plus\" button, and a new "
"function will be added with a default name:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:119
msgid ""
"This will add a new function, which can be renamed by simply double clicking "
"its name:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:125
msgid ""
"To edit the \"arguments\" this function can get (the values you pass to it "
"when you call this function), simply click the Function node and check the "
"inspector:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/getting_started.rst:131
msgid "More on that will be explained later in this document."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:4
msgid "Nodes and terminology"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:6
msgid ""
"Before continuing, it must be noted that the *Node* terminology needs to be "
"used with care. When referring to *Visual Script Nodes* (or generally "
"*Nodes*) this text will refer to the little boxes you connect with lines, "
"which are part of a graph. When referring to *Scene Nodes*, it is implied "
"that the elements that make up a Scene are being referred, which are part of "
"a tree. Their naming is similar but their function is different. When "
"referring to *Node* here, it will be implied that a *Visual Script Node* is "
"referred to unless indicated otherwise."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:15
msgid "Node properties"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:17
msgid ""
"Like in most visual scripting implementations, each node has editable "
"properties. In Godot, though, we try to avoid bloating the nodes with "
"editable controls for the sake of readability."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:20
msgid ""
"Nodes still display the required information as text, but editing is done "
"via the *Inspector*. To edit them, select any node and edit its properties "
"in the *Inspector*."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:25
msgid "Ports and connections"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:27
msgid ""
"Programming in Godot Visual Scripting is done via *Nodes* and *Port "
"Connections* inside each function."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:31
msgid "Ports"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:33
msgid ""
"Nodes in Godot Visual Scripting have *Ports*. These are endpoints that "
"appear to the left and right of nodes and which can be used to make "
"*Connections*: There are two types of *Ports*: *Sequence* and *Data*."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:40
msgid ""
"*Sequence Ports* indicate the order in which operations are executed. "
"Typically when a *Node* is done processing, it will go to the next node from "
"one of the ports at the right. If nothing is connected, the function may "
"end, or another output *Sequence Port* might be tried (this depends on the "
"node). Thanks to this, you can follow the logic flow within a function by "
"following the white lines. Not every *Node* has *Sequence Ports*. In fact, "
"most do not."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:46
msgid ""
"*Data Ports* ports contain typed values. Types can be any regular Godot "
"types, such as a boolean, an integer, a string, a Vector3, an array, any "
"Object or Scene Node, etc. A *Data Port* on the right side of a node is "
"considered an output, while, a port on the left side is an input. Connecting "
"them allows information to flow to the next node."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:51
msgid ""
"Not all *Data Port* types are compatible and will allow connections, though. "
"Pay special attention to colors and icons, as each type has a different "
"representation:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:58
#: ../../docs/development/file_formats/tscn.rst:27
msgid "Connections"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:60
msgid ""
"Connecting is a relatively simple process. Drag an *Output Port* towards an "
"*Input Port*."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:65
msgid ""
"Disconnecting takes a bit more practice. Disconnecting in *Data Ports* "
"happens by dragging the *Input* away, while for *Sequence Ports*, this "
"happens by dragging the *Output* away."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:71
msgid ""
"This may seem strange at first, but it happens because *Data Ports* are 1:N "
"(A single output port can connect to many inputs), while *Sequence Ports* "
"are N:1 (Many sequence outputs can be connected to a single input)."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:75
msgid ""
"Connecting to empty space (drag to connect but unpress over empty space) is "
"also context sensitive, it will supply a list of most common operations. For "
"sequences, it will be conditional nodes:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:81
msgid "While, for data, a contextual set/get/call menu will open:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:87
msgid "Adding nodes"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:89
msgid ""
"Finally! We got to the fun part! But, before explaining in more detail what "
"each type of node does, let's take a short look at how nodes are most "
"commonly added and dealt with."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:94
msgid "Accessing scene nodes"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:96
msgid ""
"One of the most common tasks is accessing Scene Tree Nodes (again, not to "
"mistake with *Visual Script Nodes*). Dragging from the Scene Tree and "
"dropping into the canvas will ask you to *call a method* (sometimes referred "
"to as *member function*) on this node."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:102
msgid ""
"While accessing properties is desired in most cases (more on that below), "
"sometimes *calling methods* can be useful too. Methods execute specific "
"actions on objects. In the above case, the mouse pointer can be warped to a "
"position in local coordinates to the control. Another common use case is "
"queueing a node for deletion, which is done with the *queue_free* method."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:109
msgid ""
"Care must be taken that this only works if the scene being edited contains "
"your *Visual Script* in one of the nodes! Otherwise, a warning will be shown."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:113
msgid "Accessing scene node properties"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:115
msgid ""
"This is the most common way to edit *Scene Nodes* in Visual Scripting. "
"Select a *Scene Node* from the *Scene Tree*, go to the Inspector, find *the "
"Name* of the property you want to edit (hint, *not* the value!) and drag it "
"to the canvas:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:120
msgid ""
"The result is that this value can be changed from your script by writing to "
"a *Data Port*."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:122
msgid ""
"If instead reading this value is desired, drag the node again but hold :kbd:"
"`Ctrl` (or :kbd:`Cmd` on macOS). This will create a getter:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:127
msgid "In this case, the value can be read from a *Data Port*."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:133
msgid ""
"Variables are memory containers local to the script which can hold a value. "
"This value can be read from any of the functions of the script or from other "
"scripts via the method described in the previous step."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:135
msgid ""
"To add a Variable, push the \"+\" button on the *Variables* section of the "
"Members panel. Double-click the new variable to rename it:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:140
msgid "Right-clicking the variable allows you to configure its properties:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:147
msgid ""
"As it can be seen above, the type and initial value of the variable can be "
"changed, as well as some property hints. Ticking the \"Export\" option makes "
"the variable visible in the Inspector when selecting the node. This also "
"makes it available to other scripts via the method described in the previous "
"step."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:153
msgid ""
"To use the variable in the script, simply drag it to the canvas to create a "
"getter:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:158
msgid "Likewise, hold :kbd:`Ctrl` (or :kbd:`Cmd` on macOS) to drop a setter:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:166
msgid ""
"It is also possible to create your own signals in a script and use them. For "
"this, do the same steps you did for variables in the previous step, except "
"for *Signals*:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:171
msgid ""
"A signal can also be edited via the right-click menu to customize its "
"arguments:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:176
msgid ""
"The signal you have created will appear in the Inspector, along with the "
"built-in node signals. This allows you to connect it from another script "
"from another *Scene Node*:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:181
msgid "Finally, to emit the signal, simply drag it to the canvas:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:186
msgid ""
"Remember that emitting a signal is a sequenced operation, so it must come "
"from a Sequence port."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:190
msgid "Adding more nodes"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:192
msgid ""
"Now that the basics are covered, let's discuss the large amount of utility "
"nodes available for your canvas! Below the member panel, exists the list of "
"all available node types:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:198
msgid ""
"Pressing :kbd:`Ctrl + F` (or :kbd:`Cmd + F` on macOS) allows you to search "
"the list."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:200
msgid ""
"Any of them can be dragged to the scene. Unlike nodes (e.g. dragging a "
"property from the Inspector sets the context to the node being edited "
"automatically), these are added without any \"contextual\" information, so "
"this has to be done manually."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:206
msgid ""
"Remember that you can check the class reference for what each node does, as "
"they are documented there. That mentioned, a brief overview of node types "
"follows:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:213
msgid ""
"Constant nodes are nodes that provide values that, while not changing over "
"time, can be useful as reference values. Most of the time they are integer "
"or float."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:219
msgid ""
"The first one is \"Constant\", which allows you to select any value of any "
"type as constant, from an integer (42) to a String (\"Hello!\"). In general, "
"this node is not used that often because of default input values in *Data "
"Ports*, but it's good to know it exists."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:221
msgid ""
"The second is the GlobalConstant node, which contains a long list of "
"constants for global types in Godot. In there you can find some useful "
"constants to refer to key names, joystick or mouse buttons, etc."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:224
msgid ""
"The third one is MathConstant, which provides typical mathematical "
"constants, such as PI, E, etc."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:230
msgid ""
"Data nodes deal with all sorts of access to information. Any information in "
"Godot is accessed via these nodes, so they are some of the most important "
"ones to use and pretty diverse."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:236
msgid ""
"There are many types of nodes of interest here, so a short attempt to "
"describe them will follow:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:240
msgid "Action"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:242
msgid ""
"Action nodes are vital when dealing with input from a device. You can read "
"more about actions in the (@TODO ACTION TUTE LINK). In the following example "
"below, the control is moved to the right when the \"move_right\" action is "
"pressed."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:249
msgid "Engine Singleton"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:251
msgid ""
"Engine singletons are global interfaces (meaning they can be accessed "
"without a reference; unlike Scene Nodes, they are always available). They "
"have several purposes, but in general, they are useful for low-level access "
"or OS-related access."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:257
msgid ""
"Remember that dragging a connection to empty space will help you call "
"functions or set/get properties on these:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:263
msgid "Local Variables"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:265
msgid ""
"These are nodes you can use as temporary storage for your graphs. Make sure "
"they all have the same name and type when using them and they will reference "
"the same piece of memory."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:270
msgid ""
"As it can be seen above, there are two nodes available: A simple getter, and "
"a sequenced getter (setting requires a sequence port)."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:274
msgid "Scene Node"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:276
msgid ""
"This is just a reference to a node in the tree, but it's easier to use this "
"node by dragging the actual node from the scene tree to the canvas (this "
"will create it and configure it)."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:281
msgid "Self"
msgstr "עצמי"

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:283
msgid ""
"In some rare occasions, it may be desired to pass this Scene Node as "
"argument. It can be used to call functions and set/get properties, or drag "
"nodes (or event the node itself that has the script) from the Scene Tree to "
"the canvas for this."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:290
msgid ""
"This node is similar to the Singleton node because it references the "
"SceneTree, which contains the active scene. SceneTree, however, only works "
"when the node is sitting in the scene and active, otherwise accessing it "
"will return an error."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:294
msgid ""
"SceneTree allows for many low-level things, like setting stretch options, "
"calling groups, make timers, or even load another scene. It's a good class "
"to get familiar with."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:299
msgid "Preload"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:301
msgid ""
"This does the same function as preload() in GDScript. It maintains this "
"resource loaded and ready to use. Rather than instancing the node, it's "
"simpler to drag the desired resource from the filesystem dock to the canvas."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:306
msgid "Resource Path"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:308
msgid ""
"This node is a simple helper to get a string with a path to a resource you "
"can pick. It's useful in functions that load things from disk."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:313
msgid "Comment"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:315
msgid ""
"A Comment node works as a node you can resize to put around other nodes. It "
"will not try to get focus or be brought to top when selecting it. It can "
"also be used to write text on it."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:322
msgid "Flow Control"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:324
msgid ""
"Flow control nodes allow the execution to take different branches, usually "
"depending on a given condition."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:331
msgid "Condition"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:333
msgid ""
"This is a simple node that checks a bool port. If ``true``, it will go via "
"the \"true\" sequence port. If ``false``, the second. After going for either "
"of them, it goes via the \"done\" port. Leaving sequence ports disconnected "
"is fine if not all of them are used."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:339
msgid "Iterator"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:341
msgid ""
"Some data types in Godot (ie, arrays, dictionaries) are iterable. This means "
"that a bit of code can run for each element that it has."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:344
msgid ""
"The Iterator node goes through all elements and, for each of them, it goes "
"via the \"each\" sequence port, making the element available in the \"elem\" "
"data port."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:347
msgid "When done, it goes via the \"exit\" sequence port."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:351
msgid "Return"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:353
msgid ""
"Some functions can return values. In general for virtual ones, Godot will "
"add the Return node for you. A return node forces the function to end."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:358
msgid "Sequence"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:360
msgid ""
"This node is useful mostly for organizing your graph. It calls its sequence "
"ports in order."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:364
msgid "TypeCast"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:366
msgid ""
"This is a useful and commonly used node. You can use it to cast arguments or "
"other objects to the type you desire. Afterwards, you can even drag the "
"object output to get full completion."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:372
msgid ""
"It is also possible to cast to a script, which will allow complete script "
"properties and functions:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:378
msgid "Switch"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:380
msgid ""
"The Switch node is similar to the Condition node, but it matches many values "
"at the same time."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:386
msgid ""
"This is a more primitive form of iteration. \"repeat\" sequence output will "
"be called as long as the condition in the \"cond\" data port is met."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:393
msgid ""
"Functions are simple helpers, most of the time deterministic. They take some "
"arguments as input and return an output. They are almost never sequenced."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:398
msgid "Built-In"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:400
msgid ""
"There is a list of built-in helpers. The list is almost identical to the one "
"from :ref:`GDScript<class_@GDScript>`. Most of them are mathematical "
"functions, but others can be useful helpers. Make sure to take a look at the "
"list at some point."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:404
msgid "By Type"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:406
msgid ""
"Those are the methods available to basic types. For example, if you want a "
"dot-product, you can search for \"dot\" instead of the Vector3 category. In "
"most cases just search the list of nodes, it should be faster."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:411
msgid "Call"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:413
msgid ""
"This is the generic calling node. It is rarely used directly but by dragging "
"to empty space on an already configured node."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:417
msgid "Constructors"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:419
msgid ""
"These are all the functions needed to create Godot basic datatypes. For "
"example, If you need to create a Vector3 out of 3 floats, a constructor must "
"be used."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:425
msgid "Destructor"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:427
msgid ""
"This is the opposite to Constructor, it allows to separate any basic type "
"(ie, Vector3) into its sub-elements."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:433
msgid "Emit Signal"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:435
msgid ""
"Emits signals from any object. In general it's not that useful, as dragging "
"a signal to the canvas works better."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:439
msgid "Get/Set"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:441
msgid ""
"Generic Getter/Setter node. Dragging properties from the Inspector works "
"better, as they appear properly configured on drop."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:445
msgid "Wait"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:447
msgid ""
"The Wait nodes will suspend execution of the function until something "
"happens (many frames can pass until resuming, in fact). Default nodes allow "
"you to wait for a frame to pass, a fixed frame or a given amount of time "
"until execution is resumed."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:452
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:306
msgid "Yield"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:454
msgid ""
"This node completely suspends the execution of the script, and it will make "
"the function return a value that can be used to resume execution."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:458
msgid "Yield Signal"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:460
msgid "Same as Yield, but will wait until a given signal is emitted."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:464
msgid "Index"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:466
msgid ""
"Generic indexing operator, not often used but it's good that it exists just "
"in case."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:472
msgid ""
"These are mostly generic operators, such as addition, multiplication, "
"comparison, etc. By default, these mostly accept any datatype (and will "
"throw an error at run-time if the types fed do not match those expected by "
"the operator). It is always recommended to set the right type for operators "
"to catch errors faster and make the graph easier to read."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:481
msgid "Expression Node"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:483
msgid ""
"Among the operators, the *Expression* node is the most powerful. If well "
"used, it allows you to enormously simplify visual scripts that are math or "
"logic heavy. Type any expression on it and it will be executed in real-time."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:486
msgid "Expression nodes can:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:488
msgid ""
"Perform math and logic expressions based on custom inputs (eg: \"a*5+b\", "
"where a and b are custom inputs):"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:493
msgid "Access local variables or properties:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:498
msgid ""
"Use most of the existing built-in functions that are available to GDScript, "
"such as ``sin()``, ``cos()``, ``print()``, as well as constructors, such as "
"``Vector3(x, y, z)``, ``Rect2(...)``, etc.:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:503
msgid "Call API functions:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:508
msgid ""
"Use sequenced mode, which makes more sense in case of respecting the "
"processing order:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:4
#, fuzzy
msgid "Custom VisualScript nodes"
msgstr "Android"

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:6
msgid ""
"Custom nodes are written in GDScript and can then be used in VisualScript. "
"This is useful for offloading complex code to GDScript and reusing it."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:10
#, fuzzy
msgid "Creating a custom node"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:12
msgid ""
"Create a new script that extends :ref:`class_VisualScriptCustomNode` and put "
"a ``tool`` keyword at the top. This is needed for the script to run in the "
"editor."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:14
msgid ""
"There are some functions that can be implemented to set parameters of the "
"custom node. Only add functions that are needed, a "
"``_has_input_sequence_port`` function is not necessary if it should return "
"``false`` for example."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:17
msgid ""
"The most important part of a custom node is the ``_step`` function. The "
"logic of the node is defined there."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:19
msgid "The ``inputs`` parameter holds the value of the input ports."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:21
msgid ""
"The ``outputs`` parameter is an array where the indices represent the output "
"port ids. It can be modified to set the values of the output ports."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:23
msgid ""
"``start_mode`` can be checked to see if it is the first time ``_step`` is "
"called."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:25
msgid ""
"``working_mem`` is persistent each ``_step`` call. It can be used to store "
"information."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:27
msgid ""
"If you want to throw an error, for example if the input types are incorrect, "
"you can return the error message as a string. When everything goes right, "
"return the id of the sequence port which should be called next. If your "
"custom node doesn't have any, just return 0."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:31
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:71
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:92
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:132
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:143
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:155
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:313
#: ../../docs/tutorials/io/background_loading.rst:268
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:90
#: ../../docs/tutorials/platform/services_for_ios.rst:205
#: ../../docs/tutorials/platform/services_for_ios.rst:252
#: ../../docs/community/contributing/code_style_guidelines.rst:150
msgid "Example:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:94
msgid "Using a custom node"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:96
msgid ""
"To use the script, add a ``CustomNode``, select it and drag your custom node "
"script into the ``script`` property shown in the inspector."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/custom_visualscript_nodes.rst:100
#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:263
msgid "Result:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/index.rst:2
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:30
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:59
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:199
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:214
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:237
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:245
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:260
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:272
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:329
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:124
msgid "C#"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:4
msgid "C# basics"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:9
msgid ""
"C# support is a new feature available since Godot 3.0. As such, you may "
"still run into some issues, or find spots where the documentation could be "
"improved. Please report issues with C# in Godot on the `engine GitHub page "
"<https://github.com/godotengine/godot/issues>`_, and any documentation "
"issues on the `documentation GitHub page <https://github.com/godotengine/"
"godot-docs/issues>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:17
msgid ""
"This page provides a brief introduction to C#, both what it is and how to "
"use it in Godot. Afterwards, you may want to look at :ref:`how to use "
"specific features <doc_c_sharp_features>`, read about the :ref:`differences "
"between the C# and the GDScript API <doc_c_sharp_differences>` and (re)visit "
"the :ref:`Scripting section <doc_scripting>` of the step-by-step tutorial."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:24
msgid ""
"C# is a high-level programming language developed by Microsoft. In Godot, it "
"is implemented with the Mono 6.x .NET framework, including full support for "
"C# 8.0. Mono is an open source implementation of Microsoft's .NET Framework "
"based on the ECMA standards for C# and the Common Language Runtime. A good "
"starting point for checking its capabilities is the `Compatibility <http://"
"www.mono-project.com/docs/about-mono/compatibility/>`_ page in the Mono "
"documentation."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:32
msgid ""
"This is **not** a full-scale tutorial on the C# language as a whole. If you "
"aren't already familiar with its syntax or features, see the `Microsoft C# "
"guide <https://docs.microsoft.com/en-us/dotnet/csharp/index>`_ or look for a "
"suitable introduction elsewhere."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:39
msgid "Setting up C# for Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:42
#, fuzzy
msgid "Windows (Visual Studio)"
msgstr "וינדוס ( וגם UWP)"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:44
msgid ""
"Download and install the latest version of `Visual Studio <https://"
"visualstudio.microsoft.com/downloads/>`_ (*not* Visual Studio Code), which "
"contains utilities required to use C# in Godot. If you don't plan on using "
"the Visual Studio IDE, you can download just the `Visual Studio Build Tools "
"<https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?"
"sku=BuildTools&rel=15>`_ instead. Make sure you at least have the .NET "
"Framework 4.5 targeting pack installed, you can get it using any of the "
"installers mentioned above inside the \"Individual components\" tab."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:54
#, fuzzy
msgid "Windows (JetBrains Rider)"
msgstr "וינדוס ( וגם UWP)"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:56
msgid ""
"JetBrains Rider comes with bundled MSBuild, so nothing extra is required. "
"Make sure to set the following preferences:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:59
msgid "In Godot:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:61
msgid "Mono External Editor to JetBrains Rider"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:62
msgid "Mono Build Tool to JetBrains Mono."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:64
msgid "In Rider:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:66
msgid "Set ``MSBuild version`` to either bundled with Rider or .NET Core."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:67
msgid "Install **Godot support** plugin."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:70
msgid "macOS and Linux"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:72
msgid ""
"Download and install the latest version of the `Mono SDK <http://www.mono-"
"project.com/download/>`_. As of Godot 3.1 beta 3, the version number doesn't "
"matter since Godot bundles its own Mono 5.18 installation. We only need the "
"Mono installation for NuGet and MSBuild which are required to use C# in "
"Godot."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:78
msgid ""
"To download Mono on macOS, use the \"Stable Channel\" link from the `Mono "
"Downloads Page <http://www.mono-project.com/download/>`_. The Visual Studio "
"channel is an earlier version of Mono and will not work."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:84
#, fuzzy
msgid "Additional notes"
msgstr "אנימציות"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:86
msgid ""
"Your Godot version must have Mono support enabled, so make sure to download "
"the **Mono version** of Godot. If you are building Godot from source, make "
"sure to follow the steps to enable Mono support in your build as outlined in "
"the :ref:`doc_compiling_with_mono` page."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:92
msgid ""
"In summary, you must have installed Visual Studio or Mono (depending on your "
"operating system) **and** the Mono-enabled version of Godot."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:96
msgid "Configuring an external editor"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:98
msgid ""
"C# support in Godot's script editor is minimal. Consider using an external "
"IDE or editor, such as  `Visual Studio Code <https://code.visualstudio.com/"
">`_ or MonoDevelop. These provide autocompletion, debugging, and other "
"useful features for C#. To select an external editor in Godot, click on "
"**Editor → Editor Settings** and scroll down to **Mono**. Under **Mono**, "
"click on **Editor**, and select your external editor of choice. Godot "
"currently supports the following external editors:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:107
msgid "Visual Studio 2019"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:109
#, fuzzy
msgid "MonoDevelop"
msgstr "פיתוח"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:110
msgid "Visual Studio for Mac"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:113
msgid ""
"If you are using Visual Studio Code, ensure you download and install the `C# "
"extension <https://marketplace.visualstudio.com/items?itemName=ms-vscode."
"csharp>`_ to enable features like syntax highlighting and IntelliSense."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:118
msgid ""
"If you are using Visual Studio 2019, you must follow the instructions found "
"in the \"Configure VS2019 for Debugging\" section below."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:122
msgid "Creating a C# script"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:124
msgid ""
"After you successfully set up C# for Godot, you should see the following "
"option when selecting ``Attach script`` in the context menu of a node in "
"your scene:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:129
msgid ""
"Note that while some specifics change, most concepts work the same when "
"using C# for scripting. If you're new to Godot, you may want to follow the "
"tutorials on :ref:`doc_scripting` at this point. While some places in the "
"documentation still lack C# examples, most concepts can be transferred "
"easily from GDScript."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:136
msgid "Project setup and workflow"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:138
msgid ""
"When you create the first C# script, Godot initializes the C# project files "
"for your Godot project. This includes generating a C# solution (``.sln``) "
"and a project file (``.csproj``), as well as some utility files and folders "
"(``.mono`` and ``Properties/AssemblyInfo.cs``). All of these but ``.mono`` "
"are important and should be committed to your version control system. ``."
"mono`` can be safely added to the ignore list of your VCS. When "
"troubleshooting, it can sometimes help to delete the ``.mono`` folder and "
"let it regenerate."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:148
#: ../../docs/tutorials/io/background_loading.rst:87
#: ../../docs/tutorials/misc/pausing_games.rst:80
msgid "Example"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:150
msgid ""
"Here's a blank C# script with some comments to demonstrate how it works."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:177
msgid ""
"As you can see, functions normally in global scope in GDScript like Godot's "
"``print`` function are available in the ``GD`` class which is part of the "
"``Godot`` namespace. For a list of methods in the ``GD`` class, see the "
"class reference pages for :ref:`@GDScript <class_@gdscript>` and :ref:"
"`@GlobalScope <class_@globalscope>`."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:184
msgid ""
"Keep in mind that the class you wish to attach to your node should have the "
"same name as the ``.cs`` file. Otherwise, you will get the following error "
"and won't be able to run the scene: *\"Cannot find class XXX for script "
"res://XXX.cs\"*"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:190
msgid "General differences between C# and GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:192
msgid ""
"The C# API uses ``PascalCase`` instead of ``snake_case`` in GDScript/C++. "
"Where possible, fields and getters/setters have been converted to "
"properties. In general, the C# Godot API strives to be as idiomatic as is "
"reasonably possible."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:196
msgid "For more information, see the :ref:`doc_c_sharp_differences` page."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:199
msgid "Current gotchas and known issues"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:201
msgid ""
"As C# support is quite new in Godot, there are some growing pains and things "
"that need to be ironed out. Below is a list of the most important issues you "
"should be aware of when diving into C# in Godot, but if in doubt, also take "
"a look over the official `issue tracker for Mono issues <https://github.com/"
"godotengine/godot/labels/topic%3Amono>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:207
msgid ""
"Writing editor plugins is possible, but it is currently quite convoluted."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:208
msgid ""
"State is currently not saved and restored when hot-reloading, with the "
"exception of exported variables."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:210
msgid ""
"Attached C# scripts should refer to a class that has a class name that "
"matches the file name."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:212
msgid ""
"There are some methods such as ``Get()``/``Set()``, ``Call()``/"
"``CallDeferred()`` and signal connection method ``Connect()`` that rely on "
"Godot's ``snake_case`` API naming conventions. So when using e.g. "
"``CallDeferred(\"AddChild\")``, ``AddChild`` will not work because the API "
"is expecting the original ``snake_case`` version ``add_child``. However, you "
"can use any custom properties or methods without this limitation."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:220
msgid ""
"As of Godot 3.2.2, exporting Mono projects is supported for desktop "
"platforms (Linux, Windows and macOS), Android, HTML5, and iOS. The only "
"platform not supported yet is UWP."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:225
msgid "Performance of C# in Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:227
msgid ""
"According to some preliminary `benchmarks <https://github.com/cart/godot3-"
"bunnymark>`_, the performance of C# in Godot — while generally in the same "
"order of magnitude — is roughly **~4×** that of GDScript in some naive "
"cases. C++ is still a little faster; the specifics are going to vary "
"according to your use case. GDScript is likely fast enough for most general "
"scripting workloads. C# is faster, but requires some expensive marshalling "
"when talking to Godot."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:235
msgid "Using NuGet packages in Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:237
msgid ""
"`NuGet <https://www.nuget.org/>`_ packages can be installed and used with "
"Godot, as with any C# project. Many IDEs are able to add packages directly. "
"They can also be added manually by adding the package reference in the ``."
"csproj`` file located in the project root:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:254
msgid ""
"By default, tools like NuGet put ``Version`` as an attribute of the "
"```PackageReference``` Node. **You must manually create a Version node as "
"shown above.**  This is because the version of MSBuild used requires this. "
"(This will be fixed in Godot 4.0.)"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:256
msgid ""
"Whenever packages are added or modified, run ``nuget restore`` (*not* "
"``dotnet restore``) in the root of the project directory. To ensure that "
"NuGet packages will be available for msbuild to use, run:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:265
msgid "Profiling your C# code"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:267
msgid ""
"`Mono log profiler <https://www.mono-project.com/docs/debug+profile/profile/"
"profiler/>`_ is available for Linux and macOS. Due to a Mono change, it does "
"not work on Windows currently."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:268
msgid ""
"External Mono profiler like `JetBrains dotTrace <https://www.jetbrains.com/"
"profiler/>`_ can be used as described `here <https://github.com/godotengine/"
"godot/pull/34382>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:271
msgid "Configuring VS 2019 for debugging"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:275
msgid ""
"Godot has built-in support for workflows involving several popular C# IDEs. "
"Built-in support for Visual Studio will be including in future versions, but "
"in the meantime, the steps below can let you configure VS 2019 for use with "
"Godot C# projects."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:280
msgid ""
"Install VS 2019 with ``.NET desktop development`` and ``Desktop development "
"with C++`` workloads selected."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:281
msgid ""
"**Ensure that you do not have Xamarin installed.** Do not choose the "
"``Mobile development with .NET`` workload. Xamarin changes the DLLs used by "
"MonoDebugger, which breaks debugging."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:282
msgid ""
"Install the `VSMonoDebugger extension <https://marketplace.visualstudio.com/"
"items?itemName=GordianDotNet.VSMonoDebugger0d62>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:283
msgid "In VS 2019 --> Extensions --> Mono --> Settings:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:285
msgid "Select ``Debug/Deploy to local Windows``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:286
msgid "Leave ``Local Deploy Path`` blank."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:287
msgid ""
"Set the ``Mono Debug Port`` to the port in Godot --> Project --> Project "
"Settings --> Mono --> Debugger Agent."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:288
msgid ""
"Also select ``Wait for Debugger`` in the Godot Mono options. `This Godot "
"Addon <https://godotengine.org/asset-library/asset/435>`_ may be helpful."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:290
msgid ""
"Run the game in Godot. It should hang at the Godot splash screen while it "
"waits for your debugger to attach."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:291
msgid ""
"In VS 2019, open your project and choose Extensions --> Mono --> Attach to "
"Mono Debugger."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:294
msgid "Configuring Visual Studio Code for debugging"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:296
msgid ""
"To configure Visual Studio Code for debugging open up a project in Godot. "
"Click on Project and open the project settings. Scroll down and click on "
"Debugger Agent under the Mono category. Then turn on the setting \"wait for "
"debugger.\" Next, copy the port number and open up Visual Studio Code."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:301
msgid ""
"You need to download the Mono Debug extension from Microsoft. Then open the "
"Godot project folder. Go to the run tab and click on create a launch.json "
"file. Select C# Mono from the dropdown menu. When the launch.json file is "
"automatically opened, change the port number to the number you copied "
"previously and save the file. On the run tab, switch the run setting from "
"launch to attach. Whenever you want to debug, make sure Wait for Debugger is "
"turned on in Godot, run the project, and run the debugger in Visual Studio "
"Code."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:4
#, fuzzy
msgid "C# features"
msgstr "לכידה"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:6
msgid ""
"This page provides an overview of the commonly used features of both C# and "
"Godot and how they are used together."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:12
msgid "Type conversion and casting"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:14
msgid ""
"C# is a statically typed language. Therefore, you can't do the following:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:21
msgid ""
"The method ``GetNode()`` returns a ``Node`` instance. You must explicitly "
"convert it to the desired derived type, ``Sprite`` in this case."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:24
msgid "For this, you have various options in C#."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:26
msgid "**Casting and Type Checking**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:28
msgid ""
"Throws ``InvalidCastException`` if the returned node cannot be cast to "
"Sprite. You would use it instead of the ``as`` operator if you are pretty "
"sure it won't fail."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:36
msgid "**Using the AS operator**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:38
msgid ""
"The ``as`` operator returns ``null`` if the node cannot be cast to Sprite, "
"and for that reason, it cannot be used with value types."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:47
msgid "**Using the generic methods**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:49
msgid ""
"Generic methods are also provided to make this type conversion transparent."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:51
msgid ""
"``GetNode<T>()`` casts the node before returning it. It will throw an "
"``InvalidCastException`` if the node cannot be cast to the desired type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:58
msgid ""
"``GetNodeOrNull<T>()`` uses the ``as`` operator and will return ``null`` if "
"the node cannot be cast to the desired type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:66
msgid "**Type checking using the IS operator**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:68
msgid ""
"To check if the node can be cast to Sprite, you can use the ``is`` operator. "
"The ``is`` operator returns false if the node cannot be cast to Sprite, "
"otherwise it returns true."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:79
msgid ""
"For more advanced type checking, you can look into `Pattern Matching "
"<https://docs.microsoft.com/en-us/dotnet/csharp/pattern-matching>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:84
#, fuzzy
msgid "C# signals"
msgstr "אותות"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:86
msgid ""
"For a complete C# example, see the **Handling a signal** section in the step "
"by step :ref:`doc_scripting` tutorial."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:88
msgid ""
"Declaring a signal in C# is done with the ``[Signal]`` attribute on a "
"delegate."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:98
msgid ""
"These signals can then be connected either in the editor or from code with "
"``Connect``. If you want to connect a signal in the editor, you need to "
"(re)build the project assemblies to see the new signal. This build can be "
"manually triggered by clicking the “Build” button at the top right corner of "
"the editor window."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:119
msgid "Emitting signals is done with the ``EmitSignal`` method."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:129
msgid ""
"Notice that you can always reference a signal name with the ``nameof`` "
"keyword (applied on the delegate itself)."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:131
msgid ""
"It is possible to bind values when establishing a connection by passing an "
"object array."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:151
msgid ""
"Signals support parameters and bound values of all the `built-in types "
"<https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/"
"built-in-types-table>`_ and Classes derived from :ref:`Godot.Object "
"<class_Object>`. Consequently, any ``Node`` or ``Reference`` will be "
"compatible automatically, but custom data objects will need to extend from "
"`Godot.Object` or one of its subclasses."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:163
msgid ""
"Finally, signals can be created by calling ``AddUserSignal``, but be aware "
"that it should be executed before any use of said signals (with ``Connect`` "
"or ``EmitSignal``)."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:174
msgid "Preprocessor defines"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:176
msgid ""
"Godot has a set of defines that allow you to change your C# code depending "
"on the environment you are compiling to."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:179
msgid ""
"If you created your project before Godot 3.2, you have to modify or "
"regenerate your `csproj` file to use this feature (compare "
"``<DefineConstants>`` with a new 3.2+ project)."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:186
msgid "For example, you can change code based on the platform:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:203
msgid ""
"Or you can detect which engine your code is in, useful for making cross-"
"engine libraries:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:219
msgid "Full list of defines"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:221
msgid "``GODOT`` is always defined for Godot projects."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:223
msgid ""
"One of ``GODOT_64`` or ``GODOT_32`` is defined depending on if the "
"architecture is 64-bit or 32-bit."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:225
msgid ""
"One of ``GODOT_X11``, ``GODOT_WINDOWS``, ``GODOT_OSX``, ``GODOT_ANDROID``, "
"``GODOT_HTML5``, or ``GODOT_SERVER`` depending on the OS. These names may "
"change in the future. These are created from the ``get_name()`` method of "
"the :ref:``OS <class_OS>`` singleton, but not every possible OS the method "
"returns is an OS that Godot with Mono runs on."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:230
msgid ""
"When **exporting**, the following may also be defined depending on the "
"export features:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:232
msgid ""
"One of ``GODOT_PC``, ``GODOT_MOBILE``, or ``GODOT_WEB`` depending on the "
"platform type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:234
msgid ""
"One of ``GODOT_ARM64_V8A`` or ``GODOT_ARMEABI_V7A`` on Android only "
"depending on the architecture."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:236
msgid ""
"One of ``GODOT_S3TC``, ``GODOT_ETC``, or ``GODOT_ETC2`` depending on the "
"texture compression type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:238
msgid ""
"Any custom features added in the export menu will be capitalized and "
"prefixed: ``foo`` -> ``GODOT_FOO``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:4
msgid "C# API differences to GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:6
msgid "This is a (incomplete) list of API differences between C# and GDScript."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:9
msgid "General differences"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:11
msgid ""
"As explained in the :ref:`doc_c_sharp`, C# generally uses ``PascalCase`` "
"instead of the ``snake_case`` used in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:15
#: ../../docs/tutorials/threads/thread_safe_apis.rst:15
msgid "Global scope"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:17
msgid ""
"Global functions and some constants had to be moved to classes, since C# "
"does not allow declaring them in namespaces. Most global constants were "
"moved to their own enums."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:24
msgid ""
"Global constants were moved to their own enums. For example, ``ERR_*`` "
"constants were moved to the ``Error`` enum."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:27
msgid "Special cases:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:32
msgid "``SPKEY``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:32
msgid "``GD.SpKey``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:33
msgid "``TYPE_*``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:33
msgid "``Variant.Type`` enum"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:34
msgid "``OP_*``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:34
msgid "``Variant.Operator`` enum"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:38
msgid "Math functions"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:40
msgid ""
"Math global functions, like ``abs``, ``acos``, ``asin``, ``atan`` and "
"``atan2``, are located under ``Mathf`` as ``Abs``, ``Acos``, ``Asin``, "
"``Atan`` and ``Atan2``. The ``PI`` constant can be found as ``Mathf.Pi``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:45
msgid "Random functions"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:47
msgid ""
"Random global functions, like ``rand_range`` and ``rand_seed``, are located "
"under ``GD``. Example: ``GD.RandRange`` and ``GD.RandSeed``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:51
msgid "Other functions"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:53
msgid ""
"Many other global functions like ``print`` and ``var2str`` are located under "
"``GD``. Example: ``GD.Print`` and ``GD.Var2Str``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:56
msgid "Exceptions:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:61
msgid "``weakref(obj)``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:61
msgid "``Object.WeakRef(obj)``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:62
msgid "``is_instance_valid(obj)``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:62
msgid "``Object.IsInstanceValid(obj)``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:66
msgid "Tips"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:68
msgid ""
"Sometimes it can be useful to use the ``using static`` directive. This "
"directive allows to access the members and nested types of a class without "
"specifying the class name."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:86
msgid "Export keyword"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:88
msgid ""
"Use the ``[Export]`` attribute instead of the GDScript ``export`` keyword. "
"This attribute can also be provided with optional :ref:"
"`PropertyHint<enum_@GlobalScope_PropertyHint>` and ``hintString`` "
"parameters. Default values can be set by assigning a value."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:114
msgid "Signal keyword"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116
msgid ""
"Use the ``[Signal]`` attribute to declare a signal instead of the GDScript "
"``signal`` keyword. This attribute should be used on a `delegate`, whose "
"name signature will be used to define the signal."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:124
msgid "See also: :ref:`c_sharp_signals`"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:127
msgid "Singletons"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:129
msgid ""
"Singletons are available as static classes rather than using the singleton "
"pattern. This is to make code less verbose than it would be with an "
"``Instance`` property."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:138
msgid ""
"However, in some very rare cases this is not enough. For example, you may "
"want to access a member from the base class ``Godot.Object``, like "
"``Connect``. For such use cases we provide a static property named "
"``Singleton`` that returns the singleton instance. The type of this instance "
"is ``Godot.Object``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:150
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:242
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
#: ../../docs/development/cpp/core_types.rst:174
msgid "String"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:152
msgid ""
"Use ``System.String`` (``string``). Most of Godot's String methods are "
"provided by the ``StringExtensions`` class as extension methods."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:162
#, fuzzy
msgid "There are a few differences, though:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:164
msgid ""
"``erase``: Strings are immutable in C#, so we cannot modify the string "
"passed to the extension method. For this reason, ``Erase`` was added as an "
"extension method of ``StringBuilder`` instead of string. Alternatively, you "
"can use ``string.Remove``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:168
msgid ""
"``IsSubsequenceOf``/``IsSubsequenceOfi``: An additional method is provided, "
"which is an overload of ``IsSubsequenceOf``, allowing you to explicitly "
"specify case sensitivity:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:179
msgid ""
"``Match``/``Matchn``/``ExprMatch``: An additional method is provided besides "
"``Match`` and ``Matchn``, which allows you to explicitly specify case "
"sensitivity:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:190
msgid "Basis"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:192
msgid ""
"Structs cannot have parameterless constructors in C#. Therefore, ``new "
"Basis()`` initializes all primitive members to their default value. Use "
"``Basis.Identity`` for the equivalent of ``Basis()`` in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:196
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:242
msgid "The following method was converted to a property with a different name:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:201
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:217
msgid "``get_scale()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:201
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:217
msgid "``Scale``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:205
msgid "Transform2D"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:207
msgid ""
"Structs cannot have parameterless constructors in C#. Therefore, ``new "
"Transform2D()`` initializes all primitive members to their default value. "
"Please use ``Transform2D.Identity`` for the equivalent of ``Transform2D()`` "
"in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:211
msgid ""
"The following methods were converted to properties with their respective "
"names changed:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:216
msgid "``get_rotation()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:216
msgid "``Rotation``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:221
msgid "Plane"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:223
msgid ""
"The following method was converted to a property with a *slightly* different "
"name:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
msgid "``center()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
msgid "``Center``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:232
msgid "Rect2"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:234
msgid ""
"The following field was converted to a property with a *slightly* different "
"name:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:239
msgid "``end``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:239
msgid "``End``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:247
msgid "``get_area()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:247
msgid "``Area``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:251
msgid "Quat"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:253
msgid ""
"Structs cannot have parameterless constructors in C#. Therefore, ``new "
"Quat()`` initializes all primitive members to their default value. Please "
"use ``Quat.Identity`` for the equivalent of ``Quat()`` in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:257
msgid ""
"The following methods were converted to a property with a different name:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:262
msgid "``length()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:262
#, fuzzy
msgid "``Length``"
msgstr "נתיב"

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:263
msgid "``length_squared()``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:263
msgid "``LengthSquared``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:269
msgid ""
"*This is temporary. PoolArrays will need their own types to be used the way "
"they are meant to.*"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:274
msgid "``Array``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:274
msgid "``Godot.Collections.Array``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:275
msgid "``PoolIntArray``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:275
msgid "``int[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:276
msgid "``PoolByteArray``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:276
msgid "``byte[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:277
msgid "``PoolFloatArray``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:277
msgid "``float[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:278
msgid "``PoolStringArray``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:278
msgid "``String[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:279
msgid "``PoolColorArray``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:279
msgid "``Color[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:280
msgid "``PoolVector2Array``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:280
msgid "``Vector2[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:281
msgid "``PoolVector3Array``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:281
msgid "``Vector3[]``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:284
msgid ""
"``Godot.Collections.Array<T>`` is a type-safe wrapper around ``Godot."
"Collections.Array``. Use the ``Godot.Collections.Array<T>(Godot.Collections."
"Array)`` constructor to create one."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:290
msgid "Use ``Godot.Collections.Dictionary``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:292
msgid ""
"``Godot.Collections.Dictionary<T>`` is a type-safe wrapper around ``Godot."
"Collections.Dictionary``. Use the ``Godot.Collections.Dictionary<T>(Godot."
"Collections.Dictionary)`` constructor to create one."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:296
msgid "Variant"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:298
msgid "``System.Object`` (``object``) is used instead of ``Variant``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:301
msgid "Communicating with other scripting languages"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:303
msgid "This is explained extensively in :ref:`doc_cross_language_scripting`."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:308
msgid ""
"Something similar to GDScript's ``yield`` with a single parameter can be "
"achieved with C#'s `yield keyword <https://docs.microsoft.com/en-US/dotnet/"
"csharp/language-reference/keywords/yield>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:311
msgid ""
"The equivalent of yield on signal can be achieved with async/await and "
"``Godot.Object.ToSignal``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:321
msgid "Other differences"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:323
msgid ""
"``preload``, as it works in GDScript, is not available in C#. Use ``GD."
"Load`` or ``ResourceLoader.Load`` instead."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:326
msgid "Other differences:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:331
msgid "``Color8``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:331
msgid "``Color.Color8``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:332
msgid "``is_inf``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:332
msgid "``float.IsInfinity``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:333
msgid "``is_nan``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:333
msgid "``float.IsNaN``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:334
msgid "``dict2inst``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:334
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:335
msgid "TODO"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:335
msgid "``inst2dict``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:4
msgid "C# style guide"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:6
msgid ""
"Having well-defined and consistent coding conventions is important for every "
"project, and Godot is no exception to this rule."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:9
msgid ""
"This page contains a coding style guide, which is followed by developers of "
"and contributors to Godot itself. As such, it is mainly intended for those "
"who want to contribute to the project, but since the conventions and "
"guidelines mentioned in this article are those most widely adopted by the "
"users of the language, we encourage you to do the same, especially if you do "
"not have such a guide yet."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:14
msgid ""
"This article is by no means an exhaustive guide on how to follow the "
"standard coding conventions or best practices. If you feel unsure of an "
"aspect which is not covered here, please refer to more comprehensive "
"documentation, such as `C# Coding Conventions <https://docs.microsoft.com/en-"
"us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions>`_ or "
"`Framework Design Guidelines <https://docs.microsoft.com/en-us/dotnet/"
"standard/design-guidelines/naming-guidelines>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:21
msgid "Language specification"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:23
msgid ""
"Godot currently uses **C# version 7.0** in its engine and example source "
"code. So, before we move to a newer version, care must be taken to avoid "
"mixing language features only available in C# 7.1 or later."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:27
msgid ""
"For detailed information on C# features in different versions, please see "
"`What's New in C# <https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/"
">`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:34
msgid "General guidelines"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:36
msgid "Use line feed (**LF**) characters to break lines, not CRLF or CR."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:37
msgid ""
"Use one line feed character at the end of each file, except for `csproj` "
"files."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:38
msgid ""
"Use **UTF-8** encoding without a `byte order mark <https://en.wikipedia.org/"
"wiki/Byte_order_mark>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:39
msgid ""
"Use **4 spaces** instead of tabs for indentation (which is referred to as "
"\"soft tabs\")."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:40
msgid ""
"Consider breaking a line into several if it's longer than 100 characters."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:44
#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:102
msgid "Line breaks and blank lines"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:46
msgid ""
"For a general indentation rule, follow `the \"Allman Style\" <https://en."
"wikipedia.org/wiki/Indentation_style#Allman_style>`_ which recommends "
"placing the brace associated with a control statement on the next line, "
"indented to the same level:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:63
msgid "However, you may choose to omit line breaks inside brackets:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:65
msgid "For simple property accessors."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:66
msgid "For simple object, array, or collection initializers."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:67
msgid "For abstract auto property, indexer, or event declarations."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:89
msgid "Insert a blank line:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:91
msgid "After a list of ``using`` statements."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:92
msgid "Between method, properties, and inner type declarations."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:93
msgid "At the end of each file."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:95
msgid ""
"Field and constant declarations can be grouped together according to "
"relevance. In that case, consider inserting a blank line between the groups "
"for easier reading."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:98
msgid "Avoid inserting a blank line:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:100
msgid "After ``{``, the opening brace."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:101
msgid "Before ``}``, the closing brace."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:102
msgid "After a comment block or a single-line comment."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:103
msgid "Adjacent to another blank line."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:142
msgid "Using spaces"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:144
msgid "Insert a space:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:146
msgid "Around a binary and tertiary operator."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:147
msgid ""
"Between an opening parenthesis and ``if``, ``for``, ``foreach``, ``catch``, "
"``while``, ``lock`` or ``using`` keywords."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:148
msgid "Before and within a single line accessor block."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:149
msgid "Between accessors in a single line accessor block."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:150
msgid "After a comma which is not at the end of a line."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:151
msgid "After a semicolon in a ``for`` statement."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:152
msgid "After a colon in a single line ``case`` statement."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:153
msgid "Around a colon in a type declaration."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:154
msgid "Around a lambda arrow."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:155
msgid ""
"After a single-line comment symbol (``//``), and before it if used at the "
"end of a line."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:157
msgid "Do not use a space:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:159
msgid "After type cast parentheses."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:160
msgid "Within single line initializer braces."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:162
msgid ""
"The following example shows a proper use of spaces, according to some of the "
"above mentioned conventions:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:199
msgid ""
"Use **PascalCase** for all namespaces, type names and member level "
"identifiers (i.e. methods, properties, constants, events), except for "
"private fields:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:220
msgid ""
"Use **camelCase** for all other identifiers (i.e. local variables, method "
"arguments), and use an underscore (``_``) as a prefix for private fields "
"(but not for methods or properties, as explained above):"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:234
msgid ""
"There's an exception with acronyms which consist of two letters, like "
"``UI``, which should be written in uppercase letters where PascalCase would "
"be expected, and in lowercase letters otherwise."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:237
msgid ""
"Note that ``id`` is **not** an acronym, so it should be treated as a normal "
"identifier:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:248
msgid ""
"It is generally discouraged to use a type name as a prefix of an identifier, "
"like ``string strText`` or ``float fPower``, for example. An exception is "
"made, however, for interfaces, which **should**, in fact, have an uppercase "
"letter ``I`` prefixed to their names, like ``IInventoryHolder`` or "
"``IDamageable``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:252
msgid ""
"Lastly, consider choosing descriptive names and do not try to shorten them "
"too much if it affects readability."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:255
msgid ""
"For instance, if you want to write code to find a nearby enemy and hit it "
"with a weapon, prefer:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:261
msgid "Rather than:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:282
msgid "Implicitly typed local variables"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:284
msgid ""
"Consider using implicitly typing (``var``) for declaration of a local "
"variable, but do so **only when the type is evident** from the right side of "
"the assignment:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:314
msgid "Other considerations"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:316
msgid "Use explicit access modifiers."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:317
msgid "Use properties instead of non-private fields."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:318
msgid ""
"Use modifiers in this order: ``public``/``protected``/``private``/"
"``internal``/``virtual``/``override``/``abstract``/``new``/``static``/"
"``readonly``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:320
msgid ""
"Avoid using fully-qualified names or ``this.`` prefix for members when it's "
"not necessary."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:321
msgid "Remove unused ``using`` statements and unnecessary parentheses."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:322
msgid "Consider omitting the default initial value for a type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:323
msgid ""
"Consider using null-conditional operators or type initializers to make the "
"code more compact."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:324
msgid ""
"Use safe cast when there is a possibility of the value being a different "
"type, and use direct cast otherwise."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:4
#, fuzzy
msgid "Cross-language scripting"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:6
msgid ""
"Godot allows you to mix and match scripting languages to suit your needs. "
"This means a single project can define nodes in both C# and GDScript. This "
"page will go through the possible interactions between two nodes written in "
"different languages."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:11
msgid ""
"The following two scripts will be used as references throughout this page."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:66
msgid "Instantiating nodes"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:68
msgid ""
"If you're not using nodes from the scene tree, you'll probably want to "
"instantiate nodes directly from the code."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:72
msgid "Instantiating C# nodes from GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:74
msgid ""
"Using C# from GDScript doesn't need much work. Once loaded (see :ref:"
"`doc_gdscript_classes_as_resources`), the script can be instantiated with :"
"ref:`new() <class_CSharpScript_method_new>`."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:86
msgid ""
"When creating ``.cs`` scripts, you should always keep in mind that the class "
"Godot will use is the one named like the ``.cs`` file itself. If that class "
"does not exist in the file, you'll see the following error: ``Invalid call. "
"Nonexistent function `new` in base``."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:91
msgid "For example, MyCoolNode.cs should contain a class named MyCoolNode."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:93
msgid ""
"You also need to check your ``.cs`` file is referenced in the project's ``."
"csproj`` file. Otherwise, the same error will occur."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:97
msgid "Instantiating GDScript nodes from C#"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:99
msgid ""
"From the C# side, everything work the same way. Once loaded, the GDScript "
"can be instantiated with :ref:`GDScript.New() <class_GDScript_method_new>`."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:107
msgid ""
"Here we are using an :ref:`class_Object`, but you can use type conversion "
"like explained in :ref:`doc_c_sharp_features_type_conversion_and_casting`."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:111
msgid "Accessing fields"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:114
msgid "Accessing C# fields from GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:116
msgid ""
"Accessing C# fields from GDScript is straightforward, you shouldn't have "
"anything to worry about."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:128
msgid ""
"Note that it doesn't matter if the field is defined as a property or an "
"attribute. However, trying to set a value on a property that does not define "
"a setter will result in a crash."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:133
msgid "Accessing GDScript fields from C#"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:135
msgid ""
"As C# is statically typed, accessing GDScript from C# is a bit more "
"convoluted, you will have to use :ref:`Object.Get() "
"<class_Object_method_get>` and :ref:`Object.Set() "
"<class_Object_method_set>`. The first argument is the name of the field you "
"want to access."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:148
msgid ""
"Keep in mind that when setting a field value you should only use types the "
"GDScript side knows about. Essentially, you want to work with built-in types "
"as described in :ref:`doc_gdscript` or classes extending :ref:`class_Object`."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:153
msgid "Calling methods"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:156
msgid "Calling C# methods from GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:158
msgid ""
"Again, calling C# methods from GDScript should be straightforward. The "
"marshalling process will do its best to cast your the arguments to match "
"function signatures. If that's impossible, you'll see the following error: "
"``Invalid call. Nonexistent function `FunctionName```."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:174
msgid "Calling GDScript methods from C#"
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:176
msgid ""
"To call GDScript methods from C# you'll need to use :ref:`Object.Call() "
"<class_Object_method_call>`. The first argument is the name of the method "
"you want to call. The following arguments will be passed to said method."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:198
msgid ""
"As you can see, if the first argument of the called method is an array, "
"you'll need to cast it as ``object``. Otherwise, each element of your array "
"will be treated as a single argument and the function signature won't match."
msgstr ""

#: ../../docs/getting_started/scripting/cross_language_scripting.rst:206
msgid ""
"A GDScript file may not inherit from a C# script. Likewise, a C# script may "
"not inherit from a GDScript file. Due to how complex this would be to "
"implement, this limitation is unlikely to be lifted in the future. See `this "
"GitHub issue <https://github.com/godotengine/godot/issues/38352>`__ for more "
"information."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:4
#, fuzzy
msgid "Creating script templates"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/creating_script_templates.rst:6
msgid ""
"Godot provides a way to use script templates as seen in the ``Script Create "
"Dialog`` while creating a new script:"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:11
msgid ""
"A set of default script templates is provided by default, but it's also "
"possible to modify existing and create new ones, both per project and the "
"editor."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:15
#, fuzzy
msgid "Locating the templates"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/scripting/creating_script_templates.rst:17
msgid "There are two places where templates can be managed."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:20
msgid "Editor-defined templates"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:22
msgid ""
"These are available globally throughout any project. The location of these "
"templates are determined per each OS:"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:25
msgid "Windows: ``%APPDATA%\\Godot\\script_templates\\``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:26
msgid "Linux: ``$HOME/.local/share/godot/script_templates/``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:27
msgid "macOS: ``$HOME/Library/Application Support/Godot/script_templates/``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:29
msgid ""
"If no ``script_templates`` is detected, Godot will create a default set of "
"built-in templates automatically, so this logic can be used to reset the "
"default templates in case you've accidentally overwritten them."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:34
msgid "Project-defined templates"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:36
msgid ""
"The default path to search for templates is the ``res://script_templates/`` "
"directory. The path can be changed by configuring the ``editor/"
"script_templates_search_path`` setting in the :ref:`ProjectSettings "
"<class_ProjectSettings>`, both via code and the editor."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:41
msgid ""
"If no ``script_templates`` directory is found within a project, it is simply "
"ignored."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:45
msgid "Language support and overriding behavior"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:47
msgid ""
"Depending on whether a particular language implements a way to generate "
"scripts out of templates, it's possible to create a template which can be "
"recognized by that language according to template's file extension. For "
"GDScript and C#, the extensions must be ``gd`` and ``cs`` respectively."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:52
msgid ""
"The script templates have the same extension as the regular script files. "
"This may lead to an issue of a script parser treating those templates as "
"actual scripts within a project. To avoid this, make sure to ignore the "
"directory containing them by creating a ``.gdignore`` file. The directory "
"won't be visible throughout the project's filesystem anymore, yet the "
"templates can be modified by an external text editor anytime."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:59
msgid ""
"The built-in editor templates are automatically shadowed by the project-"
"specific templates given both scripts have the same filename."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:63
msgid "Default template"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:65
msgid ""
"The ``Default`` template is always generated dynamically per language and "
"cannot be configured nor overridden, but you can use these as the base for "
"creating other templates."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:116
msgid "List of template placeholders"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:118
msgid ""
"The following describes the complete list of built-in template placeholders "
"which are currently implemented."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:122
msgid "Base placeholders"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:125
#: ../../docs/getting_started/scripting/creating_script_templates.rst:147
msgid "Placeholder"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:127
msgid "``%CLASS%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:127
msgid "The name of the new class (used in C# only)."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:129
msgid "``%BASE%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:129
msgid "The base type a new script inherits from."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:131
msgid "``%TS%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:131
msgid ""
"Indentation placeholder. The exact type and number of whitespace characters "
"used for indentation is determined by the ``text_editor/indent/type`` and "
"``text_editor/indent/size`` settings in the :ref:`EditorSettings "
"<class_EditorSettings>` respectively."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:139
msgid "Type placeholders"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:141
msgid ""
"These are only relevant for GDScript with static typing. Whether these "
"placeholders are actually replaced is determined by the ``text_editor/"
"completion/add_type_hints`` setting in the :ref:`EditorSettings "
"<class_EditorSettings>`."
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:147
#: ../../docs/tutorials/misc/binary_serialization_api.rst:23
msgid "Value"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:149
msgid "``%INT_TYPE%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:149
msgid "``: int``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:151
msgid "``%STRING_TYPE%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:151
msgid "``: String``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:153
msgid "``%FLOAT_TYPE%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:153
msgid "``: float``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:155
msgid "``%VOID_RETURN%``"
msgstr ""

#: ../../docs/getting_started/scripting/creating_script_templates.rst:155
msgid "``-> void``"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:9
msgid ""
"Since Godot has no restrictions on project structure or filesystem usage, "
"organizing files when learning the engine can seem challenging. This "
"tutorial suggests a workflow which should be a good starting point. We will "
"also cover using version control with Godot."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:15
msgid "Organization"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:17
msgid ""
"Godot is scene-based in nature, and uses the filesystem as-is, without "
"metadata or an asset database."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:20
msgid ""
"Unlike other engines, many resources are contained within the scene itself, "
"so the amount of files in the filesystem is considerably lower."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:23
msgid ""
"Considering that, the most common approach is to group assets as close to "
"scenes as possible; when a project grows, it makes it more maintainable."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:27
msgid ""
"As an example, one can usually place into a single folder their basic "
"assets, such as sprite images, 3D model meshes, materials, and music, etc. "
"They can then use a separate folder to store built levels that use them."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:48
msgid "Style guide"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:50
msgid ""
"For consistency across projects, we recommend following these guidelines:"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:52
msgid ""
"Use **snake_case** for folder and file names (with the exception of C# "
"scripts). This sidesteps case sensitivity issues that can crop up after "
"exporting a project on Windows. C# scripts are an exception to this rule, as "
"the convention is to name them after the class name which should be in "
"PascalCase."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:57
msgid ""
"Use **PascalCase** for node names, as this matches built-in node casing."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:58
msgid ""
"In general, keep third-party resources in a top-level ``addons/`` folder, "
"even if they aren't editor plugins. This makes it easier to track which "
"files are third-party. There are some exceptions to this rule; for instance, "
"if you use third-party game assets for a character, it makes more sense to "
"include them within the same folder as the character scenes and scripts."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:65
msgid "Importing"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:67
msgid ""
"Godot versions prior to 3.0 did the import process from files outside the "
"project. While this can be useful in large projects, it resulted in an "
"organization hassle for most developers."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:71
msgid ""
"Because of this, assets are now transparently imported from within the "
"project folder."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:75
msgid "Ignoring specific folders"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:77
msgid ""
"To prevent Godot from importing files contained in a specific folder, create "
"an empty file called ``.gdignore`` in the folder (the leading ``.`` is "
"required). This can be useful to speed up the initial project importing."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:83
msgid ""
"To create a file whose name starts with a dot on Windows, you can use a text "
"editor such as Notepad++ or use the following command in a command prompt: "
"``type nul > .gdignore``"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:87
msgid ""
"Once the folder is ignored, resources in that folder can't be loaded anymore "
"using the ``load()`` and ``preload()`` methods."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:90
msgid ""
"Ignoring a folder will also automatically hide it from the FileSystem dock, "
"which can be useful to reduce clutter."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:94
msgid "Case sensitivity"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:96
msgid ""
"Windows and recent macOS versions use case-insensitive filesystems by "
"default, whereas Linux distributions use a case-sensitive filesystem by "
"default. This can cause issues after exporting a project, since Godot's PCK "
"virtual filesystem is case-sensitive. To avoid this, it's recommended to "
"stick to ``snake_case`` naming for all files in the project (and lowercase "
"characters in general)."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:105
msgid ""
"You can break this rule when style guides say otherwise (such as the C# "
"style guide). Still, be consistent to avoid mistakes."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:108
msgid ""
"On Windows 10, to further avoid mistakes related to case sensitivity, you "
"can also make the project folder case-sensitive. After enabling the Windows "
"Subsystem for Linux feature, run the following command in a PowerShell "
"window::"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:118
msgid ""
"If you haven't enabled the Windows Subsystem for Linux, you can enter the "
"following line in a PowerShell window *running as Administrator* then reboot "
"when asked::"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:4
msgid "Version Control Systems"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:9
msgid ""
"Godot aims to be VCS friendly and generate mostly readable and mergeable "
"files. Godot also supports the use of version control systems in the editor "
"itself. However, VCS in the editor requires a plugin for the specific VCS "
"you are using. VCS can be setup or shut down in the editor under **Project > "
"Version Control**."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:17
msgid "Official Git plugin"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:19
msgid ""
"Using Git from inside the editor is supported with an official plugin. You "
"can find the latest releases `here <https://github.com/godotengine/godot-git-"
"plugin/releases>`__ (it is not available in the asset library). "
"Documentation on how to use the Git plugin can be found `here <https://"
"github.com/godotengine/godot-git-plugin/wiki>`__."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:27
msgid "Files to exclude from VCS"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:29
msgid "There are some folders Godot creates you should have your VCS ignore:"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:31
msgid ""
"``.import/``: This folder stores all the files it imports automatically "
"based on your source assets and their import flags."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:33
msgid ""
"``*.translation``: These files are binary imported translations generated "
"from CSV files."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:34
msgid ""
"``export_presets.cfg``: This file contains all the export presets for the "
"project, including sensitive information such as Android keystore "
"credentials."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/version_control_systems.rst:36
msgid ""
"``.mono/``: This folder stores automatically-generated Mono files. It only "
"exists in projects that use the Mono version of Godot."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2
msgid "Blender ESCN exporter"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:4
msgid ""
"This chapter relates to the Blender plugin called \"Godot Blender Exporter"
"\", which can be downloaded here: https://github.com/godotengine/godot-"
"blender-exporter"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:7
msgid ""
"This plugin can be used to export Blender scenes in a Godot-specific scene "
"format called ESCN, which is similar to TSCN (text format) but will be "
"imported as binary SCN for performance."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:12
msgid "Details on exporting"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:27
msgid "Disabling specific objects"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29
msgid ""
"Sometimes you don't want some objects exported (e.g. high-res models used "
"for baking). An object will not be exported if it is not rendered in the "
"scene. This can be set in the outliner:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:35
msgid ""
"Objects hidden in the viewport will be exported, but will be hidden in the "
"Godot scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:40
msgid "Build pipeline integration"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:42
msgid ""
"If you have hundreds of model files, you don't want your artists to waste "
"time manually exporting their blend files. To combat this, the exporter "
"provides a python function ``io_scene_godot.export(out_file_path)`` that can "
"be called to export a file. This allows easy integration with other build "
"systems. An example Makefile and python script that exports all the blends "
"in a directory are present in the Godot-Blender-exporter repository."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:2
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154
#: ../../docs/tutorials/3d/using_gridmaps.rst:60
msgid "Materials"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:5
msgid "Using existing Godot materials"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:7
msgid ""
"One way in which the exporter can handle materials is to attempt to match "
"the Blender material with an existing Godot material. This has the advantage "
"of being able to use all of the features of Godot's material system, but it "
"means that you cannot see your model with the material applied inside "
"Blender."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:12
msgid ""
"To do this, the exporter attempts to find Godot materials with names that "
"match those of the material name in Blender. So if you export an object in "
"Blender with the material name ``PurpleDots`` then the exporter will search "
"for the file ``PurpleDots.tres`` and assign it to the object. If this file "
"is not a ``SpatialMaterial`` or ``ShaderMaterial`` or if it cannot be found, "
"then the exporter will fall back to exporting the material from Blender."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:20
msgid ""
"Where the exporter searches for the ``.tres`` file is determined by the "
"\"Material Search Paths\" option:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:34
msgid "This can take the value of:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:26
msgid ""
"Project Directory - Attempts to find the ``project.Godot`` and recursively "
"searches through subdirectories. If ``project.Godot`` cannot be found it "
"will throw an error. This is useful for most projects where naming conflicts "
"are unlikely."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:30
msgid ""
"Export Directory - Look for materials in subdirectories of the export "
"location. This is useful for projects where you may have duplicate material "
"names and need more control over what material gets assigned."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:33
msgid "None - Do not search for materials. Export them from the Blender file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:37
msgid "Export of Cycles/EEVEE materials"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:39
msgid ""
"The exporter has a primitive support for converting Cycles/EEVEE material "
"node tree to Godot Shader Material. Note that some of the Shader Node are "
"not supported yet due to difficulties in implementation, which are:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43
msgid "all the ``noisy textures``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:44
msgid "``generated texture coordinates``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:45
msgid "``group node``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:46
msgid ""
"shader nodes except ``PrincipledBSDF``, ``Diffuse``, ``Glossy``, ``Glass``, "
"``add shader`` and ``mix shader``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:50
msgid ""
"If possible, try to use PrincipledBSDF node with GGX distribution as the "
"output shader node, it is the only one guaranteed to be exactly correct. "
"Others are just based on approximation."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:53
msgid ""
"Sometimes materials may not be valid for exporting (e.g. has some "
"unsupported node) or it is using Blender Internal Engine, only the diffuse "
"color and a few flags (e.g. unshaded) are exported and form a Spatial "
"Material."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:59
msgid "Generate external materials"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:61
msgid ""
"The default configuration of material exporting would keep all the materials "
"internal to the ``escn`` file. There is an option which could enable "
"generating external ``.material`` file when the ``escn`` file opens in Godot."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:67
msgid ""
"``.material`` file can be assigned to any material slot to be a external "
"resource."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:2
msgid "Physics properties"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:4
msgid ""
"Exporting physics properties is done by enabling \"Rigid Body\" in Blender's "
"physics tab:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:10
msgid ""
"By default, a single Blender object with rigid body enabled will export as "
"three nodes: a PhysicsBody, a CollisionShape, and a MeshInstance."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:14
msgid "Body type"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:16
msgid ""
"Blender only has the concept of \"Active\" and \"Passive\" rigid bodies. "
"These turn into Static and RigidBody nodes. To create a kinematic body, "
"enable the \"animated\" checkbox on an \"Active\" body:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:23
#: ../../docs/tutorials/2d/using_tilemaps.rst:110
#: ../../docs/tutorials/physics/physics_introduction.rst:55
msgid "Collision shapes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:25
msgid ""
"Many of the parameters for collision shapes are missing from Blender, and "
"many of the collision shapes are also not present. However, almost all of "
"the options in Blender's rigid body collision and rigid body dynamics "
"interfaces are supported:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:39
msgid "There are the following caveats:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:33
msgid ""
"Not all of the collision shapes are supported. Only ``Mesh``, ``Convex "
"Hull``, ``Capsule``, ``Sphere`` and ``Box`` are supported in both Blender "
"and Godot"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:36
msgid ""
"In Godot, you can have different collision groups and collision masks. In "
"Blender you only have collision groups. As a result, the exported object's "
"collision mask is equal to its collision group. Most of the time, this is "
"what you want."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:42
msgid ""
"To build compound physics shapes, parent together multiple objects with "
"rigid body enabled. The physics properties are taken from the parent-most "
"rigid body, and the rest are used as collision shapes."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:47
msgid "Collision geometry only"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:49
msgid ""
"Frequently you want different geometry for your collision meshes and your "
"graphical meshes, but by default, the exporter will export a mesh along with "
"the collision shape. To only export the collision shape, set the object's "
"maximum draw type to Wire:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:56
msgid ""
"This will also influence how the object is shown in Blender's viewport. Most "
"of the time, you want your collision geometry to be shown see-through when "
"working on the models, so this works out fairly nicely."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:2
#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:68
#: ../../docs/tutorials/3d/introduction_to_3d.rst:223
msgid "Lights"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:4
msgid ""
"By default, lamps in Blender have shadows enabled. This can cause "
"performance issues in Godot."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:8
msgid ""
"Lamps are exported using their \"Blender Render\" settings. When Blender 2.8 "
"is released, this will be removed and this part of the exporter will change."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:11
msgid ""
"Sun, point and spot lamps are all exported from Blender along with many of "
"their properties:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:16
#, fuzzy
msgid "There are some things to note:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:18
msgid ""
"In Blender, a light casts light all the way to infinity. In Godot, it is "
"clamped by the attenuation distance. To most closely match between the "
"viewport and Godot, enable the \"Sphere\" checkbox. (Highlighted green)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:21
msgid ""
"Light attenuation models differ between Godot and Blender. The exporter "
"attempts to make them match, but it isn't always very good."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:23
msgid ""
"Spotlight angular attenuation models also differ between Godot and Blender. "
"The exporter attempts to make them similar, but it doesn't always look the "
"same."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/lights.rst:26
msgid ""
"There is no difference between buffer shadow and ray shadow in the export."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:2
msgid "Mesh"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:5
msgid "Modifiers"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:6
msgid ""
"There is an exporting option :code:`Apply Modifiers` to control whether mesh "
"modifiers are applied to the exported mesh."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:11
msgid "Shape Key"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:12
msgid ""
"Exporting mesh shape key is supported, however exporting each shape key is "
"almost like exporting the mesh again, so don't be surprised it takes a "
"relatively long time."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/mesh.rst:17
msgid ""
"A lot of modifiers are not compatible with shape keys (e.g. subsurface "
"modifier), so if you found you have incorrect shape keys exported, try to "
"disable :code:`Apply Modifiers` and do the exporting again. Besides, it is "
"worthwhile to report the incompatible modifier to the `issue list <https://"
"github.com/godotengine/godot-blender-exporter/issues>`__, which helps to "
"develop the exporter to have a more precise check of modifiers."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:2
#: ../../docs/development/file_formats/tscn.rst:161
msgid "Skeleton"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:7
msgid "Rest Bone"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:9
msgid ""
"Armature object in Blender is exported as a Skeleton node along with rest "
"position (transform in Godot) of bones."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:13
msgid ""
"The three check boxes :code:`Inherit Rotation`, :code:`Inherit Scale`, :code:"
"`Local Location` (colored in red) must be ticked when building armature in "
"Blender, so that the exported bone transform be consistent between Blender "
"and Godot"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:18
msgid ""
"It is important that the mesh is not deformed by bones when exporting in "
"Blender. Make sure that the skeleton is reset to its T-pose or default rest "
"pose."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:22
msgid "Bone Weights"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:24
msgid ""
"Blender put rigged mesh vertices which has no bone weights at its original "
"position, but these vertices would be placed at (0, 0, 0) in Godot, making "
"the mesh deformed. Therefore, the exporter would raise an error for any "
"vertex with no bone weights detected in a rigged mesh."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:30
msgid "Non-Deform Bone"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:32
msgid ""
"Note that the non-deform bone can be configured as not exported by enabling "
"the :code:`Exclude Control Bones`; the deform bone checkbox is shown in the "
"picture."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:38
msgid "Bone Attachment"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/skeleton.rst:39
msgid ""
"A bone can be the parent of an object in Blender; this relation is exported "
"as a BoneAttachment node in the Godot scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:8
#, fuzzy
msgid "Animation supported:"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:4
msgid "transform animation of all types of objects"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:5
msgid "transform animation of pose bones"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:6
#, fuzzy
msgid "shape key animation"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:7
#, fuzzy
msgid "light animation"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:8
#, fuzzy
msgid "camera animation"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:11
msgid "Multiple Actions For Single Object"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:12
msgid ""
"In most games, one object would have several animations to switch between. "
"This add-on has support for exporting multiple actions all at once into a "
"single AnimationPlayer and makes it easy to switch actions."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:16
msgid ""
"This workflow makes use of blender nla_tracks. Here is a brief guide on how "
"to use this feature:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:19
msgid "**1. Stash active action**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:21
msgid ""
"New created action is always an active action bound to object. There are "
"several ways to place an active action into NLA track, one is of course "
"doing it in ``NLA Editor``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:28
msgid "Or it can be done stashing the action in ``Dope Sheet``"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:33
msgid "**2. Check mute status of NLA tracks**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:35
msgid ""
"An NLA track can be ``mute`` or ``unmute``, the exporter will export all the "
"``mute`` NLA track as a separate action, while blends all the ``unmute`` NLA "
"tracks into every action (including the action action) being exported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:41
msgid "**3. Export the scene**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:43
msgid "Make sure the ``Export Stashed Actions`` option has been turned on."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:47
msgid ""
"Then all the stashed actions, as well as the active action, are exported to "
"an AnimationPlayer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:54
#, fuzzy
msgid "Constraints"
msgstr "קבועים"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:55
msgid ""
"Sometimes complicated animation is built with object constraint; a usual "
"example is inverse kinematics. The add-on would automatically check if an "
"object has some constraint; if it does, all the constraints are baked into "
"actions and then exported along with the object."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:62
#, fuzzy
msgid "Animation Mode"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:63
msgid ""
"Godot and Blender have different structure to store animation data. In Godot "
"animation data is stored in an AnimationPlayer node, instead of in each "
"animated node. In order to fix this inconsistence and still make the "
"animation play versatile, this add-on has three animation exporting modes."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:70
msgid "**Mode 'Animation as Actions'**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:72
msgid ""
"Treat all the animations as object actions, so in the exported scene, every "
"object would have its own AnimationPlayer and hold its actions."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:76
msgid "**Mode 'Scene Animation'**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:78
msgid ""
"If you want your animation to generate the same result as playing at "
"Blender's timeline, this is what you want. In this mode, all the animations "
"in the scene are placed in just one AnimationPlayer in the scene root."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:82
msgid "**Mode 'Animation as Action with Squash'**"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/animation.rst:84
msgid ""
"This mode has very similar behavior of mode 'Animation as Action', but it "
"can generate fewer AnimationPlayers; objects in parent-children relationship "
"would share their AnimationPlayer. It is useful when you have several rigs, "
"and each Skeleton and Mesh has actions; then one rig would have just one "
"AnimationPlayer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/index.rst:2
msgid "Assets workflow"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:4
msgid "Import process"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:7
msgid "Importing assets in Godot 3.0+"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:9
msgid ""
"Previously, importing assets in Godot 2.x required manual maintenance of a "
"separate directory with source assets. Without doing this, it was impossible "
"to specify how to convert and change import flags for textures, audio files, "
"scenes, etc."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:14
msgid ""
"In Godot 3.0, we use a more modern approach to importing: Simply drop your "
"assets (image files, scenes, audio files, fonts, etc) directly in the "
"project folder (copy them manually with your OS file explorer). Godot will "
"automatically import these files internally and keep the imported resources "
"hidden in a res://.import folder."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:20
msgid "This allows changing all the import parameters transparently."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:23
msgid "Changing import parameters"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:25
msgid ""
"Changing the import parameters of an asset in Godot (again, keep in mind "
"import parameters are only present in non-native Godot resource types) is "
"easy. Select the relevant resource in the filesystem dock:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:31
msgid ""
"Then, after adjusting the parameters, press \"Reimport\". These parameters "
"will only be used for this asset and on future reimports."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:34
msgid ""
"Changing the import parameters of several assets at the same time is also "
"possible. Simply select all of them together in the resources dock and the "
"exposed parameters will apply to all of them when reimporting."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:39
msgid "Automatic reimport"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:41
msgid ""
"When the MD5 checksum of the source asset changes, Godot will perform an "
"automatic reimport of it, applying the preset configured for that specific "
"asset."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:46
msgid "Files generated"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:48
msgid ""
"Importing will add an extra <asset>.import file, containing the import "
"configuration. Make sure to commit these to your version control system!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:53
msgid ""
"Additionally, extra assets will be preset in the hidden res://.import folder:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:57
msgid ""
"If any of the files present in this folder is erased (or the whole folder), "
"the asset or assets will be reimported automatically. As such, committing "
"this folder to the version control system is optional. It can shorten "
"reimporting time when checking out on another computer, but it takes "
"considerably more space and transfer time. Pick your poison!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:64
msgid "Changing import resource type"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:66
msgid ""
"Some source assets can be imported as different types of resources. For "
"this, select the relevant type of resource desired and press \"Reimport\":"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:74
msgid "Changing default import parameters"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:76
msgid ""
"Different types of games might require different defaults. Changing the "
"defaults per project can be achieved by using the \"Preset..\" Menu. Besides "
"some resource types offering presets, the default setting can be saved and "
"cleared too:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:84
msgid "Simplicity is key!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:86
msgid ""
"This is a very simple workflow which should take very little time to get "
"used to. It also enforces a more correct way to deal with resources."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:89
msgid ""
"There are many types of assets available for import, so please continue "
"reading to understand how to work with all of them!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:4
msgid "Importing images"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:7
msgid "Why import them?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:9
msgid ""
"In Godot 3+, image files are no longer native resources and they must be "
"imported. The reason behind this is the large amount of configuration "
"parameters that image files can be imported with."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:13
msgid ""
"This small tutorial will explain what these parameters are and how to best "
"make use of them."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:17
msgid "Importing textures"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:19
msgid ""
"The default action in Godot is to import images as textures. Textures are "
"stored in video memory and can't be accessed directly. This is what makes "
"drawing them efficient."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:23
msgid "Import options are vast:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:28
msgid "Detect 3D"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:30
msgid ""
"This option makes Godot be aware of when a texture (which is imported for 2D "
"as default) is used in 3D. If this happens, setting are changed so the "
"texture flags are friendlier to 3D (mipmaps, filter and repeat become "
"enabled and compression is changed to VRAM). Texture is also reimported "
"automatically."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:34
#, fuzzy
msgid "Supported image formats"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/importing_images.rst:36
msgid "Godot can import the following image formats:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:38
msgid ""
"BMP (``.bmp``) - No support for 16-bit per pixel images. Only 1-bit, 4-bit, "
"8-bit, 24-bit, and 32-bit per pixel images are supported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:40
msgid ""
"DirectDraw Surface (``.dds``) - If mipmaps are present in the texture, they "
"will be loaded directly. This can be used to achieve effects using custom "
"mipmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:43
msgid ""
"OpenEXR (``.exr``) - Supports HDR (highly recommended for panorama skies)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:45
msgid ""
"Radiance HDR (``.hdr``) - Supports HDR (highly recommended for panorama "
"skies)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:47
msgid ""
"JPEG (``.jpg``, ``.jpeg``) - Doesn't support transparency per the format's "
"limitations."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:49
msgid ""
"PNG (``.png``) - Precision is limited to 8 bits per channel upon importing "
"(no HDR images)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:51
msgid "Truevision Targa (``.tga``)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
msgid ""
"SVG (``.svg``, ``.svgz``) - SVGs are rasterized using `NanoSVG <https://"
"github.com/memononen/nanosvg>`__ when importing them. Support is limited; "
"complex vectors may not render correctly. For complex vectors, rendering "
"them to PNGs using Inkscape is often a better solution. This can be "
"automated thanks to its `command-line interface <https://wiki.inkscape.org/"
"wiki/index.php/Using_the_Command_Line#Export_files>`__."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:57
msgid "WebP (``.webp``)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:61
msgid ""
"If you've compiled the Godot editor from source with specific modules "
"disabled, some formats may not be available."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:65
msgid "Compression"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:67
msgid ""
"Images are one of the largest assets in a game. To handle them efficiently, "
"they need to be compressed. Godot offers several compression methods, "
"depending on the use case."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:71
msgid "Compress Mode"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:73
msgid ""
"**VRAM Compression:** This is the most common compression mode for 3D "
"assets. Size on disk is reduced and video memory usage is also decreased "
"considerably (usually by a factor between 4 and 6). This mode should be "
"avoided for 2D as it exhibits noticeable artifacts."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:77
msgid ""
"**Lossless Compression:** This is the most common compression mode for 2D "
"assets. It shows assets without any kind of artifacting, and disk "
"compression is decent. It will use considerably more amount of video memory "
"than VRAM Compression, though. This is also the recommended setting for "
"pixel art."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:81
msgid ""
"**Lossy Compression:** This is a good choice for large 2D assets. It has "
"some artifacts, but less than VRAM and the file size is several times lower "
"compared to Lossless or Uncompressed. Video memory usage isn't decreased by "
"this mode; it's the same as with Lossless Compression or Uncompressed."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:85
msgid ""
"**Uncompressed:** Only useful for formats that can't be compressed (such as "
"raw float images)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:88
msgid ""
"In this table, each of the four options are described together with their "
"advantages and disadvantages (|good| = best, |bad| = worst):"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:92
msgid "Uncompressed"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:92
msgid "Compress Lossless (PNG)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:92
msgid "Compress Lossy (WebP)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:92
msgid "Compress VRAM"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:94
msgid "Stored as raw pixels"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:94
msgid "Stored as PNG"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:94
msgid "Stored as WebP"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:94
msgid "Stored as S3TC/BC or PVRTC/ETC depending on platform"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:96
msgid "Size on Disk"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:96
#: ../../docs/getting_started/workflow/assets/importing_images.rst:98
msgid "|bad| Large"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:96
msgid "|regular| Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:96
msgid "|good| Very Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:98
msgid "Memory Usage"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:98
msgid "|good| Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:100
msgid "Performance"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:100
#: ../../docs/getting_started/workflow/assets/importing_images.rst:104
msgid "|regular| Normal"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:100
#: ../../docs/getting_started/workflow/assets/importing_images.rst:104
msgid "|good| Fast"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:102
msgid "Quality Loss"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:102
msgid "|good| None"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:102
msgid "|regular| Slight"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:102
msgid "|bad| Moderate"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:104
msgid "Load Time"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:104
msgid "|bad| Slow"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:114
msgid "HDR Mode"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:116
msgid ""
"Godot supports high dynamic range textures (as .HDR or .EXR). These are "
"mostly useful as high dynamic range equirectangular panorama skies (the "
"internet has plenty if you search for them), which replace Cubemaps in Godot "
"2.x. Modern PCs support the BC6H VRAM format, but there are still plenty "
"that do not."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:119
msgid ""
"If you want Godot to ensure full compatibility in terms of the kind of "
"textures, enable the \"Force RGBE\" option."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:122
msgid "Normal Map"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:124
msgid ""
"When using a texture as normal map, only the red and green channels are "
"required. Given regular texture compression algorithms produce artifacts "
"that don't look that nice in normal maps, the RGTC compression format is the "
"best fit for this data. Forcing this option to \"Enabled\" will make Godot "
"import the image as RGTC compressed. By default, it's set to \"Detect\", "
"which means that if the texture is ever used as a normal map, it will be "
"changed to \"Enabled\" and reimported automatically."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:129
msgid ""
"Note that RGTC compression affects the resulting normal map image. You will "
"have to adjust custom shaders that use the normal map to take this into "
"account."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:133
#: ../../docs/tutorials/3d/spatial_material.rst:369
msgid ""
"Godot requires the normal map to use the X+, Y- and Z+ coordinates. In other "
"words, if you've imported a material made to be used with another engine, "
"you may have to convert the normal map so its Y axis is flipped. Otherwise, "
"the normal map direction may appear to be inverted on the Y axis."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:138
#: ../../docs/tutorials/3d/spatial_material.rst:374
msgid ""
"More information about normal maps (including a coordinate order table for "
"popular engines) can be found `here <http://wiki.polycount.com/wiki/"
"Normal_Map_Technical_Details>`__."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:143
#: ../../docs/tutorials/3d/spatial_material.rst:30
msgid "Flags"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:145
msgid ""
"There are plenty of settings that can be toggled when importing an image as "
"a texture, depending on the use case."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:148
msgid "Repeat"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:150
msgid ""
"This setting is most commonly used in 3D, and is therefore generally "
"disabled in 2D. It sets UV coordinates going beyond the 0,0 - 1,1 range to "
"\"loop\"."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:152
msgid "Repeating can optionally be set to mirrored mode."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:155
#: ../../docs/tutorials/audio/audio_buses.rst:180
msgid "Filter"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:157
msgid ""
"When pixels become larger than the screen pixels, this option enables linear "
"interpolation for them. The result is a smoother (less blocky) texture. This "
"setting can be commonly used in 2D and 3D, but it's usually disabled when "
"making pixel perfect games."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:160
msgid "Mipmaps"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:162
msgid ""
"When pixels become smaller than the screen, mipmaps kick in. This helps "
"reduce the grainy effect when shrinking the textures. Keep in mind that, in "
"older hardware (GLES2, mainly mobile), there are some requirements to use "
"mipmaps:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:165
msgid "Texture width and height must be powers of 2"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:166
msgid "Repeat must be enabled"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:168
msgid ""
"Keep in mind the above when making phone games and applications, want to aim "
"for full compatibility, and need mipmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:170
msgid ""
"When doing 3D, mipmap should be turned on, as this also improves performance "
"(smaller versions of the texture are used for objects further away)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:173
msgid "Anisotropic"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:175
msgid ""
"When textures are near parallel to the view (like floors), this option makes "
"them have more detail by reducing blurriness."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:178
msgid "SRGB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:180
msgid ""
"Godot uses Linear colorspace when rendering 3D. Textures mapped to albedo or "
"detail channels need to have this option turned on in order for colors to "
"look correct. When set to \"Detect\" mode, the texture will be marked as "
"SRGB when used in albedo channels."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:184
msgid "Process"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:186
msgid ""
"Some special processes can be applied to images when imported as textures."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:189
msgid "Fix Alpha Border"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:191
msgid ""
"This puts pixels of the same surrounding color in transition from "
"transparency to non transparency. It helps mitigate the outline effect when "
"exporting images from Photoshop and the like."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:196
msgid ""
"It's a good idea to leave it on by default, unless specific values are "
"needed."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:199
msgid "Premultiplied Alpha"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:201
msgid ""
"An alternative to fix darkened borders is to use premultiplied alpha. By "
"enabling this option, the texture will be converted to this format. Keep in "
"mind that a material will need to be created that uses the PREMULT ALPHA "
"blend mode on canvas items that need it."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:205
msgid "HDR as sRGB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:207
msgid ""
"A few HDR files are broken and contain sRGB color data. It is advised not to "
"use them, but, in the worst-case scenario, toggling this option on will make "
"them look right."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:210
msgid "Invert Color"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:212
msgid ""
"Reverses the image's color. This is useful, for example, to convert a height "
"map generated by external programs to depth map to use with :ref:"
"`doc_spatial_material`."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:4
msgid "Importing audio samples"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:7
msgid "Why import?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:9
msgid ""
"Raw audio data in general is large and undesired. Godot provides two main "
"options to import your audio data: WAV and Ogg Vorbis."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:12
msgid "Each has different advantages."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:14
msgid ""
"WAV files use raw data or light compression, make few demands on the CPU to "
"play back (hundreds of simultaneous voices in this format are fine), but "
"take up significant space."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:15
msgid ""
"Ogg Vorbis files use a stronger compression that results in much smaller "
"file size, but require significantly more processing power to play back."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:20
msgid "Here is a comparative chart."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:23
msgid "Format"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:23
msgid "1 second of audio"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:25
msgid "WAV 24-bit, 96 kHz, stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:25
msgid "576 KB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:27
msgid "WAV 16-bit, 44 kHz, mono"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:27
msgid "88 KB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:29
msgid "WAV 16-bit, IMA-ADPCM, mono"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:29
msgid "22 KB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:31
msgid "Ogg Vorbis 128 Kb/s, stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:31
msgid "16 KB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:33
msgid "Ogg Vorbis 96 Kb/s, stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:33
msgid "12 KB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:36
msgid ""
"Consider using WAV for short and repetitive sound effects, and Ogg Vorbis "
"for music, speech, and long sound effects."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:40
#: ../../docs/getting_started/workflow/best_practices/index.rst:2
msgid "Best practices"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:42
msgid ""
"Godot has an :ref:`extensive bus system <doc_audio_buses>` with built-in "
"effects. This saves SFX artists the need to add reverb to the sound effects, "
"reducing their size greatly and ensuring correct trimming. Say no to SFX "
"with baked reverb!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:49
msgid "As you can see above, sound effects become huge with reverb added."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:52
msgid "Trimming"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:54
msgid ""
"One issue that happens often is that the waveform is exported with long "
"silences at the beginning and at the end. These are inserted by DAWs when "
"saving to a waveform, increase their size unnecessarily and add latency to "
"the moment they are played back."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:59
msgid "Importing as WAV with the **Trimming** option enabled solves this."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:63
msgid "Looping"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:65
msgid ""
"Godot supports looping in the samples (tools such as Sound Forge or Audition "
"can add loop points to WAV files). This is useful for sound effects, such as "
"engines, machine guns etc. Ping-pong looping is also supported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:70
msgid ""
"As an alternative, the Import dock has a **Loop** option that enables "
"looping for the entire sample when importing."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:4
msgid "Importing translations"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:7
msgid "Games and internationalization"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:9
msgid ""
"The world is full of different markets and cultures and, to maximize "
"profits™, nowadays games are released in several languages. To solve this, "
"internationalized text must be supported in any modern game engine."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:14
msgid ""
"In regular desktop or mobile applications, internationalized text is usually "
"located in resource files (or .po files for GNU stuff). Games, however, can "
"use several orders of magnitude more text than applications, so they must "
"support efficient methods for dealing with loads of multilingual text."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:20
msgid ""
"There are two approaches to generate multilingual language games and "
"applications. Both are based on a key:value system. The first is to use one "
"of the languages as the key (usually English), the second is to use a "
"specific identifier. The first approach is probably easier for development "
"if a game is released first in English, later in other languages, but a "
"complete nightmare if working with many languages at the same time."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:28
msgid ""
"In general, games use the second approach and a unique ID is used for each "
"string. This allows you to revise the text while it is being translated to "
"other languages. The unique ID can be a number, a string, or a string with a "
"number (it's just a unique string anyway)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:33
msgid ""
"If you need a more powerful file format, Godot also supports loading "
"translations written in the gettext ``.po`` format. See :ref:"
"`doc_localization_using_gettext` for details."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:38
msgid "Translation format"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:40
msgid ""
"To complete the picture and allow efficient support for translations, Godot "
"has a special importer that can read CSV files. Most spreadsheet editors can "
"export to this format, so the only requirement is that the files have a "
"special arrangement. The CSV files **must** be saved with UTF-8 encoding "
"without a `byte order mark <https://en.wikipedia.org/wiki/"
"Byte_order_mark>`__."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:48
msgid ""
"By default, Microsoft Excel will always save CSV files with ANSI encoding "
"rather than UTF-8. There is no built-in way to do this, but there are "
"workarounds as described `here <https://stackoverflow.com/questions/4221176/"
"excel-to-csv-with-utf8-encoding>`__."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:53
msgid ""
"We recommend using `LibreOffice <https://www.libreoffice.org/>`__ or Google "
"Sheets instead."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:55
msgid "CSV files must be formatted as follows:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:58
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:77
msgid "keys"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:58
msgid "<lang1>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:58
msgid "<lang2>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:58
msgid "<langN>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:60
msgid "KEY1"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:60
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:62
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:64
#: ../../docs/tutorials/misc/binary_serialization_api.rst:33
msgid "string"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:62
msgid "KEY2"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:64
msgid "KEYN"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:67
msgid ""
"The \"lang\" tags must represent a language, which must be one of the :ref:"
"`valid locales <doc_locales>` supported by the engine. The \"KEY\" tags must "
"be unique and represent a string universally (they are usually in uppercase, "
"to differentiate from other strings). These keys will be replaced at runtime "
"by the matching translated string. Note that the case is important, \"KEY1\" "
"and \"Key1\" will be different keys. The top-left cell is ignored and can be "
"left empty or having any content. Here's an example:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:77
#: ../../docs/tutorials/i18n/locales.rst:178
msgid "en"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:77
#: ../../docs/tutorials/i18n/locales.rst:220
msgid "es"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:77
#: ../../docs/tutorials/i18n/locales.rst:372
msgid "ja"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:79
msgid "GREET"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:79
msgid "Hello, friend!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:79
msgid "Hola, amigo!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:79
msgid "こんにちは"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:81
msgid "ASK"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:81
msgid "How are you?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:81
msgid "Cómo está?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:81
msgid "元気ですか"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:83
msgid "BYE"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:83
msgid "Goodbye"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:83
msgid "Adiós"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:83
msgid "さようなら"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:85
msgid "QUOTE"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:85
msgid "\"Hello\" said the man."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:85
msgid "\"Hola\" dijo el hombre."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:85
msgid "「こんにちは」男は言いました"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:88
msgid ""
"The same example is shown below as a comma-separated plain text file, which "
"should be the result of editing the above in a spreadsheet. When editing the "
"plain text version, be sure to enclose with double quotes any message that "
"contains commas, line breaks or double quotes, so that commas are not parsed "
"as delimiters, line breaks don't create new entries and double quotes are "
"not parsed as enclosing characters. Be sure to escape any double quotes a "
"message may contain by preceding them with another double quote. "
"Alternatively, you can select another delimiter than comma in the import "
"options."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:107
msgid "CSV importer"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:109
msgid ""
"Godot will treat CSV files as translations by default. It will import them "
"and generate one or more compressed translation resource files next to it."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:112
msgid ""
"Importing will also add the translation to the list of translations to load "
"when the game runs, specified in project.godot (or the project settings). "
"Godot allows loading and removing translations at runtime as well."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:117
msgid ""
"Select the ``.csv`` file and access the **Import** dock to define import "
"options. You can toggle the compression of the imported translations, and "
"select the delimiter to use when parsing the CSV file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:123
msgid "Be sure to click **Reimport** after any change to these options."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:4
msgid "Importing 3D scenes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:7
msgid "Godot scene importer"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:9
msgid ""
"When dealing with 3D assets, Godot has a flexible and configurable importer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:11
msgid ""
"Godot works with *scenes*. This means that the entire scene being worked on "
"in your favorite 3D DCC will be transferred as close as possible."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:14
msgid "Godot supports the following 3D *scene file formats*:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:16
msgid "glTF 2.0. Godot has full support for text and binary formats."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:17
msgid "DAE (COLLADA), an older format that is fully supported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:18
msgid ""
"OBJ (Wavefront) formats. It is also fully supported, but pretty limited (no "
"support for pivots, skeletons, etc)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:19
msgid "ESCN, a Godot specific format that Blender can export with a plugin."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:20
msgid ""
"FBX, supported via the Open Asset Import library. However, FBX is "
"proprietary, so we recommend using other formats listed above, if suitable "
"for your workflow."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:23
msgid ""
"Just copy the scene file together with the texture to the project "
"repository, and Godot will do a full import."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:25
msgid ""
"It is important that the mesh is not deformed by bones when exporting. Make "
"sure that the skeleton is reset to its T-pose or default rest pose before "
"exporting with your favorite 3D editor."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:29
msgid "Exporting DAE files from Maya and 3DS Max"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:31
msgid ""
"Autodesk added built-in COLLADA support to Maya and 3DS Max, but it's broken "
"by default and should not be used. The best way to export this format is by "
"using the `OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/"
"OpenCOLLADA-Tools>`__ plugins. They work well, although they are not always "
"up-to date with the latest version of the software."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:39
msgid "Exporting glTF 2.0 files from Blender"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:41
msgid ""
"There are three ways to export glTF files from Blender. As a glTF binary (``."
"glb`` file), glTF embedded (``.gltf`` file), and with textures (``gltf`` + "
"``.bin`` + textures)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:44
msgid ""
"glTF binary files are the smallest of the three options. They include the "
"mesh and textures set up in Blender. When brought into Godot the textures "
"are part of the object's material file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:47
msgid ""
"glTF embedded files function the same way as binary files. They don't "
"provide extra functionality in Godot, and shouldn't be used since they have "
"a larger file size."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:50
msgid ""
"There are two reasons to use glTF with the textures separate. One is to have "
"the scene description in a text based format and the binary data in a "
"separate binary file. This can be useful for version control if you want to "
"review changes in a text based format. The second is you need the texture "
"files separate from the material file. If you don't need either of those "
"glTF binary files are fine."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55
msgid ""
"Blender does not export emissive textures with the glTF file. If your model "
"uses one it must be brought in separately."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:58
msgid "Exporting DAE files from Blender"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60
msgid ""
"Blender has built-in COLLADA support, but it does not work properly for the "
"needs of game engines and should not be used as is."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:63
msgid ""
"Godot provides a `Blender plugin <https://github.com/godotengine/collada-"
"exporter>`_ that will correctly export COLLADA scenes for use in Godot. It "
"does not work in Blender 2.8 or newer, but there are plans to update it in "
"the future."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:68
msgid "Exporting ESCN files from Blender"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:70
msgid ""
"The most powerful one, called `godot-blender-exporter <https://github.com/"
"godotengine/godot-blender-exporter>`__. It uses a .escn file, which is kind "
"of another name for a .tscn file (Godot scene file); it keeps as much "
"information as possible from a Blender scene. However, it is considered "
"experimental."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76
msgid ""
"The ESCN exporter has a detailed `document <escn_exporter/index.html>`__ "
"describing its functionality and usage."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80
msgid "Import workflows"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82
msgid ""
"Godot scene importer allows different workflows regarding how data is "
"imported. Depending on many options, it is possible to import a scene with:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:85
msgid ""
"External materials (default): Where each material is saved to a file "
"resource. Modifications to them are kept."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86
msgid ""
"External meshes: Where each mesh is saved to a different file. Many users "
"prefer to deal with meshes directly."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87
msgid ""
"External animations: Allowing saved animations to be modified and merged "
"when sources change."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:88
msgid ""
"External scenes: Save each of the root nodes of the imported scenes as a "
"separate scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89
msgid "Single scene: A single scene file with everything built in."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:93
msgid ""
"As different developers have different needs, this import process is highly "
"customizable."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:96
msgid "Import options"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:98
msgid "The importer has several options, which will be discussed below:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106
msgid "Root Type"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:108
msgid ""
"By default, the type of the root node in imported scenes is \"Spatial\", but "
"this can be modified."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:111
msgid "Root Name"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113
msgid "Allows setting a specific name to the generated root node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:116
msgid "Root Scale"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:118
msgid "The scale of the root node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121
msgid "Custom Script"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:123
msgid ""
"A special script to process the whole scene after import can be provided. "
"This is great for post processing, changing materials, doing funny stuff "
"with the geometry etc."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:127
msgid "Create a script like this:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:139
msgid ""
"The ``post_import`` function takes the imported scene as argument (the "
"parameter is actually the root node of the scene). The scene that will "
"finally be used must be returned. It can be a different one."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:144
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:163
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:218
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:310
msgid "Storage"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:146
msgid ""
"By default, Godot imports a single scene. This option allows specifying that "
"nodes below the root will each be a separate scene and instanced into the "
"imported one."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:150
msgid ""
"Of course, instancing such imported scenes in other places manually works, "
"too."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157
#: ../../docs/tutorials/io/data_paths.rst:51
msgid "Location"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159
msgid ""
"Godot supports materials in meshes or nodes. By default, materials will be "
"put on each node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165
msgid ""
"Materials can be stored within the scene or in external files. By default, "
"they are stored in external files so editing them is possible. This is "
"because most 3D DCCs don't have the same material options as those present "
"in Godot."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169
msgid ""
"When materials are built-in, they will be lost each time the source scene is "
"modified and re-imported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173
msgid "Keep On Reimport"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:175
msgid ""
"Once materials are edited to use Godot features, the importer will keep the "
"edited ones and ignore the ones coming from the source scene. This option is "
"only present if materials are saved as files."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:180
msgid "Meshes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:183
msgid "Compress"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185
msgid ""
"Makes meshes use less precise numbers for multiple aspects of the mesh in "
"order to save space."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198
msgid "These are:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:189
msgid ""
"Transform Matrix (Location, rotation, and scale)             : 32-bit float "
"to 16-bit signed integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190
msgid ""
"Vertices                                                     : 32-bit float "
"to 16-bit signed integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:191
msgid ""
"Normals                                                      : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:192
msgid ""
"Tangents                                                     : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:193
msgid ""
"Vertex Colors                                                : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:194
msgid ""
"UV                                                           : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:195
msgid ""
"UV2                                                          : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196
msgid ""
"Vertex weights                                               : 32-bit float "
"to 16-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:197
msgid ""
"Armature bones                                               : 32-bit float "
"to 16-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:198
msgid ""
"Array index                                                  : 32-bit or 16-"
"bit unsigned integer based on how many elements there are."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202
msgid "Additional info:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:201
msgid ""
"UV2 = The second UV channel for detail textures and baked lightmap textures."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202
msgid ""
"Array index = An array of numbers that number each element of the arrays "
"above; i.e. they number the vertices and normals."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:204
msgid ""
"In some cases, this might lead to loss of precision, so disabling this "
"option may be needed. For instance, if a mesh is very big or there are "
"multiple meshes being imported that cover a large area, compressing the "
"import of this mesh(es) may lead to gaps in geometry or vertices not being "
"exactly where they should be."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:210
msgid "Ensure Tangents"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212
msgid ""
"If textures with normal mapping are to be used, meshes need to have tangent "
"arrays. This option ensures that these are generated if not present in the "
"source scene. Godot uses Mikktspace for this, but it's always better to have "
"them generated in the exporter."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:220
msgid ""
"Meshes can be stored in separate files (resources) instead of built-in. This "
"does not have much practical use unless one wants to build objects with them "
"directly."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223
msgid ""
"This option is provided to help those who prefer working directly with "
"meshes instead of scenes."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:227
msgid "Light Baking"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:229
msgid "Whether or not the mesh is used in baked lightmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:231
msgid "**Disabled:** The mesh is not used in baked lightmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232
msgid "**Enable:** The mesh is used in baked lightmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:233
msgid ""
"**Gen Lightmaps:** The mesh is used in baked lightmaps, and unwraps a second "
"UV layer for lightmaps."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:235
msgid "For more information on light baking see :ref:`doc_baked_lightmaps`."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238
msgid "External Files"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240
msgid ""
"Generated meshes and materials can be optionally stored in a subdirectory "
"with the name of the scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:244
#, fuzzy
msgid "Animation options"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246
msgid ""
"Godot provides many options regarding how animation data is dealt with. Some "
"exporters (such as Blender) can generate many animations in a single file. "
"Others, such as 3DS Max or Maya, need many animations put into the same "
"timeline or, at worst, put each animation in a separate file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:253
msgid "Import of animations is enabled by default."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256
msgid "FPS"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:258
msgid ""
"Most 3D export formats store animation timeline in seconds instead of "
"frames. To ensure animations are imported as faithfully as possible, please "
"specify the frames per second used to edit them. Failing to do this may "
"result in shaky animations."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:263
msgid "Filter Script"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:265
msgid ""
"It is possible to specify a filter script in a special syntax to decide "
"which tracks from which animations should be kept."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268
msgid ""
"The filter script is executed against each imported animation. The syntax "
"consists of two types of statements, the first for choosing which animations "
"to filter, and the second for filtering individual tracks within the matched "
"animation. All name patterns are performed using a case insensitive "
"expression match, using ``?`` and ``*`` wildcards (using ``String.matchn()`` "
"under the hood)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:274
msgid ""
"The script must start with an animation filter statement (as denoted by the "
"line beginning with an ``@``). For example, if we would like to apply "
"filters to all imported animations which have a name ending in ``\"_Loop"
"\"``::"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:280
msgid ""
"Similarly, additional patterns can be added to the same line, separated by "
"commas. Here is a modified example to additionally *include* all animations "
"with names that begin with ``\"Arm_Left\"``, but also *exclude* all "
"animations which have names ending in ``\"Attack\"``::"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:286
msgid ""
"Following the animation selection filter statement, we add track filtering "
"patterns to indicate which animation tracks should be kept or discarded. If "
"no track filter patterns are specified, then all tracks within the matched "
"animations will be discarded!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:290
msgid ""
"It's important to note that track filter statements are applied in order for "
"each track within the animation, this means that one line may include a "
"track, a later rule can still discard it. Similarly, a track excluded by an "
"early rule may then be re-included once again by a filter rule further down "
"in the filter script."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295
msgid ""
"For example: include all tracks in animations with names ending in ``\"_Loop"
"\"``, but discard any tracks affecting a ``\"Skeleton\"`` which end in ``"
"\"Control\"``, unless they have ``\"Arm\"`` in their name::"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304
msgid ""
"In the above example, tracks like ``\"Skeleton:Leg_Control\"`` would be "
"discarded, while tracks such as ``\"Skeleton:Head\"`` or ``\"Skeleton:"
"Arm_Left_Control\"`` would be retained."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307
msgid ""
"Any track filter lines that do not begin with a ``+`` or ``-`` are ignored."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:312
msgid ""
"By default, animations are saved as built-in. It is possible to save them to "
"a file instead. This allows adding custom tracks to the animations and "
"keeping them after a reimport."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316
msgid "Optimizer"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318
msgid ""
"When animations are imported, an optimizer is run, which reduces the size of "
"the animation considerably. In general, this should always be turned on "
"unless you suspect that an animation might be broken due to it being enabled."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:322
msgid "Clips"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324
msgid ""
"It is possible to specify multiple animations from a single timeline as "
"clips. For this to work, the model must have only one animation that is "
"named ``default``. To create clips, change the clip amount to something "
"greater than zero. You can then name a clip, specify which frames it starts "
"and stops on, and choose whether the animation loops or not."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:333
msgid "Scene inheritance"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:335
msgid ""
"In many cases, it may be desired to make modifications to the imported "
"scene. By default, this is not possible because if the source asset changes "
"(source ``.dae``, ``.gltf``, ``.obj`` file re-exported from 3D modelling "
"app), Godot will re-import the whole scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:338
msgid ""
"It is possible, however, to make local modifications by using *Scene "
"Inheritance*. Try to open the imported scene and the following dialog will "
"appear:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:343
msgid "In inherited scenes, the only limitations for modifications are:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:345
msgid "Nodes can't be removed (but can be added anywhere)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:346
msgid ""
"Sub-Resources can't be edited (save them externally as described above for "
"this)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:348
msgid "Other than that, everything is allowed!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:351
msgid "Import hints"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:353
msgid ""
"Many times, when editing a scene, there are common tasks that need to be "
"done after exporting:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:355
msgid "Adding collision detection to objects"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:356
msgid "Setting objects as navigation meshes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:357
msgid ""
"Deleting nodes that are not used in the game engine (like specific lights "
"used for modelling)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:359
msgid ""
"To simplify this workflow, Godot offers a few suffixes that can be added to "
"the names of the objects in your 3D modelling software. When imported, Godot "
"will detect them and perform actions automatically:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:364
msgid "Remove nodes (-noimp)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:366
msgid ""
"Node names that have this suffix will be removed at import time, no matter "
"what their type is. They will not appear in the imported scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:370
msgid "Create collisions (-col, -colonly, -convcolonly)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:372
msgid ""
"Option \"-col\" will work only for Mesh nodes. If it is detected, a child "
"static collision node will be added, using the same geometry as the mesh."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:375
msgid ""
"However, it is often the case that the visual geometry is too complex or too "
"un-smooth for collisions, which ends up not working well."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:378
msgid ""
"To solve this, the \"-colonly\" modifier exists, which will remove the mesh "
"upon import and create a :ref:`class_staticbody` collision instead. This "
"helps the visual mesh and actual collision to be separated."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:382
msgid ""
"Option \"-convcolonly\" will create a :ref:`class_convexpolygonshape` "
"instead of a :ref:`class_concavepolygonshape`."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:384
msgid ""
"Option \"-colonly\" can also be used with Blender's empty objects. On "
"import, it will create a :ref:`class_staticbody` with a collision node as a "
"child. The collision node will have one of a number of predefined shapes, "
"depending on Blender's empty draw type:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:391
msgid "Single arrow will create a :ref:`class_rayshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:392
msgid "Cube will create a :ref:`class_boxshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:393
msgid "Image will create a :ref:`class_planeshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:394
msgid ""
"Sphere (and the others not listed) will create a :ref:`class_sphereshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:396
msgid ""
"For better visibility in Blender's editor, the user can set \"X-Ray\" option "
"on collision empties and set some distinct color for them in User "
"Preferences / Themes / 3D View / Empty."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:400
msgid "Create navigation (-navmesh)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:402
msgid ""
"A mesh node with this suffix will be converted to a navigation mesh. "
"Original Mesh node will be removed."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:406
msgid "Create a VehicleBody (-vehicle)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:408
msgid ""
"A mesh node with this suffix will be imported as a child to a :ref:"
"`VehicleBody <class_VehicleBody>` node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:411
msgid "Create a VehicleWheel (-wheel)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:413
msgid ""
"A mesh node with this suffix will be imported as a child to a :ref:"
"`VehicleWheel <class_VehicleWheel>` node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:416
msgid "Rigid Body (-rigid)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:418
msgid "Creates a rigid body from this mesh."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:421
msgid "Animation loop (-loop, -cycle)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:423
msgid ""
"Animation clips in the COLLADA document that start or end with the token "
"\"loop\" or \"cycle\" will be imported as a Godot Animation with the loop "
"flag set. This is case-sensitive and does not require a hyphen."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:427
msgid ""
"In Blender, this requires using the NLA Editor and naming the Action with "
"the \"loop\" or \"cycle\" prefix or suffix."
msgstr ""

#: ../../docs/getting_started/workflow/export/index.rst:2
msgid "Export"
msgstr "ייצוא"

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:4
msgid "Exporting projects"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:9
msgid "Why export?"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:11
msgid ""
"Originally, Godot did not have any means to export projects. The developers "
"would compile the proper binaries and build the packages for each platform "
"manually."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:15
msgid ""
"When more developers (and even non-programmers) started using it, and when "
"our company started taking more projects at the same time, it became evident "
"that this was a bottleneck."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:20
msgid "On PC"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:22
msgid ""
"Distributing a game project on PC with Godot is rather easy. Drop the Godot "
"binary in the same directory as the ``project.godot`` file, then compress "
"the project directory and you are done."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:26
msgid ""
"It sounds simple, but there are probably a few reasons why the developer may "
"not want to do this. The first one is that it may not be desirable to "
"distribute loads of files. Some developers may not like curious users "
"peeking at how the game was made, others may find it inelegant, and so on. "
"Another reason is that the developer might prefer a specially-compiled "
"binary, which is smaller in size, more optimized and does not include tools "
"like the editor and debugger."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:34
msgid ""
"Finally, Godot has a simple but efficient system for creating DLCs as extra "
"package files."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:38
msgid "On mobile"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:40
msgid ""
"The same scenario on mobile platforms is a little worse. To distribute a "
"project on those devices, a binary for each of those platforms is built, "
"then added to a native project together with the game data."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:45
msgid ""
"This can be troublesome because it means that the developer must be "
"familiarized with the SDK of each platform before even being able to export. "
"While learning each SDK is always encouraged, it can be frustrating to be "
"forced to do it at an undesired time."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:50
msgid ""
"There is also another problem with this approach: different devices prefer "
"some data in different formats to run. The main example of this is texture "
"compression. All PC hardware uses S3TC (BC) compression and that has been "
"standardized for more than a decade, but mobile devices use different "
"formats for texture compression, such as PVRTC (iOS) or ETC (Android)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:58
msgid "Export menu"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:60
msgid ""
"After many attempts at different export workflows, the current one has "
"proven to work the best. At the time of this writing, not all platforms are "
"supported yet, but the supported platforms continue to grow."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:64
msgid "To open the export menu, click the **Export** button:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:68
msgid ""
"The export menu will open. However, it will be completely empty. This is "
"because we need to add an export preset."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:73
msgid ""
"To create an export preset, click the **Add…** button at the top of the "
"export menu. This will open a drop-down list of platforms to choose from for "
"an export preset."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:79
msgid ""
"The default options are often enough to export, so tweaking them is usually "
"not necessary. However, many platforms require additional tools (SDKs) to be "
"installed to be able to export. Additionally, Godot needs export templates "
"installed to create packages. The export menu will complain when something "
"is missing and will not allow the user to export for that platform until "
"they resolve it:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:88
msgid ""
"At that time, the user is expected to come back to the documentation and "
"follow instructions on how to properly set up that platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:94
msgid ""
"Apart from setting up the platform, the export templates must be installed "
"to be able to export projects. They can be obtained as a TPZ file (which is "
"a renamed ZIP archive) from the `download page of the website <https://www."
"godotengine.org/download>`_."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:99
msgid ""
"Once downloaded, they can be installed using the **Install Export "
"Templates** option in the editor:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:105
msgid "Export mode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:107
msgid ""
"When exporting, Godot makes a list of all the files to export and then "
"creates the package. There are 3 different modes for exporting:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:110
#, fuzzy
msgid "Export all resources in the project"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:111
msgid "Export selected scenes (and dependencies)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:112
msgid "Export selected resources (and dependencies)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:116
msgid ""
"**Export all resources in the project** will export every resource in the "
"project. **Export selected scenes** and **Export selected resources** gives "
"you a list of the scenes or resources in the project, and you have to select "
"every scene or resource you want to export."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:124
msgid "Exporting from the command line"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:126
msgid ""
"In production, it is useful to automate builds, and Godot supports this with "
"the ``--export`` and ``--export-debug`` command line parameters. Exporting "
"from the command line still requires an export preset to define the export "
"parameters. A basic invocation of the command would be:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:135
msgid ""
"This will export to ``some_name.exe``, assuming there is a preset called "
"\"Windows Desktop\" and the template can be found. The output path is "
"relative to the project path or absolute; it does not respect the directory "
"the command was invoked from."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:140
msgid ""
"You can also configure it to export only the PCK or ZIP file, allowing a "
"single export to be used with multiple Godot executables. This takes place "
"if the target name ends with ``.pck`` or ``.zip``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:144
msgid ""
"It is often useful to combine the ``--export`` flag with the ``--path`` "
"flag, and to create a dedicated export preset for automated export:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:4
msgid "Exporting packs, patches, and mods"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:7
msgid "Use cases"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:9
msgid ""
"Oftentimes one would like to add functionality to one's game after it has "
"been deployed."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:12
msgid "Examples of this include..."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:14
msgid ""
"Downloadable Content: the ability to add features and content to one's game."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:15
msgid "Patches: the ability to fix a bug that is present in a shipped product."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:16
msgid "Mods: grant other people the ability to create content for one's game."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:18
msgid ""
"These tools help developers to extend their development beyond the initial "
"release."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:22
msgid "Overview of PCK files"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:24
msgid ""
"Godot enables this via a feature called **resource packs** (PCK files, with "
"extension ``.pck``)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:27
msgid "**Advantages:**"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:29
msgid "incremental updates/patches"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:30
msgid "offer DLCs"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:31
msgid "offer mod support"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:32
msgid "no source code disclosure needed for mods"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:33
msgid "more modular project structure"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:34
msgid "users don't have to replace the entire game"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:36
msgid ""
"The first part of using them involves exporting and delivering the project "
"to players. Then, when one wants to add functionality or content later on, "
"they just deliver the updates via PCK files to the users."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:40
msgid "PCK files usually contain, but are not limited to:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:42
#, fuzzy
msgid "scripts"
msgstr "תיאור"

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:43
msgid "scenes"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:44
msgid "shaders"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:45
msgid "models"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:46
msgid "textures"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:47
msgid "sound effects"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:48
msgid "music"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:49
msgid "any other asset suitable for import into the game"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:51
msgid ""
"The PCK files can even be an entirely different Godot project, which the "
"original game loads in at runtime."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:55
msgid "Generating PCK files"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:57
msgid ""
"In order to pack all resources of a project into a PCK file open the project "
"and go to Project/Export and click on “Export PCK/Zip”. Also make sure to "
"have an export template selected while doing so."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:63
msgid ""
"Another method would be to :ref:`export from the command line "
"<doc_command_line_tutorial_exporting>`. If the output file ends with a PCK "
"or ZIP file extension, then the export process will build that type of file "
"for the chosen platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:69
msgid ""
"If one wishes to support mods for their game, they will need their users to "
"create similarly exported files. Assuming the original game expects a "
"certain structure for the PCK's resources and/or a certain interface for its "
"scripts, then either..."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:74
msgid ""
"The developer must publicize documentation of these expected structures/ "
"interfaces, expect modders to install Godot Engine, and then also expect "
"those modders to conform to the documentation's defined API when building "
"mod content for the game (so that it will work). Users would then use "
"Godot's built in exporting tools to create a PCK file, as detailed above."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:80
msgid ""
"The developer uses Godot to build a GUI tool for adding their exact API "
"content to a project. This Godot tool must either run on a tools-enabled "
"build of the engine or have access to one (distributed alongside or perhaps "
"in the original game's files). The tool can then use the Godot executable to "
"export a PCK file from the command line with :ref:`OS.execute() "
"<class_OS_method_execute>`. It makes the most sense for the game to not use "
"a tool-build though (for security) and for the modding tools to *do* use a "
"tool-enabled engine build."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:90
msgid "Opening PCK files at runtime"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:92
msgid ""
"To import a PCK file, one uses a one-liner. Keep in mind, there is no error "
"or exception if the import fails. Instead, one might have to create some "
"validation code as a layer on top. The following example expects a “mod.pck” "
"file in the directory of the games executable. The PCK file contains a "
"“mod_scene.tscn” test scene in its root."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:117
msgid ""
"By default, if you import a file with the same file path/name as one you "
"already have in your project, the imported one will replace it. This is "
"something to watch out for when creating DLC or mods (solved easily with a "
"tool isolating mods to a specific mods subfolder). However, it is also a way "
"of creating patches for one's own game. A PCK file of this kind can fix the "
"content of a previously loaded PCK."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:123
msgid ""
"To opt out of this behavior, pass ``false`` as the second argument to :ref:"
"`ProjectSettings.load_resource_pack() "
"<class_ProjectSettings_method_load_resource_pack>`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:127
msgid ""
"For a C# project, you need to build the DLL and place it in the project "
"directory first. Then, before loading the resource pack, you need to load "
"its DLL as follows: ``Assembly.LoadFile(\"mod.dll\")``"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_pcks.rst:134
msgid ""
"This tutorial should illustrate how easy adding mods, patches or DLC to a "
"game is. The most important thing is to identify how one plans to distribute "
"future content for their game and develop a workflow that is customized for "
"that purpose. Godot should make that process smooth regardless of which "
"route a developer pursues."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:4
msgid "Feature tags"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:9
msgid ""
"Godot has a special system to tag availability of features. Each *feature* "
"is represented as a string, which can refer to many of the following:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:12
msgid "Platform name."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:13
msgid "Platform architecture (64-bit or 32-bit, x86 or ARM)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:14
msgid "Platform type (desktop, mobile, Web)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:15
msgid "Supported texture compression algorithms on the platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:16
msgid ""
"Whether a build is ``debug`` or ``release`` (``debug`` includes the editor)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:17
msgid ""
"Whether the project is running from the editor or a \"standalone\" binary."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:18
msgid "Many more things."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:20
msgid "Features can be queried at run-time from the singleton API by calling:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:28
msgid "Default features"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:30
msgid ""
"Here is a list of most feature tags in Godot. Keep in mind they are **case-"
"sensitive**:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:33
msgid "**Feature tag**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:35
msgid "**Android**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:35
msgid "Running on Android"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:37
msgid "**HTML5**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:37
msgid "Running on HTML5"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:39
msgid "**JavaScript**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:39
msgid ":ref:`JavaScript singleton <doc_javascript_eval>` is available"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:42
msgid "**OSX**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:42
msgid "Running on macOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:44
msgid "**iOS**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:44
msgid "Running on iOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:46
msgid "**UWP**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:46
msgid "Running on UWP"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:48
msgid "**Windows**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:48
msgid "Running on Windows"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:50
msgid "**X11**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:50
msgid "Running on X11 (Linux/BSD desktop)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:52
msgid "**Server**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:52
msgid "Running on the headless server platform"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:54
msgid "**debug**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:54
msgid "Running on a debug build (including the editor)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:56
msgid "**release**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:56
msgid "Running on a release build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:58
#, fuzzy
msgid "**editor**"
msgstr "**בשביל העורך:**"

#: ../../docs/getting_started/workflow/export/feature_tags.rst:58
msgid "Running on an editor build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:60
msgid "**standalone**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:60
msgid "Running on a non-editor build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:62
msgid "**64**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:62
msgid "Running on a 64-bit build (any architecture)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:64
msgid "**32**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:64
msgid "Running on a 32-bit build (any architecture)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:66
msgid "**x86_64**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:66
msgid "Running on a 64-bit x86 build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:68
msgid "**x86**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:68
msgid "Running on a 32-bit x86 build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:70
msgid "**arm64**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:70
msgid "Running on a 64-bit ARM build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:72
msgid "**arm**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:72
msgid "Running on a 32-bit ARM build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:74
msgid "**mobile**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:74
msgid "Host OS is a mobile platform"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:76
msgid "**pc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:76
msgid "Host OS is a PC platform (desktop/laptop)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:78
msgid "**web**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:78
msgid "Host OS is a Web browser"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:80
msgid "**etc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:80
msgid "Textures using ETC1 compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:82
msgid "**etc2**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:82
msgid "Textures using ETC2 compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:84
msgid "**s3tc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:84
msgid "Textures using S3TC (DXT/BC) compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:86
msgid "**pvrtc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:86
msgid "Textures using PVRTC compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:90
msgid "Custom features"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:92
msgid ""
"It is possible to add custom features to a build; use the relevant field in "
"the *export preset* used to generate it:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:98
msgid "Overriding project settings"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:100
msgid ""
"Features can be used to override specific configuration values in the "
"*Project Settings*. This allows you to better customize any configuration "
"when doing a build."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:103
msgid ""
"In the following example, a different icon is added for the demo build of "
"the game (which was customized in a special export preset, which, in turn, "
"includes only demo levels)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:108
msgid "After overriding, a new field is added for this specific configuration:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:113
msgid "Default overrides"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:115
msgid ""
"There are already a lot of settings that come with overrides by default; "
"they can be found in many sections of the project settings."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:121
msgid "Customizing the build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:123
msgid ""
"Feature tags can be used to customize a build process too, by writing a "
"custom **ExportPlugin**. They are also used to specify which shared library "
"is loaded and exported in **GDNative**."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_pc.rst:4
msgid "Exporting for PC"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_pc.rst:6
msgid ""
"The simplest way to distribute a game for PC is to copy the executables "
"(``godot.exe`` on Windows, ``godot`` on the rest), compress the folder and "
"send it to someone else. However, this is often not desired."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_pc.rst:10
msgid ""
"Godot offers a more elegant approach for PC distribution when using the "
"export system. When exporting for PC (Linux, Windows, macOS), the exporter "
"takes all the project files and creates a ``data.pck`` file. This file is "
"bundled with a specially optimized binary that is smaller, faster and does "
"not contain the editor and debugger."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:4
msgid "Exporting for iOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:6
msgid ""
"These are the steps to load a Godot project in Xcode. This allows you to "
"build and deploy to an iOS device, build a release for the App Store, and do "
"everything else you can normally do with Xcode."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:11
#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:23
#: ../../docs/tutorials/legal/complying_with_licenses.rst:15
#: ../../docs/development/compiling/compiling_for_windows.rst:9
#: ../../docs/development/compiling/compiling_for_x11.rst:9
#: ../../docs/development/compiling/compiling_for_osx.rst:9
#: ../../docs/development/compiling/compiling_for_android.rst:20
#: ../../docs/development/compiling/compiling_for_ios.rst:9
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:27
#: ../../docs/development/compiling/compiling_for_uwp.rst:9
#: ../../docs/development/compiling/compiling_for_web.rst:9
#: ../../docs/development/compiling/compiling_with_mono.rst:9
msgid "Requirements"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:13
msgid ""
"You must export for iOS from a computer running macOS with Xcode installed."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:14
msgid ""
"Download the Godot export templates. Use the Godot menu: Editor > Manage "
"Export Templates"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:17
msgid "Export a Godot project to Xcode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:19
msgid ""
"In the Godot editor, open the **Export** window from the **Project** menu. "
"When the Export window opens, click **Add..** and select **iOS**."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:22
msgid ""
"The following export options are required. Leaving any blank will cause the "
"exporter to throw an error:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:25
msgid ""
"In the **Application** category * **App Store Team ID** and (Bundle) "
"**Identifier**"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:27
msgid "Everything in the **Required Icons** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:28
msgid "Everything in the **Landscape Launch Screens** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:29
msgid "Everything in the **Portrait Launch Screens** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:31
msgid ""
"After you click **Export Project**, there are still two important options "
"left:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:33
msgid ""
"**Path** is an empty folder that will contain the exported Xcode project "
"files."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:34
msgid ""
"**File** will be the name of the Xcode project and several project specific "
"files and directories."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:38
msgid ""
"This tutorial uses **exported_xcode_project_name**, but you will use your "
"project's name. When you see **exported_xcode_project_name** in the "
"following steps, replace it with the name you used instead."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:42
msgid ""
"Avoid using spaces when you choose your **exported_xcode_project_name** as "
"this can lead to corruption in your XCode project file."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:45
msgid "When the export completes, the output folder should look like this:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:49
msgid ""
"Opening **exported_xcode_project_name.xcodeproj** lets you build and deploy "
"like any other iOS app."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:53
msgid "Active development considerations"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:55
msgid ""
"The above method creates an exported project that you can build for release, "
"but you have to re-export every time you make a change in Godot."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:58
msgid ""
"While developing, you can speed this process up by linking your Godot "
"project files directly into your app."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:61
msgid "In the following example:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:63
msgid ""
"**exported_xcode_project_name** is the name of the exported iOS application "
"(as above)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:64
msgid "**godot_project_to_export** is the name of the Godot project."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:67
msgid "Steps to link a Godot project folder to Xcode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:69
msgid "Start from an exported iOS project (follow the steps above)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:70
msgid "In Finder, drag the Godot project folder into the Xcode file browser."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:74
msgid ""
"3. In the dialog, make sure **Create folder references** is selected. This "
"means you will be able to continue to edit your Godot project in its current "
"location."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:79
msgid "See the **godot_project_to_export** folder in the Xcode file browser."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:80
msgid "Delete **exported_xcode_project_name.pck** from the Xcode project."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:84
msgid ""
"6. Open **exported_xcode_project_name-Info.plist** and add a string property "
"named **godot_path** (this is the real key name) with a value "
"**godot_project_to_export** (this is the name of your project)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:90
msgid ""
"That's it! You can now edit your project in the Godot editor and build it in "
"Xcode when you want to run it on a device."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:94
#: ../../docs/tutorials/platform/services_for_ios.rst:4
msgid "Services for iOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:96
msgid ""
"Special iOS services can be used in Godot. Check out the :ref:"
"`doc_services_for_ios` page."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:4
msgid "Exporting for Universal Windows Platform"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:6
msgid ""
"There's no extra requirement to export an ``.appx`` package that can be "
"installed as a Windows App or submitted to the Windows Store. Exporting UWP "
"packages also works from any platform, not only from Windows."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:10
msgid ""
"However, if you want to install and run the app, you need to sign it with a "
"trusted signature. Godot supports automatic signing of packages with "
"external tools."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:14
msgid ""
"Also, make sure the Publisher Name you set when exporting the package "
"matches the name used on the certificate."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:18
msgid "Limitations on Xbox One"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:20
msgid ""
"As described in the `UWP documentation <https://docs.microsoft.com/en-us/"
"windows/uwp/xbox-apps/system-resource-allocation>`__:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:25
msgid "Submitted as an \"App\""
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:23
msgid "available memory is 1GB"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:24
msgid "share of 2-4 CPU cores"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:25
msgid "shared access of GPU power (45%)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:30
msgid ""
"Submitted as a \"Game\" (through `Xbox Live Creators Program <https://www."
"xbox.com/en-US/developers/creators-program>`__)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:28
msgid "available memory is 5GB"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:29
msgid "4 exclusive CPU cores and 2 shared CPU cores"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:30
msgid "exclusive access to GPU power (100%)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:32
msgid ""
"Exceeding these memory limitations will cause allocation failures and the "
"application will crash."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:35
msgid "Creating a signing certificate"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:37
msgid ""
"This requires the ``MakeCert.exe`` and ``Pvk2Pfx.exe`` tools, which come "
"with the Windows SDK. If you use Visual Studio, you can open one of its "
"Developer Prompts, since it comes with these tools and they can be located "
"in the path."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:41
msgid ""
"You can get more detailed instructions from `Microsoft's documentation "
"<https://msdn.microsoft.com/en-us/library/windows/desktop/jj835832(v=vs.85)."
"aspx>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:44
msgid "First, run ``MakeCert`` to create a private key::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:48
msgid ""
"Where ``publisherName`` matches the Publisher Name of your package and "
"``expirationDate`` is in the ``mm/dd/yyyy`` format."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:51
msgid ""
"Next, create a Personal Information Exchange (.pfx) file using ``Pvk2Pfx."
"exe``::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:55
msgid ""
"If you don't specify a password with ``/po`` argument, the PFX will have the "
"same password as the private key."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:58
msgid ""
"You will also need to trust this certificate in order to be able to install "
"your app. Open the Command Prompt as Administrator and run the following "
"command::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:64
#, fuzzy
msgid "Setting up automatic signing"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:66
msgid ""
"To setup automatic signing on export you need to go to Editor Settings > "
"Export > Uwp. From there you need to click on the folder for ``Signtool``, "
"and navigate to the ``SignTool.exe`` file on your computer."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:72
msgid ""
"After setting that up close the editor settings, go to Project > Export, and "
"select the UWP preset. Under the ``Signing`` options click on the folder "
"next to ``Certificate`` and go to the certificate file. Then enter the "
"pfxPassword in the password field."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:79
msgid "Your project will now be automatically signed on export."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:81
msgid ""
"If you want to sign an exported app manually run ``SignTool.exe`` and use "
"the following command."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:84
msgid "SignTool sign /fd SHA256 /a /f MyKey.pfx /p pfxPassword package.appx"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:87
msgid "Installing the package"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:89
msgid ""
"As of the Windows 10 Anniversary Update, you are able to install packages "
"simply by double clicking the ``.appx`` file from Windows Explorer."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:92
msgid ""
"It's also possible to install by using the ``Add-AppxPackage`` PowerShell "
"cmdlet."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:94
msgid ""
"If you want to update your already installed app, you must update the "
"version number on the new package or first uninstall the previous package."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:4
msgid "Exporting for Android"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:6
msgid ""
"Exporting for Android has fewer requirements than compiling Godot for it. "
"The following steps detail what is needed to setup the SDK and the engine."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:10
msgid "Download the Android SDK"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:12
msgid ""
"Download and install the Android SDK from `developer.android.com <https://"
"developer.android.com/studio/>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:15
msgid ""
"If you install Android Studio, you need to run it once to complete the SDK "
"setup."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:18
msgid "Install OpenJDK 8"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:20
msgid ""
"Download and install  `OpenJDK 8 <https://adoptopenjdk.net/index.html?"
"variant=openjdk8&jvmVariant=hotspot>`__, newer versions do not work."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:24
msgid "Create a debug.keystore"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:26
msgid ""
"Android needs a debug keystore file to install to devices and distribute non-"
"release APKs. If you have used the SDK before and have built projects, ant "
"or eclipse probably generated one for you (on Linux and macOS, you can find "
"it in the ``~/.android`` directory)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:31
msgid ""
"If you can't find it or need to generate one, the keytool command from the "
"JDK can be used for this purpose::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:36
msgid ""
"This will create a ``debug.keystore`` file in your current directory. You "
"should move it to a memorable location such as ``%USERPROFILE%\\.android"
"\\``, because you will need its location in a later step. For more "
"information on ``keytool`` usage, see `this Q&A article <https://godotengine."
"org/qa/21349/jdk-android-file-missing>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:39
msgid "Make sure you have adb"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:41
msgid ""
"Android Debug Bridge (``adb``) is the command line tool used to communicate "
"with Android devices. It's installed with the SDK, but you may need to "
"install one (any) of the Android API levels for it to be installed in the "
"SDK directory."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:46
msgid "Setting it up in Godot"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:48
msgid ""
"Enter the Editor Settings screen. This screen contains the editor settings "
"for the user account in the computer (it's independent of the project)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:54
msgid "Scroll down to the section where the Android settings are located:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:58
msgid "In that screen, the path to 3 files needs to be set:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:60
msgid ""
"The ``adb`` executable (``adb.exe`` on Windows) - It can usually be found at "
"``%LOCALAPPDATA%\\Android\\Sdk\\platform-tools\\adb.exe``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:63
msgid ""
"The ``jarsigner`` executable (from JDK 6 or 8) - On Windows, OpenJDK "
"installs to a dir like ``%PROGRAMFILES%\\ojdkbuild\\java-1.8.0-"
"openjdk-1.8.0.232-2\\bin``. On Linux, it typically installs to a dir like ``/"
"usr/bin/jarsigner``. The exact path may vary depending on the OpenJDK update "
"you've installed and your machine's operating system."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:66
msgid ""
"The debug ``.keystore`` file - It can be found in the folder where you put "
"the ``debug.keystore`` file you created above."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:69
msgid "Once that is configured, everything is ready to export to Android!"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:72
msgid "Providing launcher icons"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:74
msgid ""
"Launcher icons are used by Android launcher apps to represent your "
"application to users. Godot only requires high-resolution icons (for "
"``xxxhdpi`` density screens) and will automatically generate lower-"
"resolution variants."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:76
#, fuzzy
msgid "There are two types of icons required by Godot:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:78
msgid ""
"**Main Icon:** The \"classic\" icon. This will be used on all Android "
"versions up to Android 8 (Oreo), exclusive. Must be at least 192×192 px."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:79
msgid ""
"**Adaptive Icons:** Starting from Android 8 (inclusive), `Adaptive Icons "
"<https://developer.android.com/guide/practices/ui_guidelines/"
"icon_design_adaptive>`_ were introduced. Applications will need to include "
"separate background and foreground icons to have a native look. The user's "
"launcher application will control the icon's animation and masking. Must be "
"at least 432×432 px."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:81
msgid ""
"It's important to adhere to some rules when designing adaptive icons. "
"`Google Design has provided a nice article <https://medium.com/google-design/"
"designing-adaptive-icons-515af294c783>`_ that helps to understand those "
"rules and some of the capabilities of adaptive icons."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:83
msgid ""
"The most important adaptive icon design rule is to have your icon critical "
"elements inside the safe zone: a centered circle with a diameter of 66dp "
"(264 pixels on ``xxxhdpi``) to avoid being clipped by the launcher."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:85
msgid ""
"If you don't provide some of the requested icons, Godot will replace them "
"using a fallback chain, trying the next in line when the current one fails:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:87
msgid ""
"**Main Icon:** Provided main icon -> Project icon -> Default Godot main icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:88
msgid ""
"**Adaptive Icon Foreground:** Provided foreground icon -> Provided main icon "
"-> Project icon -> Default Godot foreground icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:89
msgid ""
"**Adaptive Icon Background:** Provided background icon -> Default Godot "
"background icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:91
msgid ""
"It's highly recommended to provide all requested icons, and at least with "
"the specified resolutions. Only this way your application will look great on "
"all Android devices and versions."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:94
msgid "Exporting for Google Play Store"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:96
msgid ""
"Uploading an APK to Google's Play Store requires you to sign using a non-"
"debug keystore file; such file can be generated like this:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:103
msgid ""
"This keystore and key are used to verify your developer identity, remember "
"the password and keep it in a safe place! Use Google's Android Developer "
"guides to learn more about `APK signing <https://developer.android.com/"
"studio/publish/app-signing>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:106
msgid "Now fill in the following forms in your Android Export Presets:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:110
msgid "**Release:** Enter the path to the keystore file you just generated."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:111
msgid "**Release User:** Replace with the key alias."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:112
msgid ""
"**Release Password:** Key password. Note that the keystore password and the "
"key password currently have to be the same."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:114
msgid ""
"**Your export_presets.cfg file now contains sensitive information.** If you "
"use a version control system, you should remove it from public repositories "
"and add it to your ``.gitignore`` file or equivalent."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:118
msgid ""
"Don't forget to uncheck the **Export With Debug** checkbox while choosing "
"the APK's name."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:123
msgid "Optimizing the APK size"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:125
msgid ""
"By default, the APK will contain native libraries for both ARMv7 and ARMv8 "
"architectures. This increases its size significantly. To create a smaller "
"APK, uncheck either **Armeabi-v 7a** or **Arm 64 -v 8a** in your project's "
"Android export preset. This will create an APK that only contains a library "
"for a single architecture. Note that applications targeting ARMv7 can also "
"run on ARMv8 devices, but the opposite is not true."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:132
msgid ""
"Since August 2019, Google Play requires all applications to be available in "
"64-bit form. This means you cannot upload an APK that contains *just* an "
"ARMv7 library. To solve this, you can upload several APKs to Google Play "
"using its `Multiple APK support <https://developer.android.com/google/play/"
"publishing/multiple-apks>`__. Each APK should target a single architecture; "
"creating an APK for ARMv7 and ARMv8 is usually sufficient to cover most "
"devices in use today."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:139
msgid ""
"You can optimize the size further by compiling an Android export template "
"with only the features you need. See :ref:`doc_optimizing_for_size` for more "
"information."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:4
msgid "Exporting for the Web"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:6
msgid ""
"HTML5 export allows publishing games made in Godot Engine to the browser. "
"This requires support for `WebAssembly <https://webassembly.org/>`__ and "
"`WebGL <https://www.khronos.org/webgl/>`__ in the user's browser."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:11
msgid ""
"Use the browser-integrated developer console, usually opened with :kbd:"
"`F12`, to view **debug information** like JavaScript, engine, and WebGL "
"errors."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:15
msgid ""
"Many browsers, including Firefox and Chromium-based browsers, will not load "
"exported projects when **opened locally** per ``file://`` protocol. To get "
"around this, use a local server."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:19
msgid ""
"Python offers an easy method to start a local server. Use ``python -m http."
"server`` with Python 3 to serve the current working directory at ``http://"
"localhost:8000``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:23
msgid ""
"`There are significant bugs when running HTML5 projects on iOS <https://"
"github.com/godotengine/godot/issues/26554>`__ (regardless of the browser). "
"We recommend using :ref:`iOS' native export functionality "
"<doc_exporting_for_ios>` instead, as it will also result in better "
"performance."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:29
msgid "WebGL 2"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:31
msgid ""
"Until the *OpenGL ES 3* renderer is removed from Godot in favor of *Vulkan*, "
"HTML5 export uses *WebGL 2* when the *GLES3* option is selected."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:34
msgid ""
"Using WebGL 2 is not recommended due to its expected removal from Godot "
"without replacement."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:37
msgid ""
"WebGL 2 is not supported in all browsers. **Firefox** and **Chromium** "
"(Chrome, Opera) are the most popular supported browsers, **Safari** and "
"**Edge** do not work. On **iOS**, all browsers are based on WebKit (i.e. "
"Safari), so they will also not work."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:42
msgid ""
"Godot's WebGL 2 renderer has issues with 3D and is no longer maintained."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:45
msgid "Limitations"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:47
msgid ""
"For security and privacy reasons, many features that work effortlessly on "
"native platforms are more complicated on the web platform. Following is a "
"list of limitations you should be aware of when porting a Godot game to the "
"web."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:52
msgid "Using cookies for data persistence"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:54
msgid ""
"Users must **allow cookies** (specifically IndexedDB) if persistence of the "
"``user://`` file system is desired. When playing a game presented in an "
"``iframe``, **third-party** cookies must also be enabled. Incognito/private "
"browsing mode also prevents persistence."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:59
msgid ""
"The method ``OS.is_userfs_persistent()`` can be used to check if the "
"``user://`` file system is persistent, but can give false positives in some "
"cases."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:64
msgid "Full screen and mouse capture"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:66
msgid ""
"Browsers do not allow arbitrarily **entering full screen**. The same goes "
"for **capturing the cursor**. Instead, these actions have to occur as a "
"response to a JavaScript input event. In Godot, this means entering full "
"screen from within a pressed input event callback such as ``_input`` or "
"``_unhandled_input``. Querying the :ref:`class_Input` singleton is not "
"sufficient, the relevant input event must currently be active."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:73
msgid ""
"For the same reason, the full screen project setting doesn't work unless the "
"engine is started from within a valid input event handler. This requires :"
"ref:`customization of the HTML page <doc_customizing_html5_shell>`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:78
msgid "Audio autoplay"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:80
msgid ""
"Chrome restricts how websites may play audio. It may be necessary for the "
"player to click or tap or press a key to enable audio."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:83
msgid ""
"Google offers additional information about their `Web Audio autoplay "
"policies <https://sites.google.com/a/chromium.org/dev/audio-video/"
"autoplay>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:87
msgid ":ref:`class_HTTPClient` and :ref:`class_HTTPRequest`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:89
msgid "The HTTP classes have several restrictions on the HTML5 platform:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:91
msgid "Accessing or changing the ``StreamPeer`` is not possible"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:92
msgid "Threaded/Blocking mode is not available"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:93
msgid ""
"Cannot progress more than once per frame, so polling in a loop will freeze"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:94
msgid "No chunked responses"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:95
msgid "Host verification cannot be disabled"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:96
msgid ""
"Subject to `same-origin policy <https://developer.mozilla.org/en-US/docs/Web/"
"Security/Same-origin_policy>`__"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:99
msgid "Exported ``.html`` file must not be reused"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:101
msgid ""
"Each project must generate their own HTML file. On export, several text "
"placeholders are replaced in the **generated HTML file** specifically for "
"the given export options. Any direct modifications to the **generated HTML "
"file** will be lost in future exports. To customize the generated file, see :"
"ref:`doc_customizing_html5_shell`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:105
msgid "Boot splash is not displayed"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:107
msgid ""
"The default HTML page does not display the boot splash while loading. "
"However, the image is exported as a PNG file, so :ref:`custom HTML pages "
"<doc_customizing_html5_shell>` can display it."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:112
#, fuzzy
msgid "Shader language limitations"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:114
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:374
msgid ""
"When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0 "
"doesn't support dynamic loops, so shaders using those won't work there."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:118
msgid "Unimplemented functionality"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:120
msgid ""
"The following functionality is currently unavailable on the HTML5 platform:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:122
#: ../../docs/tutorials/threads/using_multiple_threads.rst:7
#: ../../docs/tutorials/threads/thread_safe_apis.rst:7
msgid "Threads"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:123
#: ../../docs/tutorials/plugins/gdnative/index.rst:2
msgid "GDNative"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:125
msgid "Clipboard synchronization between engine and operating system"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:126
msgid ""
"Networking other than :ref:`class_HTTPClient` and :ref:"
"`class_WebSocketClient`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:128
msgid ""
"Check the `list of open HTML5 issues on GitHub <https://github.com/"
"godotengine/godot/issues?q=is:open+is:issue+label:platform:html5>`__ to see "
"if the functionality you're interested in has an issue yet. If not, open one "
"to communicate your interest."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:134
msgid "Serving the files"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:136
msgid ""
"Exporting for the web generates several files to be served from a web "
"server, including a default HTML page for presentation. A custom HTML file "
"can be used, see :ref:`doc_customizing_html5_shell`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:140
msgid ""
"The generated ``.html`` file can be used as ``DirectoryIndex`` in Apache "
"servers and can be renamed to e.g. ``index.html`` at any time, its name is "
"never depended on by default."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:144
msgid ""
"The HTML page draws the game at maximum size within the browser window. This "
"way it can be inserted into an ``<iframe>`` with the game's size, as is "
"common on most web game hosting sites."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:148
msgid ""
"The other exported files are served as they are, next to the ``.html`` file, "
"names unchanged. The ``.wasm`` file is a binary WebAssembly module "
"implementing the engine. The ``.pck`` file is the Godot main pack containing "
"your game. The ``.js`` file contains start-up code and is used by the ``."
"html`` file to access the engine. The ``.png`` file contains the boot splash "
"image. It is not used in the default HTML page, but is included for :ref:"
"`custom HTML pages <doc_customizing_html5_shell>`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:156
msgid ""
"The ``.pck`` file is binary, usually delivered with the MIME-type :mimetype:"
"`application/octet-stream`. The ``.wasm`` file is delivered as :mimetype:"
"`application/wasm`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:160
msgid ""
"Delivering the WebAssembly module (``.wasm``) with a MIME-type other than :"
"mimetype:`application/wasm` can prevent some start-up optimizations."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:164
msgid ""
"Delivering the files with server-side compression is recommended especially "
"for the ``.pck`` and ``.wasm`` files, which are usually large in size. The "
"WebAssembly module compresses particularly well, down to around a quarter of "
"its original size with gzip compression."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:170
msgid "Export options"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:172
msgid ""
"If a runnable web export template is available, a button appears between the "
"*Stop scene* and *Play edited Scene* buttons in the editor to quickly open "
"the game in the default browser for testing."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:176
msgid ""
"If a path to a **Custom HTML shell** file is given, it will be used instead "
"of the default HTML page. See :ref:`doc_customizing_html5_shell`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:179
msgid ""
"**Head Include** is appended into the ``<head>`` element of the generated "
"HTML page. This allows to, for example, load webfonts and third-party "
"JavaScript APIs, include CSS, or run JavaScript code."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:186
msgid "Calling JavaScript from script"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:188
msgid ""
"In web builds, the ``JavaScript`` singleton is implemented. It offers a "
"single method called ``eval`` that works similarly to the JavaScript "
"function of the same name. It takes a string as an argument and executes it "
"as JavaScript code. This allows interacting with the browser in ways not "
"possible with script languages integrated into Godot."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:199
msgid ""
"The value of the last JavaScript statement is converted to a GDScript value "
"and returned by ``eval()`` under certain circumstances:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:202
msgid "JavaScript ``number`` is returned as GDScript :ref:`class_float`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:203
msgid "JavaScript ``boolean`` is returned as GDScript :ref:`class_bool`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:204
msgid "JavaScript ``string`` is returned as GDScript :ref:`class_String`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:205
msgid ""
"JavaScript ``ArrayBuffer``, ``TypedArray`` and ``DataView`` are returned as "
"GDScript :ref:`class_PoolByteArray`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:214
msgid "Any other JavaScript value is returned as ``null``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:216
msgid ""
"HTML5 export templates may be built without support for the singleton. With "
"such templates, and on platforms other than HTML5, calling ``JavaScript."
"eval`` will also return ``null``.  The availability of the singleton can be "
"checked with the ``JavaScript`` :ref:`feature tag <doc_feature_tags>`::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:229
msgid ""
"GDScript's multi-line strings, surrounded by 3 quotes ``\"\"\"`` as in "
"``my_func3()`` above, are useful to keep JavaScript code readable."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:232
msgid ""
"The ``eval`` method also accepts a second, optional Boolean argument, which "
"specifies whether to execute the code in the global execution context, "
"defaulting to ``false`` to prevent polluting the global namespace::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:4
#: ../../docs/tutorials/networking/high_level_multiplayer.rst:425
msgid "Exporting for dedicated servers"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:6
msgid ""
"If you want to run a dedicated server for your project on a machine that "
"doesn't have a GPU or display server available, you'll need to use a server "
"build of Godot."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:10
#, fuzzy
msgid "Platform support"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:12
msgid ""
"**Linux:** `Download an official Linux server binary <https://godotengine."
"org/download/server>`__. To compile a server binary from source, follow "
"instructions in :ref:`doc_compiling_for_x11`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:15
msgid ""
"**macOS:** :ref:`Compile a server binary from source for macOS "
"<doc_compiling_for_osx>`."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:16
msgid ""
"**Windows:** There is no dedicated server build for Windows yet. As an "
"alternative, you can use the ``--no-window`` command-line argument to "
"prevent Godot from spawning a window."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:20
msgid ""
"If your project uses C#, you'll have to use a Mono-enabled server binary."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:23
msgid "\"Headless\" versus \"server\" binaries"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:25
msgid ""
"The `server download page <https://godotengine.org/download/server>`__ "
"offers two kinds of binaries with several differences."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:28
msgid ""
"**Server:** Use this one for running dedicated servers. It does not contain "
"editor functionality, and is therefore smaller and more optimized."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:31
msgid ""
"**Headless:** This binary contains editor functionality and is intended to "
"be used for exporting projects. This binary *can* be used to run dedicated "
"servers, but it's not recommended as it's larger and less optimized."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:36
msgid "Exporting a PCK file"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:38
msgid ""
"Once you've downloaded a server binary, you should export a PCK file "
"containing your project data. It's recommended to create a Linux export "
"preset for this purpose. After creating the export preset, click **Export "
"PCK/ZIP** at the bottom of the Export dialog then choose a destination path."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:43
msgid ""
"The **Export With Debug** checkbox in the file dialog has no bearing on the "
"final PCK file, so you can leave it as-is."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:46
msgid "See :ref:`doc_exporting_projects` for more information."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:50
msgid ""
"The PCK file will include resources not normally needed by the server, such "
"as textures and sounds. This means the PCK file will be larger than it could "
"possibly be. Support for stripping unneeded resources from a PCK for server "
"usage is planned in a future Godot release."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:55
msgid ""
"On the bright side, this allows the same PCK file to be used both by a "
"client and dedicated server build. This can be useful if you want to ship a "
"single archive that can be used both as a client and dedicated server."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:60
#, fuzzy
msgid "Preparing the server distribution"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:62
msgid ""
"After downloading or compiling a server binary, you should now place it in "
"the same folder as the PCK file you've exported. The server binary should "
"have the same name as the PCK (excluding the extension). This lets Godot "
"detect and use the PCK file automatically. If you want to start a server "
"with a PCK that has a different name, you can specify the path to the PCK "
"file using the ``--main-pack`` command-line argument::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:72
#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:849
msgid "Next steps"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:74
msgid ""
"On Linux, to make your dedicated server restart after a crash or system "
"reboot, you can `create a systemd service <https://medium.com/@benmorel/"
"creating-a-linux-service-with-systemd-611b5c8b91d6>`__. This also lets you "
"view server logs in a more convenient fashion, with automatic log rotation "
"provided by systemd."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_dedicated_servers.rst:80
msgid ""
"If you have experience with containers, you could also look into wrapping "
"your dedicated server in a `Docker <https://www.docker.com/>`__ container. "
"This way, it can be used more easily in an automatic scaling setup (which is "
"outside the scope of this tutorial)."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:4
msgid "One-click deploy"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:7
msgid "Sounds good, what is it?"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:9
msgid ""
"This feature will pop up automatically once a platform is properly "
"configured and a supported device is connected to the computer. Since things "
"can go wrong at many levels (platform may not be configured correctly, SDK "
"may be incorrectly installed, device may be improperly configured, etc.), "
"it's good to let the user know that it exists."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:15
msgid ""
"Some platforms (at the time of this writing, only Android) can detect when a "
"USB device is connected to the computer, and offer the user to automatically "
"export, install and run the project (in debug mode) on the device. This "
"feature is called, in industry buzzwords, \"One-Click Deploy\"."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:21
msgid "Steps for one-click deploy"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:23
msgid "Configure target platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:24
msgid ""
"Configure device (make sure it's in developer mode, likes the computer, USB "
"cable is plugged, USB is recognized, etc.)."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:26
msgid "Connect the device..."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:27
msgid "And voilà!"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:31
msgid "Click once... and deploy!"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:4
msgid "Custom builds for Android"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:6
msgid ""
"Godot provides the option to use custom build Android templates. Instead of "
"using the already pre-built template that ships with Godot, an actual "
"Android Java project gets installed into your project folder. Godot will "
"then build it and use it as an export template every time you export the "
"project."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:11
msgid "There are some reasons why you may want to do this:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:13
msgid "Modify the project before it's built."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:14
msgid "Add external SDKs that build with your project."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:16
msgid ""
"Configuring the custom build is a more or less straightforward process, but "
"it may take a while to get used to how the Android SDK works."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:19
msgid ""
"Instructions will be provided as detailed as possible to do this process."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:22
msgid "Set up the custom build environment"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:24
msgid "Go to the Project menu, and install the *Custom Build* template:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:28
msgid ""
"Make sure export templates are downloaded. If not, this menu will help you "
"download them."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:31
msgid ""
"This will create an Gradle-based Android project in ``res://android/build`` "
"and place a ``.gdignore`` file in ``res://android`` so the Godot filesystem "
"ignores this folder. Editing these files is not needed unless you want to :"
"ref:`create your own add-ons<doc_android_plugin>`, or you really need to "
"modify the project."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:37
msgid "Install the Android SDK (command-line version)"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:39
msgid ""
"These are the steps for installing the Android SDK using command line. The "
"advantage of this approach is the simplicity and small download/install "
"size. It can be more challenging though. The Android Studio approach is "
"easier, but it requires downloading and installing Android Studio (which may "
"require more than 1 GB of storage)."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:46
msgid "Install a JDK"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:48
msgid ""
"The Android SDK doesn't come with Java, so it needs to be installed "
"manually. You need to install a Java SDK (**not** just the runtime or JRE). "
"`OpenJDK 8 <https://adoptopenjdk.net/index.html>`__ is required, newer "
"versions won't work."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:54
msgid "Download the command-line tools"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:56
msgid ""
"Go to the `Android Studio download page <https://developer.android.com/"
"studio/#command-tools>`_. To save disk space, you don't want the full IDE, "
"so don't download it."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:61
msgid ""
"If you do want Android Studio, read further down for instructions for doing "
"the same using Android Studio."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:64
msgid ""
"Look on that page for the *Command line tools only* section. Currently, they "
"are listed under *Download Options*. Scroll down a bit until you see them."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:67
msgid ""
"Download the ZIP file for your platform, there will be a single ``tools`` "
"folder inside:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:72
msgid ""
"This may appear a little confusing, but be sure to follow these instructions "
"carefully:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:75
msgid ""
"Create a new folder anywhere you want named ``android-sdk`` (it **must** be "
"an empty directory). On Windows, the following path is usually good enough:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:84
msgid ""
"If you already have an android-sdk folder, normally located in ``"
"%LOCALAPPDATA%\\Android\\Sdk``, then use this folder instead of creating an "
"empty ``android-sdk`` folder."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:87
msgid ""
"Unzip the Android SDK ZIP file into the ``android-sdk`` folder. This folder "
"should now contain the unzipped folder called ``tools``. Rename ``tools`` to "
"``latest``. Finally, create an empty folder named ``cmdline-tools`` and "
"place ``latest`` into it. Your final directory structure should look like "
"this :"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:99
msgid ""
"We need to setup the directory structure this way for the sdkmanager (inside "
"the bin folder) to work."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:102
#, fuzzy
msgid "Accepting the licenses"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:104
msgid ""
"To be able to use the Android SDK tools, Google requires you to accept its "
"licenses."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:107
msgid ""
"To do this, the ``sdkmanager`` must be executed from the command line with a "
"special argument. Navigate to the ``tools/bin`` directory inside the SDK "
"folder (instructions provided for Windows users, as Linux and macOS users "
"are expected to understand how command line navigation works):"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:114
msgid "Then open a command line window:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:118
msgid "In there, run ``sdkmanager --licenses``:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:122
msgid ""
"This will ask you to accept several licenses, just write ``y`` and press :"
"kbd:`Enter` on every of them until it's done."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:125
msgid ""
"Afterwards, install the platform tools (this is required to install ``adb``):"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:129
msgid ""
"If you get an error saying ``Warning: Could not create settings``, try ``./"
"sdkmanager --sdk_root=../../ --licenses`` or ``./sdkmanager --"
"sdk_root=../../ platform-tools``. These must be executed inside the ``/tools/"
"bin/`` folder because the path for ``--sdk_root`` is relative."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:132
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:216
#, fuzzy
msgid "Generating the keystore"
msgstr "יצירת תוכן"

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:134
msgid ""
"Once the *platform tools* are installed, the last step is to generate a "
"debug keystore (this is needed to build). Go up two folders by writing:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:141
msgid "(or open a new shell in the ``android-sdk`` folder)."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:143
msgid ""
"And you need to input the following line (on Linux and macOS, this should "
"work out of the box, for Windows there are further instructions below):"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:150
msgid ""
"On Windows, the full path to Java should be provided. You need to add ``&`` "
"at the beginning of the line if you use PowerShell; it's not needed for the "
"regular ``cmd.exe`` console."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:154
msgid ""
"To make it clearer, here is an capture of a line that works on PowerShell "
"(by adding ``&`` and the full Java path before ``keytool.exe``). Again, keep "
"in mind that you need Java installed:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:160
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:171
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:243
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:254
msgid "(right-click and open the image in a new tab if this appears too small)"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:164
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:247
msgid "Setting up Godot"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:166
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:249
msgid ""
"Go to the **Editor Settings** and set up a few fields in **Export > "
"Android**. Make sure they look like the following:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:173
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:256
msgid ""
"As it can be seen, most paths are inside either the ``android-sdk`` folder "
"you originally created, or inside the Java install. For Linux and macOS "
"users, ``jarsigner`` is often located in ``/usr/bin``."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:177
#: ../../docs/getting_started/workflow/export/android_custom_build.rst:260
msgid "With this, you should be all set."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:181
msgid "Install the Android SDK (Android Studio)"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:183
msgid ""
"If you just finished installing the SDK via the command-line tools, feel "
"free to skip this section entirely. The Android Studio path is easier, but "
"it takes up more disk space. It's also useful if you plan to develop Godot "
"for Android (modify the Java source code) or if you plan to develop add-ons."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:189
msgid "Download and install Android Studio"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:191
msgid ""
"Download the latest version of Android Studio. When installing, pay "
"attention to where the *android-sdk* directory is created."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:196
msgid ""
"This is funny, the path it proposes by default contains whitespace (and "
"complains about it). It must be changed."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:198
msgid ""
"In any case, it's better to select a different path inside your user "
"folders. The recommended one is usually:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:205
msgid ""
"Replace *yourusername* by your actual user name. Once it's correct, select "
"from the list above in the same screen:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:208
#, fuzzy
msgid "Android SDK"
msgstr "Android"

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:209
msgid "Android SDK Platform"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:211
msgid ""
"The rest are not needed, because the build system will fetch them itself. "
"After selecting them, go on with the installation."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:218
msgid ""
"Go to the folder where you installed ``android-sdk`` in the previous step, "
"use File Explorer and open a command line tool there:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:223
msgid ""
"The actual command line to type is the following. On Linux and macOS, it "
"should work out of the box, but on Windows, it needs additional details "
"(keep reading afterwards)."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:231
msgid ""
"On Windows, the full path to Java should be provided (and ``&`` needs to be "
"added at the beginning on the line if you use PowerShell, it's not needed "
"for the regular ``cmd.exe`` console). Don't worry, at least by using Android "
"Studio on Windows, Java comes bundled with it."
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:236
msgid ""
"To make it clearer, here is a screen capture of a line that works on "
"PowerShell (by adding ``&`` and the full Java Path to ``keytool.exe``; "
"remove ``&`` if you use ``cmd.exe``). It uses a path to the Java version "
"that comes with Android Studio:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:264
msgid "Enabling the custom build and exporting"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:266
msgid ""
"When setting up the Android project in the **Project > Export** dialog, "
"**Custom Build** needs to be enabled:"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:271
msgid ""
"From now on, attempting to export the project or one-click deploy will call "
"the `Gradle <https://gradle.org/>`__ build system to generate fresh "
"templates (this window will appear every time):"
msgstr ""

#: ../../docs/getting_started/workflow/export/android_custom_build.rst:277
msgid ""
"The templates built will be used automatically afterwards, so no further "
"configuration is needed."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:4
msgid "Changing application icon for Windows"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:6
msgid ""
"By default, the exported project's icon will be the Godot icon. You will "
"most likely want to change that for your project. There are two types of "
"icons that can be changed on Windows: the file icon and the taskbar icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:11
msgid "Changing the taskbar icon"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:13
msgid ""
"The taskbar icon is the icon that shows up on the taskbar when your project "
"is running."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:18
msgid ""
"To change the taskbar icon, go to **Project → Project Settings → Application "
"→ Config → Icon**. Click on the folder icon and select your desired icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:22
msgid "This is also the icon that gets displayed in the Godot project list."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:27
msgid "Changing the file icon"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:29
msgid ""
"The file icon is the icon of the executable that you click on to start the "
"project."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:34
msgid ""
"Before selecting it in the export options, you will need to install an extra "
"tool called **rcedit**. You can download it `here <https://github.com/"
"electron/rcedit/releases>`_."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:38
msgid ""
"After downloading, you need to tell Godot the path to the rcedit executable "
"on your computer. Go to **Editor → Editor Settings → Export → Windows**. "
"Click on the folder icon for the **rcedit** entry. Navigate to and select "
"the rcedit executable."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:44
msgid ""
"Linux and macOS users will also need to install `WINE <https://www.winehq."
"org/>`_ to use rcedit."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:49
msgid ""
"You should now have everything in place to change the file icon. To do that, "
"you will need to specify the icon when exporting. Go to **Project → "
"Export**. Assuming you have already created a Windows Desktop preset, select "
"your icon in ICO format in the **Application → Icon** field."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:55
msgid ""
"You can use software such as GIMP to export an ICO image. For more "
"information, please refer to `this tutorial <http://skyboygames.com/easily-"
"create-a-windows-app-icon-with-gimp/>`_."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:62
msgid "Testing the result"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:64
msgid ""
"You can now export the project. If it worked correctly, you should see this:"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:69
msgid "ICO file requirements"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:71
msgid ""
"Regardless of which program you use to create your `ICO file <https://en."
"wikipedia.org/wiki/ICO_(file_format)>`_, there are some requirements to "
"ensure the icon (and your executable) works on Windows."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:75
msgid ""
"This is a bit tricky, as can be seen in the following Stack Overflow "
"threads: `one <https://stackoverflow.com/q/3236115/>`_, `two <https://"
"stackoverflow.com/q/40749785/>`_."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:79
msgid ""
"Your ICO file should at least contain icons in the following resolutions: "
"16×16, 48×48 and 256×256."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:82
msgid ""
"If you want to fully support high-DPI screens, this is the full list of "
"supported icon sizes on Windows 10: 16, 20, 24, 28, 30, 31, 32, 40, 42, 47, "
"48, 56, 60, 63, 84 and one larger than 255 pixels (such as 256, 512 or 1024)."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:87
msgid ""
"It is also possible to convert a PNG image to an hiDPI-friendly ICO file "
"using this `ImageMagick <https://www.imagemagick.org/>`_ command:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:6
msgid ""
"This series is a collection of best practices to help you work efficiently "
"with Godot."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:9
msgid ""
"Godot allows for a great amount of flexibility in how you structure a "
"project's codebase and break it down into scenes. Each approach has its own "
"pros and cons, and they can be hard to weigh until you've worked with the "
"engine for long enough."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:13
msgid ""
"There are always many ways to structure your code and solve specific "
"programming problems. It would be impossible to cover them all here."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:16
msgid ""
"That is why each article starts from a real-world problem. We will break "
"down each problem in fundamental questions, suggest solutions, analyze the "
"pros and cons of each option, and highlight the best course of action for "
"the problem at hand."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:20
msgid ""
"You should start by reading :ref:`doc_what_are_godot_classes`. It explains "
"how Godot's nodes and scenes relate to classes and objects in other Object-"
"Oriented programming languages. It will help you make sense of the rest of "
"the series."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/introduction_best_practices.rst:26
msgid ""
"The best practices in Godot rely on Object-Oriented design principles. We "
"use tools like the `single responsibility <https://en.wikipedia.org/wiki/"
"Single_responsibility_principle>`_ principle and `encapsulation <https://en."
"wikipedia.org/wiki/Encapsulation_(computer_programming)>`_."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:4
msgid "Godot scenes and scripts are classes"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:6
msgid ""
"In Godot, scripts and scenes can both be the equivalent of classes in an "
"Object-Oriented programming language. The main difference is that scenes are "
"`declarative code <https://en.wikipedia.org/wiki/Declarative_programming>`_, "
"while scripts can contain `imperative code <https://en.wikipedia.org/wiki/"
"Imperative_programming>`_."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:12
msgid ""
"As a result, many best practices in Godot boil down to applying Object-"
"Oriented design principles to the scenes, nodes, or scripts that make up "
"your game."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:15
msgid ""
"This guide explains how scripts and scenes work in the engine's core, to "
"help you get a sense of how Godot works under the hood, and to help you "
"better understand where some of this series' best practices come from."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:20
msgid "Making sense of classes in Godot"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:22
msgid ""
"Godot Engine provides built-in classes like :ref:`Node <class_Node>`. User-"
"created types are not technically classes. Instead, they are resources that "
"tell the engine a sequence of initializations to perform on one of the "
"engine's built-in classes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:27
msgid ""
"Godot's internal classes have methods that register a class's data with a :"
"ref:`ClassDB <class_ClassDB>`. This database provides runtime access to "
"class information. ``ClassDB`` contains information about classes like:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:31
msgid "properties"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:32
msgid "methods"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:33
#, fuzzy
msgid "constants"
msgstr "קבועים"

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:34
#, fuzzy
msgid "signals"
msgstr "אותות"

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:36
msgid ""
"This ``ClassDB`` is what Objects check against when performing an operation "
"like accessing a property or calling a method. ``ClassDB`` checks the "
"database's records and the records of the Object's base types to see if the "
"Object supports the operation."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:41
msgid ""
"On the engine's side, every class defines a static ``_bind_methods()`` "
"function that describes what C++ content it registers to the database and "
"how. When you use the engine, you can extend the methods, properties, and "
"signals available from the ``ClassDB`` by attaching a :ref:`Script "
"<class_Script>` to your node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:46
msgid ""
"Objects check their attached script before the database. This is why scripts "
"can override built-in methods. If a script defines a "
"``_get_property_list()`` method, Godot appends that data to the list of "
"properties the Object fetches from the ClassDB. The same is true for other "
"declarative code."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:51
msgid ""
"Even scripts that don't inherit from a built-in type, i.e. scripts that "
"don't start with the ``extends`` keyword, implicitly inherit from the "
"engine's base :ref:`Reference <class_Reference>` class. This allows the "
"Object to defer to the script's content where the engine logic deems "
"appropriate."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:58
msgid ""
"As a result, you can instance scripts without the ``extends`` keyword from "
"code, but you cannot attach them to a :ref:`Node <class_Node>`"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:63
msgid "Scripting performances and PackedScene"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:65
msgid ""
"As the size of Objects increases, the scripts' necessary size to create them "
"grows much, much larger. Creating node hierarchies demonstrates this. Each "
"individual Node's logic could be several hundred lines of code in length."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:69
msgid ""
"Let's see a simple example of creating a single ``Node`` as a child. The "
"code below creates a new ``Node``, changes its name, assigns a script to it, "
"sets its future parent as its owner so it gets saved to disk along with it, "
"and finally adds it as a child of the ``Main`` node:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:109
msgid ""
"Script code like this is much slower than engine-side C++ code. Each change "
"makes a separate call to the scripting API which leads to many \"look-ups\" "
"on the back-end to find the logic to execute."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:113
msgid ""
"Scenes help to avoid this performance issue. :ref:`PackedScene "
"<class_PackedScene>`, the base type that scenes inherit from, are resources "
"that use serialized data to create objects. The engine can process scenes in "
"batches on the back-end and provide much better performance than scripts."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:119
msgid "Scenes and scripts are objects"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:121
msgid ""
"Why is any of this important to scene organization? Because scenes *are* "
"objects. One often pairs a scene with a scripted root node that makes use of "
"the sub-nodes. This means that the scene is often an extension of the "
"script's declarative code."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:126
msgid "The content of a scene helps to define:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:128
msgid "What nodes are available to the script"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:129
msgid "How they are organized"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:130
msgid "How they are initialized"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:131
msgid "What signal connections they have with each other"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:133
msgid ""
"Many Object-Oriented principles which apply to written code *also* apply to "
"scenes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:136
msgid ""
"The scene is *always an extension of the script attached to its root node*. "
"You can see all the nodes it contains as part of a single class."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/what_are_godot_classes.rst:139
msgid ""
"Most of the tips and techniques explained in this series will build on this."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:4
#, fuzzy
msgid "Scene organization"
msgstr "אנימציות"

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:6
msgid ""
"This article covers topics related to the effective organization of scene "
"content. Which nodes should one use? Where should one place them? How should "
"they interact?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:11
msgid "How to build relationships effectively"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:13
msgid ""
"When Godot users begin crafting their own scenes, they often run into the "
"following problem:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:16
msgid ""
"They create their first scene and fill it with content only to eventually "
"end up saving branches of their scene into separate scenes as the nagging "
"feeling that they should split things up starts to accumulate. However, they "
"then notice that the hard references they were able to rely on before are no "
"longer possible. Re-using the scene in multiple places creates issues "
"because the node paths do not find their targets and signal connections "
"established in the editor break."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:24
msgid ""
"To fix these problems, one must instantiate the sub-scenes without them "
"requiring details about their environment. One needs to be able to trust "
"that the sub-scene will create itself without being picky about how one uses "
"it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:29
msgid ""
"One of the biggest things to consider in OOP is maintaining focused, "
"singular-purpose classes with `loose coupling <https://en.wikipedia.org/wiki/"
"Loose_coupling>`_ to other parts of the codebase. This keeps the size of "
"objects small (for maintainability) and improves their reusability."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:35
msgid ""
"These OOP best practices have *several* implications for best practices in "
"scene structure and script usage."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:38
msgid ""
"**If at all possible, one should design scenes to have no dependencies.** "
"That is, one should create scenes that keep everything they need within "
"themselves."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:42
msgid ""
"If a scene must interact with an external context, experienced developers "
"recommend the use of `Dependency Injection <https://en.wikipedia.org/wiki/"
"Dependency_injection>`_. This technique involves having a high-level API "
"provide the dependencies of the low-level API. Why do this? Because classes "
"which rely on their external environment can inadvertently trigger bugs and "
"unexpected behavior."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:49
msgid ""
"To do this, one must expose data and then rely on a parent context to "
"initialize it:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:52
msgid ""
"Connect to a signal. Extremely safe, but should be used only to \"respond\" "
"to behavior, not start it. Note that signal names are usually past-tense "
"verbs like \"entered\", \"skill_activated\", or \"item_collected\"."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:73
msgid "Call a method. Used to start behavior."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:92
msgid ""
"Initialize a :ref:`FuncRef <class_FuncRef>` property. Safer than a method as "
"ownership of the method is unnecessary. Used to start behavior."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:112
msgid "Initialize a Node or other Object reference."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:131
msgid "Initialize a NodePath."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:150
msgid ""
"These options hide the points of access from the child node. This in turn "
"keeps the child **loosely coupled** to its environment. One can re-use it in "
"another context without any extra changes to its API."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:156
msgid ""
"Although the examples above illustrate parent-child relationships, the same "
"principles apply towards all object relations. Nodes which are siblings "
"should only be aware of their hierarchies while an ancestor mediates their "
"communications and references."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:203
msgid ""
"The same principles also apply to non-Node objects that maintain "
"dependencies on other objects. Whichever object actually owns the objects "
"should manage the relationships between them."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:209
msgid ""
"One should favor keeping data in-house (internal to a scene) though as "
"placing a dependency on an external context, even a loosely coupled one, "
"still means that the node will expect something in its environment to be "
"true. The project's design philosophies should prevent this from happening. "
"If not, the code's inherent liabilities will force developers to use "
"documentation to keep track of object relations on a microscopic scale; this "
"is otherwise known as development hell. Writing code that relies on external "
"documentation for one to use it safely is error-prone by default."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:218
msgid ""
"To avoid creating and maintaining such documentation, one converts the "
"dependent node (\"child\" above) into a tool script that implements :ref:"
"`_get_configuration_warning() "
"<class_Node_method__get_configuration_warning>`. Returning a non-empty "
"string from it will make the Scene dock generate a warning icon with the "
"string as a tooltip by the node. This is the same icon that appears for "
"nodes such as the :ref:`Area2D <class_Area2D>` node when it has no child :"
"ref:`CollisionShape2D <class_CollisionShape2D>` nodes defined. The editor "
"then self-documents the scene through the script code. No content "
"duplication via documentation is necessary."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:229
msgid ""
"A GUI like this can better inform project users of critical information "
"about a Node. Does it have external dependencies? Have those dependencies "
"been satisfied? Other programmers, and especially designers and writers, "
"will need clear instructions in the messages telling them what to do to "
"configure it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:234
msgid ""
"So, why do all this complex switcharoo work? Well, because scenes operate "
"best when they operate alone. If unable to work alone, then working with "
"others anonymously (with minimal hard dependencies, i.e. loose coupling) is "
"the next best thing. Inevitably, changes may need to be made to a class and "
"if these changes cause it to interact with other scenes in unforeseen ways, "
"then things will start to break down. The whole point of all this "
"indirection is to avoid ending up in a situation where changing one class "
"results in adversely effecting other classes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:243
msgid ""
"Scripts and scenes, as extensions of engine classes, should abide by *all* "
"OOP principles. Examples include..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:246
msgid "`SOLID <https://en.wikipedia.org/wiki/SOLID>`_"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:247
msgid "`DRY <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>`_"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:248
msgid "`KISS <https://en.wikipedia.org/wiki/KISS_principle>`_"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:249
msgid "`YAGNI <https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it>`_"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:252
msgid "Choosing a node tree structure"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:254
msgid ""
"So, a developer starts work on a game only to stop at the vast possibilities "
"before them. They might know what they want to do, what systems they want to "
"have, but *where* to put them all? Well, how one goes about making their "
"game is always up to them. One can construct node trees in a myriad of ways. "
"But, for those who are unsure, this helpful guide can give them a sample of "
"a decent structure to start with."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:261
msgid ""
"A game should always have a sort of \"entry point\"; somewhere the developer "
"can definitively track where things begin so that they can follow the logic "
"as it continues elsewhere. This place also serves as a bird's eye view of "
"all of the other data and logic in the program. For traditional "
"applications, this would be the \"main\" function. In this case, it would be "
"a Main node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:267
#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:278
msgid "Node \"Main\" (main.gd)"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:269
msgid ""
"The ``main.gd`` script would then serve as the primary controller of one's "
"game."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:272
msgid ""
"Then one has their actual in-game \"World\" (a 2D or 3D one). This can be a "
"child of Main. In addition, one will need a primary GUI for their game that "
"manages the various menus and widgets the project needs."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:277
msgid "Node2D/Spatial \"World\" (game_world.gd)"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:278
msgid "Control \"GUI\" (gui.gd)"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:280
msgid ""
"When changing levels, one can then swap out the children of the \"World\" "
"node. :ref:`Changing scenes manually <doc_change_scenes_manually>` gives "
"users full control over how their game world transitions."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:284
msgid ""
"The next step is to consider what gameplay systems one's project requires. "
"If one has a system that..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:287
msgid "tracks all of its data internally"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:288
msgid "should be globally accessible"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:289
msgid "should exist in isolation"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:291
msgid ""
"... then one should create an :ref:`autoload 'singleton' node "
"<doc_singletons_autoload>`."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:295
msgid ""
"For smaller games, a simpler alternative with less control would be to have "
"a \"Game\" singleton that simply calls the :ref:`SceneTree.change_scene() "
"<class_SceneTree_method_change_scene>` method to swap out the main scene's "
"content. This structure more or less keeps the \"World\" as the main game "
"node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:301
msgid ""
"Any GUI would need to also be a singleton; be a transitory part of the "
"\"World\"; or be manually added as a direct child of the root. Otherwise, "
"the GUI nodes would also delete themselves during scene transitions."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:306
msgid ""
"If one has systems that modify other systems' data, one should define those "
"as their own scripts or scenes rather than autoloads. For more information "
"on the reasons, please see the :ref:`'Autoloads vs. Internal Nodes' "
"<doc_autoloads_versus_internal_nodes>` documentation."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:312
msgid ""
"Each subsystem within one's game should have its own section within the "
"SceneTree. One should use parent-child relationships only in cases where "
"nodes are effectively elements of their parents. Does removing the parent "
"reasonably mean that one should also remove the children? If not, then it "
"should have its own place in the hierarchy as a sibling or some other "
"relation."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:320
msgid ""
"In some cases, one needs these separated nodes to *also* position themselves "
"relative to each other. One can use the :ref:`RemoteTransform "
"<class_RemoteTransform>` / :ref:`RemoteTransform2D "
"<class_RemoteTransform2D>` nodes for this purpose. They will allow a target "
"node to conditionally inherit selected transform elements from the Remote\\* "
"node. To assign the ``target`` :ref:`NodePath <class_NodePath>`, use one of "
"the following:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:328
msgid ""
"A reliable third party, likely a parent node, to mediate the assignment."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:329
msgid ""
"A group, to easily pull a reference to the desired node (assuming there will "
"only ever be one of the targets)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:332
msgid ""
"When should one do this? Well, this is subjective. The dilemma arises when "
"one must micro-manage when a node must move around the SceneTree to preserve "
"itself. For example..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:336
msgid "Add a \"player\" node to a \"room\"."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:337
msgid "Need to change rooms, so one must delete the current room."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:338
msgid ""
"Before the room can be deleted, one must preserve and/or move the player."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:340
msgid "Is memory a concern?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:342
msgid ""
"If not, one can just create the two rooms, move the player and delete the "
"old one. No problem."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:345
msgid "If so, one will need to..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:347
msgid "Move the player somewhere else in the tree."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:348
msgid "Delete the room."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:349
msgid "Instantiate and add the new room."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:350
msgid "Re-add the player."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:352
msgid ""
"The issue is that the player here is a \"special case\"; one where the "
"developers must *know* that they need to handle the player this way for the "
"project. As such, the only way to reliably share this information as a team "
"is to *document* it. Keeping implementation details in documentation however "
"is dangerous. It's a maintenance burden, strains code readability, and "
"bloats the intellectual content of a project unnecessarily."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:359
msgid ""
"In a more complex game with larger assets, it can be a better idea to simply "
"keep the player somewhere else in the SceneTree entirely. This results in:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:362
msgid "More consistency."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:363
msgid "No \"special cases\" that must be documented and maintained somewhere."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:364
msgid ""
"No opportunity for errors to occur because these details are not accounted "
"for."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:367
msgid ""
"In contrast, if one ever needs to have a child node that does *not* inherit "
"the transform of their parent, one has the following options:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:370
msgid ""
"The **declarative** solution: place a :ref:`Node <class_Node>` in between "
"them. As nodes with no transform, Nodes will not pass along such information "
"to their children."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:373
msgid ""
"The **imperative** solution: Use the ``set_as_toplevel`` setter for the :ref:"
"`CanvasItem <class_CanvasItem_method_set_as_toplevel>` or :ref:`Spatial "
"<class_Spatial_method_set_as_toplevel>` node. This will make the node ignore "
"its inherited transform."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:380
msgid ""
"If building a networked game, keep in mind which nodes and gameplay systems "
"are relevant to all players versus those just pertinent to the authoritative "
"server. For example, users do not all need to have a copy of every players' "
"\"PlayerController\" logic. Instead, they need only their own. As such, "
"keeping these in a separate branch from the \"world\" can help simplify the "
"management of game connections and the like."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:387
msgid ""
"The key to scene organization is to consider the SceneTree in relational "
"terms rather than spatial terms. Are the nodes dependent on their parent's "
"existance? If not, then they can thrive all by themselves somewhere else. If "
"they are dependent, then it stands to reason that they should be children of "
"that parent (and likely part of that parent's scene if they aren't already)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scene_organization.rst:393
msgid ""
"Does this mean nodes themselves are components? Not at all. Godot's node "
"trees form an aggregation relationship, not one of composition. But while "
"one still has the flexibility to move nodes around, it is still best when "
"such moves are unnecessary by default."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:4
msgid "When to use scenes versus scripts"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:6
msgid ""
"We've already covered how scenes and scripts are different. Scripts define "
"an engine class extension with imperative code, scenes with declarative code."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:10
msgid ""
"Each system's capabilities are different as a result. Scenes can define how "
"an extended class initializes, but not what its behavior actually is. Scenes "
"are often used in conjunction with a script so that the scene acts as an "
"extension of the scripts declarative code."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:16
msgid "Anonymous types"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:18
msgid ""
"It *is* possible to completely define a scenes' contents using a script "
"alone. This is, in essence, what the Godot Editor does, only in the C++ "
"constructor of its objects."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:22
msgid ""
"But, choosing which one to use can be a dilemma. Creating script instances "
"is identical to creating in-engine classes whereas handling scenes requires "
"a change in API:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:59
msgid ""
"Also, scripts will operate a little slower than scenes due to the speed "
"differences between engine and script code. The larger and more complex the "
"node, the more reason there is to build it as a scene."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:64
msgid "Named types"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:66
msgid ""
"In some cases, a user can register a script as a new type within the editor "
"itself. This displays it as a new type in the node or resource creation "
"dialog with an optional icon. In these cases, the user's ability to use the "
"script is much more streamlined. Rather than having to..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:71
msgid "Know the base type of the script they would like to use."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:73
msgid "Create an instance of that base type."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:75
msgid "Add the script to the node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:77
msgid "(Drag-n-drop method)"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:79
msgid "Find the script in the FileSystem dock."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:81
msgid "Drag and drop the script onto the node in the Scene dock."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:83
msgid "(Property method)"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:85
msgid ""
"Scroll down to the bottom of the Inspector to find the ``script`` property "
"and select it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:87
msgid "Select \"Load\" from the dropdown."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:89
msgid "Select the script from the file dialog."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:91
msgid ""
"With a registered script, the scripted type instead becomes a creation "
"option like the other nodes and resources in the system. One need not do any "
"of the above work. The creation dialog even has a search bar to look up the "
"type by name."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:96
msgid "There are two systems for registering types..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:98
msgid ":ref:`Custom Types <doc_making_plugins>`"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:100
msgid "Editor-only. Typenames are not accessible at runtime."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:102
msgid "Does not support inherited custom types."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:104
msgid "An initializer tool. Creates the node with the script. Nothing more."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:106
msgid ""
"Editor has no type-awareness of the script or its relationship to other "
"engine types or scripts."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:109
#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:127
msgid "Allows users to define an icon."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:111
msgid ""
"Works for all scripting languages because it deals with Script resources in "
"abstract."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:113
msgid ""
"Set up using :ref:`EditorPlugin.add_custom_type "
"<class_EditorPlugin_method_add_custom_type>`."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:115
msgid ":ref:`Script Classes <doc_scripting_continued_class_name>`"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:117
msgid "Editor and runtime accessible."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:119
msgid "Displays inheritance relationships in full."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:121
msgid ""
"Creates the node with the script, but can also change types or extend the "
"type from the editor."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:124
msgid ""
"Editor is aware of inheritance relationships between scripts, script "
"classes, and engine C++ classes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:129
msgid ""
"Engine developers must add support for languages manually (both name "
"exposure and runtime accessibility)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:132
msgid "Godot 3.1+ only."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:134
msgid ""
"The Editor scans project folders and registers any exposed names for all "
"scripting languages. Each scripting language must implement its own support "
"for exposing this information."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:138
msgid ""
"Both methodologies add names to the creation dialog, but script classes, in "
"particular, also allow for users to access the typename without loading the "
"script resource. Creating instances and accessing constants or static "
"methods is viable from anywhere."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:143
msgid ""
"With features like these, one may wish their type to be a script without a "
"scene due to the ease of use it grants users. Those developing plugins or "
"creating in-house tools for designers to use will find an easier time of "
"things this way."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:148
msgid ""
"On the downside, it also means having to use largely imperative programming."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:153
msgid "In the end, the best approach is to consider the following:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:155
msgid ""
"If one wishes to create a basic tool that is going to be re-used in several "
"different projects and which people of all skill levels will likely use "
"(including those who don't label themselves as \"programmers\"), then "
"chances are that it should probably be a script, likely one with a custom "
"name/icon."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:160
msgid ""
"If one wishes to create a concept that is particular to their game, then it "
"should always be a scene. Scenes are easier to track/edit and provide more "
"security than scripts."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/scenes_versus_scripts.rst:164
msgid ""
"If one would like to give a name to a scene, then they can still sort of do "
"this in 3.1 by declaring a script class and giving it a scene as a constant. "
"The script becomes, in effect, a namespace:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:4
msgid "Autoloads versus regular nodes"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:6
msgid ""
"Godot offers a feature to automatically load nodes at the root of your "
"project, allowing you to access them globally, that can fulfill the role of "
"a Singleton: :ref:`doc_singletons_autoload`. These auto-loaded nodes are not "
"freed when you change the scene from code with :ref:`SceneTree.change_scene "
"<class_SceneTree_method_change_scene>`."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:11
msgid ""
"In this guide, you will learn when to use the Autoload feature, and "
"techniques you can use to avoid it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:15
msgid "The cutting audio issue"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:17
msgid ""
"Other engines can encourage the use of creating manager classes, singletons "
"that organize a lot of functionality into a globally accessible object. "
"Godot offers many ways to avoid global state thanks to the node tree and "
"signals."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:21
msgid ""
"For example, let's say we are building a platformer and want to collect "
"coins that play a sound effect. There's a node for that: the :ref:"
"`AudioStreamPlayer <class_AudioStreamPlayer>`. But if we call the "
"``AudioStreamPlayer`` while it is already playing a sound, the new sound "
"interrupts the first."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:26
msgid ""
"A solution is to code a global, auto-loaded sound manager class. It "
"generates a pool of ``AudioStreamPlayer`` nodes that cycle through as each "
"new request for sound effects comes in. Say we call that class ``Sound``, "
"you can use it from anywhere in your project by calling ``Sound."
"play(\"coin_pickup.ogg\")``. This solves the problem in the short term but "
"causes more problems:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:32
msgid ""
"**Global state**: one object is now responsible for all objects' data. If "
"the ``Sound`` class has errors or doesn't have an AudioStreamPlayer "
"available, all the nodes calling it can break."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:36
msgid ""
"**Global access**: now that any object can call ``Sound.play(sound_path)`` "
"from anywhere, there's no longer an easy way to find the source of a bug."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:39
msgid ""
"**Global resource allocation**: with a pool of ``AudioStreamPlayer`` nodes "
"stored from the start, you can either have too few and face bugs, or too "
"many and use more memory than you need."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:45
msgid ""
"About global access, the problem is that Any code anywhere could pass wrong "
"data to the ``Sound`` autoload in our example. As a result, the domain to "
"explore to fix the bug spans the entire project."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:49
msgid ""
"When you keep code inside a scene, only one or two scripts may be involved "
"in audio."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:52
msgid ""
"Contrast this with each scene keeping as many ``AudioStreamPlayer`` nodes as "
"it needs within itself and all these problems go away:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:55
msgid ""
"Each scene manages its own state information. If there is a problem with the "
"data, it will only cause issues in that one scene."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:58
msgid ""
"Each scene accesses only its own nodes. Now, if there is a bug, it's easy to "
"find which node is at fault."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:61
msgid "Each scene allocates exactly the amount of resources it needs."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:64
msgid "Managing shared functionality or data"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:66
msgid ""
"Another reason to use an Autoload can be that you want to reuse the same "
"method or data across many scenes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:69
msgid ""
"In the case of functions, you can create a new type of ``Node`` that "
"provides that feature for an individual scene using the :ref:`class_name "
"<doc_scripting_continued_class_name>` keyword in GDScript."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:73
msgid "When it comes to data, you can either:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:75
msgid ""
"Create a new type of :ref:`Resource <class_Resource>` to share the data."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:77
msgid ""
"Store the data in an object to which each node has access, for example using "
"the ``owner`` property to access the scene's root node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:81
msgid "When you should use an Autoload"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:83
msgid "Auto-loaded nodes can simplify your code in some cases:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:85
msgid ""
"**Static Data**: if you need data that is exclusive to one class, like a "
"database, then an autoload can be a good tool. There is no scripting API in "
"Godot to create and manage static data otherwise."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:89
msgid ""
"**Static functions**: creating a library of functions that only return "
"values."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:91
msgid ""
"**Systems with a wide scope**: If the singleton is managing its own "
"information and not invading the data of other objects, then it's a great "
"way to create systems that handle broad-scoped tasks. For example, a quest "
"or a dialogue system."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:96
msgid ""
"Until Godot 3.1, another use was just for convenience: autoloads have a "
"global variable for their name generated in GDScript, allowing you to call "
"them from any script file in your project. But now, you can use the "
"``class_name`` keyword instead to get auto-completion for a type in your "
"entire project."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:103
msgid ""
"Autoload is not exactly a Singleton. Nothing prevents you from instantiating "
"copies of an auto-loaded node. It is only a tool that makes a node load "
"automatically as a child of the root of your scene tree, regardless of your "
"game's node structure or which scene you run, e.g. by pressing :kbd:`F6` key."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/autoloads_versus_internal_nodes.rst:108
msgid ""
"As a result, you can get the auto-loaded node, for example an autoload "
"called ``Sound``, by calling ``get_node(\"/root/Sound\")``."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:4
msgid "When and how to avoid using nodes for everything"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:7
msgid ""
"Nodes are cheap to produce, but even they have their limits. A project may "
"have tens of thousands of nodes all doing things. The more complex their "
"behavior though, the larger the strain each one adds to a project's "
"performance."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:12
msgid ""
"Godot provides more lightweight objects for creating APIs which nodes use. "
"Be sure to keep these in mind as options when designing how you wish to "
"build your project's features."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:16
msgid ""
":ref:`Object <class_Object>`: The ultimate lightweight object, the original "
"Object must use manual memory management. With that said, it isn't too "
"difficult to create one's own custom data structures, even node structures, "
"that are also lighter than the :ref:`Node <class_Node>` class."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:21
msgid ""
"**Example:** See the :ref:`Tree <class_Tree>` node. It supports a high level "
"of customization for a table of content with an arbitrary number of rows and "
"columns. The data that it uses to generate its visualization though is "
"actually a tree of :ref:`TreeItem <class_TreeItem>` Objects."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:26
msgid ""
"**Advantages:** Simplifying one's API to smaller scoped objects helps "
"improve its accessibility improve iteration time. Rather than working with "
"the entire Node library, one creates an abbreviated set of Objects from "
"which a node can generate and manage the appropriate sub-nodes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:31
msgid ""
"One should be careful when handling them. One can store an Object into a "
"variable, but these references can become invalid without warning. For "
"example, if the object's creator decides to delete it out of nowhere, this "
"would trigger an error state when one next accesses it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:36
msgid ""
":ref:`Reference <class_Reference>`: Only a little more complex than Object. "
"They track references to themselves, only deleting loaded memory when no "
"further references to themselves exist. These are useful in the majority of "
"cases where one needs data in a custom class."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:41
msgid ""
"**Example:** See the :ref:`File <class_File>` object. It functions just like "
"a regular Object except that one need not delete it themselves."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:44
msgid "**Advantages:** same as the Object."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:46
msgid ""
":ref:`Resource <class_Resource>`: Only slightly more complex than Reference. "
"They have the innate ability to serialize/deserialize (i.e. save and load) "
"their object properties to/from Godot resource files."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:50
msgid ""
"**Example:** Scripts, PackedScene (for scene files), and other types like "
"each of the :ref:`AudioEffect <class_AudioEffect>` classes. Each of these "
"can be save and loaded, therefore they extend from Resource."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/node_alternatives.rst:54
msgid ""
"**Advantages:** Much has :ref:`already been said <doc_resources>` on :ref:"
"`Resource <class_Resource>`'s advantages over traditional data storage "
"methods. In the context of using Resources over Nodes though, their main "
"advantage is in Inspector-compatibility. While nearly as lightweight as "
"Object/Reference, they can still display and export properties in the "
"Inspector. This allows them to fulfill a purpose much like sub-Nodes on the "
"usability front, but also improve performance if one plans to have many such "
"Resources/Nodes in their scenes."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:4
msgid "Godot interfaces"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:6
msgid ""
"Often one needs scripts that rely on other objects for features. There are 2 "
"parts to this process:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:9
msgid "Acquiring a reference to the object that presumably has the features."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:11
msgid "Accessing the data or logic from the object."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:13
msgid "The rest of this tutorial outlines the various ways of doing all this."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:16
msgid "Acquiring object references"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:18
msgid ""
"For all :ref:`Object <class_Object>`\\s, the most basic way of referencing "
"them is to get a reference to an existing object from another acquired "
"instance."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:32
msgid ""
"The same principle applies for :ref:`Reference <class_Reference>` objects. "
"While users often access :ref:`Node <class_Node>` and :ref:`Resource "
"<class_Resource>` this way, alternative measures are available."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:36
msgid ""
"Instead of property or method access, one can get Resources by load access."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:115
msgid "Note the following:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:117
msgid "There are many ways in which a language can load such resources."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:119
msgid ""
"When designing how objects will access data, don't forget that one can pass "
"resources around as references as well."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:122
msgid ""
"Keep in mind that loading a resource fetches the cached resource instance "
"maintained by the engine. To get a new object, one must :ref:`duplicate "
"<class_Resource_method_duplicate>` an existing reference or instantiate one "
"from scratch with ``new()``."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:127
msgid "Nodes likewise have an alternative access point: the SceneTree."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:244
msgid "Accessing data or logic from an object"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:246
msgid ""
"Godot's scripting API is duck-typed. This means that if a script executes an "
"operation, Godot doesn't validate that it supports the operation by "
"**type**. It instead checks that the object **implements** the individual "
"method."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:250
msgid ""
"For example, the :ref:`CanvasItem <class_CanvasItem>` class has a "
"``visible`` property. All properties exposed to the scripting API are in "
"fact a setter and getter pair bound to a name. If one tried to access :ref:"
"`CanvasItem.visible <class_CanvasItem_property_visible>`, then Godot would "
"do the following checks, in order:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:256
msgid ""
"If the object has a script attached, it will attempt to set the property "
"through the script. This leaves open the opportunity for scripts to override "
"a property defined on a base object by overriding the setter method for the "
"property."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:261
msgid ""
"If the script does not have the property, it performs a HashMap lookup in "
"the ClassDB for the \"visible\" property against the CanvasItem class and "
"all of its inherited types. If found, it will call the bound setter or "
"getter. For more information about HashMaps, see the :ref:`data preferences "
"<doc_data_preferences>` docs."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:267
msgid ""
"If not found, it does an explicit check to see if the user wants to access "
"the \"script\" or \"meta\" properties."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:270
msgid ""
"If not, it checks for a ``_set``/``_get`` implementation (depending on type "
"of access) in the CanvasItem and its inherited types. These methods can "
"execute logic that gives the impression that the Object has a property. This "
"is also the case with the ``_get_property_list`` method."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:275
msgid ""
"Note that this happens even for non-legal symbol names such as in the case "
"of :ref:`TileSet <class_TileSet>`'s \"1/tile_name\" property. This refers to "
"the name of the tile with ID 1, i.e. :ref:`TileSet.tile_get_name(1) "
"<class_TileSet_method_tile_get_name>`."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:280
msgid ""
"As a result, this duck-typed system can locate a property either in the "
"script, the object's class, or any class that object inherits, but only for "
"things which extend Object."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:284
msgid ""
"Godot provides a variety of options for performing runtime checks on these "
"accesses:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:287
msgid ""
"A duck-typed property access. These will property check (as described "
"above). If the operation isn't supported by the object, execution will halt."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:315
msgid ""
"A method check. In the case of :ref:`CanvasItem.visible "
"<class_CanvasItem_property_visible>`, one can access the methods, "
"``set_visible`` and ``is_visible`` like any other method."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:447
msgid ""
"Outsource the access to a :ref:`FuncRef <class_FuncRef>`. These may be "
"useful in cases where one needs the max level of freedom from dependencies. "
"In this case, one relies on an external context to setup the method."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_interfaces.rst:506
msgid ""
"These strategies contribute to Godot's flexible design. Between them, users "
"have a breadth of tools to meet their specific needs."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:4
msgid "Godot notifications"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:6
msgid ""
"Every Object in Godot implements a :ref:`_notification "
"<class_Object_method__notification>` method. Its purpose is to allow the "
"Object to respond to a variety of engine-level callbacks that may relate to "
"it. For example, if the engine tells a :ref:`CanvasItem <class_CanvasItem>` "
"to \"draw\", it will call ``_notification(NOTIFICATION_DRAW)``."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:13
msgid ""
"Some of these notifications, like draw, are useful to override in scripts. "
"So much so that Godot exposes many of them with dedicated functions:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:16
msgid "``_ready()`` : NOTIFICATION_READY"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:18
msgid "``_enter_tree()`` : NOTIFICATION_ENTER_TREE"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:20
msgid "``_exit_tree()`` : NOTIFICATION_EXIT_TREE"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:22
msgid "``_process(delta)`` : NOTIFICATION_PROCESS"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:24
msgid "``_physics_process(delta)`` : NOTIFICATION_PHYSICS_PROCESS"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:26
msgid "``_input()`` : NOTIFICATION_INPUT"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:28
msgid "``_unhandled_input()`` : NOTIFICATION_UNHANDLED_INPUT"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:30
msgid "``_draw()`` : NOTIFICATION_DRAW"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:32
msgid ""
"What users might *not* realize is that notifications exist for types other "
"than Node alone:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:35
msgid ""
":ref:`Object::NOTIFICATION_POSTINITIALIZE "
"<class_Object_constant_NOTIFICATION_POSTINITIALIZE>`: a callback that "
"triggers during object initialization. Not accessible to scripts."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:38
msgid ""
":ref:`Object::NOTIFICATION_PREDELETE "
"<class_Object_constant_NOTIFICATION_PREDELETE>`: a callback that triggers "
"before the engine deletes an Object, i.e. a 'destructor'."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:42
msgid ""
":ref:`MainLoop::NOTIFICATION_WM_MOUSE_ENTER "
"<class_MainLoop_constant_NOTIFICATION_WM_MOUSE_ENTER>`: a callback that "
"triggers when the mouse enters the window in the operating system that "
"displays the game content."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:46
msgid ""
"And many of the callbacks that *do* exist in Nodes don't have any dedicated "
"methods, but are still quite useful."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:49
msgid ""
":ref:`Node::NOTIFICATION_PARENTED "
"<class_Node_constant_NOTIFICATION_PARENTED>`: a callback that triggers "
"anytime one adds a child node to another node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:52
msgid ""
":ref:`Node::NOTIFICATION_UNPARENTED "
"<class_Node_constant_NOTIFICATION_UNPARENTED>`: a callback that triggers "
"anytime one removes a child node from another node."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:56
msgid ""
":ref:`Popup::NOTIFICATION_POST_POPUP "
"<class_Popup_constant_NOTIFICATION_POST_POPUP>`: a callback that triggers "
"after a Popup node completes any ``popup*`` method. Note the difference from "
"its ``about_to_show`` signal which triggers *before* its appearance."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:61
msgid ""
"One can access all these custom notifications from the universal "
"``_notification`` method."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:65
msgid ""
"Methods in the documentation labeled as \"virtual\" are also intended to be "
"overridden by scripts."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:68
msgid ""
"A classic example is the :ref:`_init <class_Object_method__init>` method in "
"Object. While it has no ``NOTIFICATION_*`` equivalent, the engine still "
"calls the method. Most languages (except C#) rely on it as a constructor."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:73
msgid ""
"So, in which situation should one use each of these notifications or virtual "
"functions?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:77
msgid "_process vs. _physics_process vs. \\*_input"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:79
msgid ""
"Use ``_process`` when one needs a framerate-dependent deltatime between "
"frames. If code that updates object data needs to update as often as "
"possible, this is the right place. Recurring logic checks and data caching "
"often execute here, but it comes down to the frequency at which one needs "
"the evaluations to update. If they don't need to execute every frame, then "
"implementing a Timer-yield-timeout loop is another option."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:97
msgid ""
"Use ``_physics_process`` when one needs a framerate-independent deltatime "
"between frames. If code needs consistent updates over time, regardless of "
"how fast or slow time advances, this is the right place. Recurring kinematic "
"and object transform operations should execute here."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:102
msgid ""
"While it is possible, to achieve the best performance, one should avoid "
"making input checks during these callbacks. ``_process`` and "
"``_physics_process`` will trigger at every opportunity (they do not \"rest\" "
"by default). In contrast, ``*_input`` callbacks will trigger only on frames "
"in which the engine has actually detected the input."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:108
msgid ""
"One can check for input actions within the input callbacks just the same. If "
"one wants to use delta time, one can fetch it from the related deltatime "
"methods as needed."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:156
msgid "_init vs. initialization vs. export"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:158
msgid ""
"If the script initializes its own node subtree, without a scene, that code "
"should execute here. Other property or SceneTree-independent initializations "
"should also run here. This triggers before ``_ready`` or ``_enter_tree``, "
"but after a script creates and initializes its properties."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:163
msgid ""
"Scripts have three types of property assignments that can occur during "
"instantiation:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:210
msgid ""
"When instantiating a scene, property values will set up according to the "
"following sequence:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:213
msgid ""
"**Initial value assignment:** instantiation will assign either the "
"initialization value or the init assignment value. Init assignments take "
"priority over initialization values."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:217
msgid ""
"**Exported value assignment:** If instancing from a scene rather than a "
"script, Godot will assign the exported value to replace the initial value "
"defined in the script."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:221
msgid ""
"As a result, instantiating a script versus a scene will affect both the "
"initialization *and* the number of times the engine calls the setter."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:225
msgid "_ready vs. _enter_tree vs. NOTIFICATION_PARENTED"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:227
msgid ""
"When instantiating a scene connected to the first executed scene, Godot will "
"instantiate nodes down the tree (making ``_init`` calls) and build the tree "
"going downwards from the root. This causes ``_enter_tree`` calls to cascade "
"down the tree. Once the tree is complete, leaf nodes call ``_ready``. A node "
"will call this method once all child nodes have finished calling theirs. "
"This then causes a reverse cascade going up back to the tree's root."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:234
msgid ""
"When instantiating a script or a standalone scene, nodes are not added to "
"the SceneTree upon creation, so no ``_enter_tree`` callbacks trigger. "
"Instead, only the ``_init`` and later ``_ready`` calls occur."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/godot_notifications.rst:238
msgid ""
"If one needs to trigger behavior that occurs as nodes parent to another, "
"regardless of whether it occurs as part of the main/active scene or not, one "
"can use the :ref:`PARENTED <class_Node_constant_NOTIFICATION_PARENTED>` "
"notification. For example, here is a snippet that connects a node's method "
"to a custom signal on the parent node without failing. Useful on data-"
"centric nodes that one might create at runtime."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:4
msgid "Data preferences"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:6
msgid ""
"Ever wondered whether one should approach problem X with data structure Y or "
"Z? This article covers a variety of topics related to these dilemmas."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:11
msgid ""
"This article makes references to \"[something]-time\" operations. This "
"terminology comes from algorithm analysis' `Big O Notation <https://rob-bell."
"net/2009/06/a-beginners-guide-to-big-o-notation/>`_."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:15
msgid ""
"Long-story short, it describes the worst-case scenario of runtime length. In "
"laymen's terms:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:18
msgid ""
"\"As the size of a problem domain increases, the runtime length of the "
"algorithm...\""
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:21
msgid "Constant-time, ``O(1)``: \"...does not increase.\""
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:22
msgid "Logarithmic-time, ``O(log n)``: \"...increases at a slow rate.\""
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:23
msgid "Linear-time, ``O(n)``: \"...increases at the same rate.\""
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:24
msgid "Etc."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:26
msgid ""
"Imagine if one had to process 3 million data points within a single frame. "
"It would be impossible to craft the feature with a linear-time algorithm "
"since the sheer size of the data would increase the runtime far beyond the "
"time allotted. In comparison, using a constant-time algorithm could handle "
"the operation without issue."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:32
msgid ""
"By and large, developers want to avoid engaging in linear-time operations as "
"much as possible. But, if one keeps the scale of a linear-time operation "
"small, and if one does not need to perform the operation often, then it may "
"be acceptable. Balancing these requirements and choosing the right "
"algorithm / data structure for the job is part of what makes programmers' "
"skills valuable."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:40
msgid "Array vs. Dictionary vs. Object"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:42
msgid ""
"Godot stores all variables in the scripting API in the `Variant <https://"
"docs.godotengine.org/en/latest/development/cpp/variant_class.html>`_ class. "
"Variants can store Variant-compatible data structures such as :ref:`Array "
"<class_Array>` and :ref:`Dictionary <class_Dictionary>` as well as :ref:"
"`Object <class_Object>` s."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:48
msgid ""
"Godot implements Array as a ``Vector<Variant>``. The engine stores the Array "
"contents in a contiguous section of memory, i.e. they are in a row adjacent "
"to each other."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:53
msgid ""
"For those unfamiliar with C++, a Vector is the name of the array object in "
"traditional C++ libraries. It is a \"templated\" type, meaning that its "
"records can only contain a particular type (denoted by angled brackets). So, "
"for example, a :ref:`PoolStringArray <class_PoolStringArray>` would be "
"something like a ``Vector<String>``."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:60
msgid "Contiguous memory stores imply the following operation performance:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:62
msgid "**Iterate:** Fastest. Great for loops."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:64
msgid "Op: All it does is increment a counter to get to the next record."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:66
msgid "**Insert, Erase, Move:** Position-dependent. Generally slow."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:68
msgid ""
"Op: Adding/removing/moving content involves moving the adjacent records over "
"(to make room / fill space)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:71
msgid "Fast add/remove *from the end*."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:73
msgid "Slow add/remove *from an arbitrary position*."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:75
msgid "Slowest add/remove *from the front*."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:77
msgid "If doing many inserts/removals *from the front*, then..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:79
msgid "invert the array."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:81
msgid "do a loop which executes the Array changes *at the end*."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:83
msgid "re-invert the array."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:85
msgid ""
"This makes only 2 copies of the array (still constant time, but slow) versus "
"copying roughly 1/2 of the array, on average, N times (linear time)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:88
msgid ""
"**Get, Set:** Fastest *by position*. Ex. can request 0th, 2nd, 10th record, "
"etc. but cannot specify which record you want."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:91
msgid "Op: 1 addition operation from array start position up to desired index."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:93
msgid "**Find:** Slowest. Identifies the index/position of a value."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:95
msgid ""
"Op: Must iterate through array and compare values until one finds a match."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:97
msgid ""
"Performance is also dependent on whether one needs an exhaustive search."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:100
msgid ""
"If kept ordered, custom search operations can bring it to logarithmic time "
"(relatively fast). Laymen users won't be comfortable with this though. Done "
"by re-sorting the Array after every edit and writing an ordered-aware search "
"algorithm."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:105
msgid ""
"Godot implements Dictionary as an ``OrderedHashMap<Variant, Variant>``. The "
"engine stores a giant array (initialized to 1000 records) of key-value "
"pairs. When one attempts to access a value, they provide it a key. It then "
"*hashes* the key, i.e. converts it into a number. The \"hash\" becomes the "
"index into the array, giving the OHM a quick lookup for the value within the "
"conceptual \"table\" of keys mapped to values."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:112
msgid ""
"Hashes are to reduce the chance of a key collision. If one occurs, the table "
"must recalculate another index for the value that takes the previous "
"position into account. In all, this results in constant-time access to all "
"records at the expense of memory and some minor operational efficiency."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:117
msgid "Hashing every key an arbitrary number of times."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:119
msgid ""
"Hash operations are constant-time, so even if an algorithm must do more than "
"one, as long as the number of hash calculations doesn't become too dependent "
"on the density of the table, things will stay fast. Which leads to..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:124
msgid "Maintaining a huge size for the table."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:126
msgid ""
"The reason it starts with 1000 records, and the reason it forces large gaps "
"of unused memory interspersed in the table is to minimize hash collisions "
"and maintain the speed of the accesses."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:130
msgid ""
"As one might be able to tell, Dictionaries specialize in tasks that Arrays "
"do not. An overview of their operational details is as follows:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:133
msgid "**Iterate:** Fast."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:135
msgid ""
"Op: Iterate over the map's internal vector of hashes. Return each key. "
"Afterwards, users then use the key to jump to and return the desired value."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:139
msgid "**Insert, Erase, Move:** Fastest."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:141
msgid ""
"Op: Hash the given key. Do 1 addition operation to look up the appropriate "
"value (array start + offset). Move is two of these (one insert, one erase). "
"The map must do some maintenance to preserve its capabilities:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:146
msgid "update ordered List of records."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:148
msgid "determine if table density mandates a need to expand table capacity."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:150
msgid ""
"The Dictionary remembers in what order users inserted its keys. This enables "
"it to execute reliable iterations."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:153
msgid "**Get, Set:** Fastest. Same as a lookup *by key*."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:155
msgid "Op: Same as insert/erase/move."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:157
msgid "**Find:** Slowest. Identifies the key of a value."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:159
msgid ""
"Op: Must iterate through records and compare the value until a match is "
"found."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:162
msgid ""
"Note that Godot does not provide this feature out-of-the-box (because they "
"aren't meant for this task)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:165
msgid ""
"Godot implements Objects as stupid, but dynamic containers of data content. "
"Objects query data sources when posed questions. For example, to answer the "
"question, \"do you have a property called, 'position'?\", it might ask its :"
"ref:`script <class_Script>` or the :ref:`ClassDB <class_ClassDB>`. One can "
"find more information about what objects are and how they work in the :ref:"
"`doc_what_are_godot_classes` article."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:172
msgid ""
"The important detail here is the complexity of the Object's task. Every time "
"it performs one of these multi-source queries, it runs through *several* "
"iteration loops and HashMap lookups. What's more, the queries are linear-"
"time operations dependent on the Object's inheritance hierarchy size. If the "
"class the Object queries (its current class) doesn't find anything, the "
"request defers to the next base class, all the way up until the original "
"Object class. While these are each fast operations in isolation, the fact "
"that it must make so many checks is what makes them slower than both of the "
"alternatives for looking up data."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:184
msgid ""
"When developers mention how slow the scripting API is, it is this chain of "
"queries they refer to. Compared to compiled C++ code where the application "
"knows exactly where to go to find anything, it is inevitable that scripting "
"API operations will take much longer. They must locate the source of any "
"relevant data before they can attempt to access it."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:190
msgid ""
"The reason GDScript is slow is because every operation it performs passes "
"through this system."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:193
msgid ""
"C# can process some content at higher speeds via more optimized bytecode. "
"But, if the C# script calls into an engine class' content or if the script "
"tries to access something external to it, it will go through this pipeline."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:198
msgid ""
"NativeScript C++ goes even further and keeps everything internal by default. "
"Calls into external structures will go through the scripting API. In "
"NativeScript C++, registering methods to expose them to the scripting API is "
"a manual task. It is at this point that external, non-C++ classes will use "
"the API to locate them."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:204
msgid ""
"So, assuming one extends from Reference to create a data structure, like an "
"Array or Dictionary, why choose an Object over the other two options?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:207
msgid ""
"**Control:** With objects comes the ability to create more sophisticated "
"structures. One can layer abstractions over the data to ensure the external "
"API doesn't change in response to internal data structure changes. What's "
"more, Objects can have signals, allowing for reactive behavior."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:212
msgid ""
"**Clarity:** Objects are a reliable data source when it comes to the data "
"that scripts and engine classes define for them. Properties may not hold the "
"values one expects, but one doesn't need to worry about whether the property "
"exists in the first place."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:217
msgid ""
"**Convenience:** If one already has a similar data structure in mind, then "
"extending from an existing class makes the task of building the data "
"structure much easier. In comparison, Arrays and Dictionaries don't fulfill "
"all use cases one might have."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:222
msgid ""
"Objects also give users the opportunity to create even more specialized data "
"structures. With it, one can design their own List, Binary Search Tree, "
"Heap, Splay Tree, Graph, Disjoint Set, and any host of other options."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:226
msgid ""
"\"Why not use Node for tree structures?\" one might ask. Well, the Node "
"class contains things that won't be relevant to one's custom data structure. "
"As such, it can be helpful to construct one's own node type when building "
"tree structures."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:270
msgid ""
"From here, one can then create their own structures with specific features, "
"limited only by their imagination."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:274
msgid "Enumerations: int vs. string"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:276
msgid ""
"Most languages offer an enumeration type option. GDScript is no different, "
"but unlike most other languages, it allows one to use either integers or "
"strings for the enum values (the latter only when using the ``export`` "
"keyword in GDScript). The question then arises, \"which should one use?\""
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:281
msgid ""
"The short answer is, \"whichever you are more comfortable with.\" This is a "
"feature specific to GDScript and not Godot scripting in general; The "
"languages prioritizes usability over performance."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:285
msgid ""
"On a technical level, integer comparisons (constant-time) will happen faster "
"than string comparisons (linear-time). If one wants to keep up other "
"languages' conventions though, then one should use integers."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:289
msgid ""
"The primary issue with using integers comes up when one wants to *print* an "
"enum value. As integers, attempting to print MY_ENUM will print ``5`` or "
"what-have-you, rather than something like ``\"MyEnum\"``. To print an "
"integer enum, one would have to write a Dictionary that maps the "
"corresponding string value for each enum."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:295
msgid ""
"If the primary purpose of using an enum is for printing values and one "
"wishes to group them together as related concepts, then it makes sense to "
"use them as strings. That way, a separate data structure to execute on the "
"printing is unnecessary."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:301
msgid ""
"AnimatedTexture vs. AnimatedSprite vs. AnimationPlayer vs. AnimationTree"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:303
msgid ""
"Under what circumstances should one use each of Godot's animation classes? "
"The answer may not be immediately clear to new Godot users."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:306
msgid ""
":ref:`AnimatedTexture <class_AnimatedTexture>` is a texture that the engine "
"draws as an animated loop rather than a static image. Users can manipulate..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:310
msgid "the rate at which it moves across each section of the texture (fps)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:312
msgid "the number of regions contained within the texture (frames)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:314
msgid ""
"Godot's :ref:`VisualServer <class_VisualServer>` then draws the regions in "
"sequence at the prescribed rate. The good news is that this involves no "
"extra logic on the part of the engine. The bad news is that users have very "
"little control."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:319
msgid ""
"Also note that AnimatedTexture is a :ref:`Resource <class_Resource>` unlike "
"the other :ref:`Node <class_Node>` objects discussed here. One might create "
"a :ref:`Sprite <class_Sprite>` node that uses AnimatedTexture as its "
"texture. Or (something the others can't do) one could add AnimatedTextures "
"as tiles in a :ref:`TileSet <class_TileSet>` and integrate it with a :ref:"
"`TileMap <class_TileMap>` for many auto-animating backgrounds that all "
"render in a single batched draw call."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:327
msgid ""
"The AnimatedSprite node, in combination with the :ref:`SpriteFrames "
"<class_SpriteFrames>` resource, allows one to create a variety of animation "
"sequences through spritesheets, flip between animations, and control their "
"speed, regional offset, and orientation. This makes them well-suited to "
"controlling 2D frame-based animations."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:333
msgid ""
"If one needs trigger other effects in relation to animation changes (for "
"example, create particle effects, call functions, or manipulate other "
"peripheral elements besides the frame-based animation), then will need to "
"use an :ref:`AnimationPlayer <class_AnimationPlayer>` node in conjunction "
"with the AnimatedSprite."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:339
msgid ""
"AnimationPlayers are also the tool one will need to use if they wish to "
"design more complex 2D animation systems, such as..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:342
msgid "**Cut-Out animations:** editing sprites' transforms at runtime."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:344
msgid ""
"**2D Mesh animations:** defining a region for the sprite's texture and "
"rigging a skeleton to it. Then one animates the bones which stretch and bend "
"the texture in proportion to the bones' relationships to each other."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:349
msgid "A mix of the above."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/data_preferences.rst:351
msgid ""
"While one needs an AnimationPlayer to design each of the individual "
"animation sequences for a game, it can also be useful to combine animations "
"for blending, i.e. enabling smooth transitions between these animations. "
"There may also be a hierarchical structure between animations that one plans "
"out for their object. These are the cases where the :ref:`AnimationTree "
"<class_AnimationTree>` shines. One can find an in-depth guide on using the "
"AnimationTree :ref:`here <doc_animation_tree>`."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:4
msgid "Logic preferences"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:6
msgid ""
"Ever wondered whether one should approach problem X with strategy Y or Z? "
"This article covers a variety of topics related to these dilemmas."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:10
msgid "Loading vs. preloading"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:12
msgid ""
"In GDScript, there exists the global :ref:`preload "
"<class_@GDScript_method_preload>` method. It loads resources as early as "
"possible to front-load the \"loading\" operations and avoid loading "
"resources while in the middle of performance-sensitive code."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:17
msgid ""
"Its counterpart, the :ref:`load <class_@GDScript_method_load>` method, loads "
"a resource only when it reaches the load statement. That is, it will load a "
"resource in-place which can cause slowdowns when it occurs in the middle of "
"sensitive processes. The ``load`` function is also an alias for :ref:"
"`ResourceLoader.load(path) <class_ResourceLoader_method_load>` which is "
"accessible to *all* scripting languages."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:24
msgid ""
"So, when exactly does preloading occur versus loading, and when should one "
"use either? Let's see an example:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:88
msgid ""
"Preloading allows the script to handle all the loading the moment one loads "
"the script. Preloading is useful, but there are also times when one doesn't "
"wish for it. To distinguish these situations, there are a few things one can "
"consider:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:93
msgid ""
"If one cannot determine when the script might load, then preloading a "
"resource, especially a scene or script, could result in further loads one "
"does not expect. This could lead to unintentional, variable-length load "
"times on top of the original script's load operations."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:98
msgid ""
"If something else could replace the value (like a scene's exported "
"initialization), then preloading the value has no meaning. This point isn't "
"a significant factor if one intends to always create the script on its own."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:102
msgid ""
"If one wishes only to 'import' another class resource (script or scene), "
"then using a preloaded constant is often the best course of action. However, "
"in exceptional cases, one my wish not to do this:"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:106
msgid ""
"If the 'imported' class is liable to change, then it should be a property "
"instead, initialized either using an ``export`` or a ``load`` (and perhaps "
"not even initialized until later)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:110
msgid ""
"If the script requires a great many dependencies, and one does not wish to "
"consume so much memory, then one may wish to, load and unload various "
"dependencies at runtime as circumstances change. If one preloads resources "
"into constants, then the only way to unload these resources would be to "
"unload the entire script. If they are instead loaded properties, then one "
"can set them to ``null`` and remove all references to the resource entirely "
"(which, as a :ref:`Reference <class_Reference>`-extending type, will cause "
"the resources to delete themselves from memory)."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:121
msgid "Large levels: static vs. dynamic"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:123
msgid ""
"If one is creating a large level, which circumstances are most appropriate? "
"Should they create the level as one static space? Or should they load the "
"level in pieces and shift the world's content as needed?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:127
msgid ""
"Well, the simple answer is , \"when the performance requires it.\" The "
"dilemma associated with the two options is one of the age-old programming "
"choices: does one optimize memory over speed, or vice versa?"
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:131
msgid ""
"The naive answer is to use a static level that loads everything at once. "
"But, depending on the project, this could consume a large amount of memory. "
"Wasting users' RAM leads to programs running slow or outright crashing from "
"everything else the computer tries to do at the same time."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:136
msgid ""
"No matter what, one should break larger scenes into smaller ones (to aid in "
"reusability of assets). Developers can then design a node that manages the "
"creation/loading and deletion/unloading of resources and nodes in real-time. "
"Games with large and varied environments or procedurally generated elements "
"often implement these strategies to avoid wasting memory."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:142
msgid ""
"On the flip side, coding a dynamic system is more complex, i.e. uses more "
"programmed logic, which results in opportunities for errors and bugs. If one "
"isn't careful, they can develop a system that bloats the technical debt of "
"the application."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:147
msgid "As such, the best options would be..."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:149
msgid "To use a static level for smaller games."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:151
msgid ""
"If one has the time/resources on a medium/large game, create a library or "
"plugin that can code the management of nodes and resources. If refined over "
"time, so as to improve usability and stability, then it could evolve into a "
"reliable tool across projects."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:156
msgid ""
"Code the dynamic logic for a medium/large game because one has the coding "
"skills, but not the time or resources to refine the code (game's gotta get "
"done). Could potentially refactor later to outsource the code into a plugin."
msgstr ""

#: ../../docs/getting_started/workflow/best_practices/logic_preferences.rst:161
msgid ""
"For an example of the various ways one can swap scenes around at runtime, "
"please see the :ref:`\"Change scenes manually\" "
"<doc_change_scenes_manually>` documentation."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:4
msgid "Canvas layers"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:7
msgid "Viewport and Canvas items"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:9
msgid ""
"Regular 2D nodes, such as :ref:`Node2D <class_Node2D>` or :ref:`Control "
"<class_Control>` both inherit from :ref:`CanvasItem <class_CanvasItem>`, "
"which is the base for all 2D nodes. CanvasItems can be arranged in trees. "
"Each item will inherit its parent's transform. This means that when the "
"parent is moved, the children will move too."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:16
msgid ""
"CanvasItem nodes, and nodes inheriting from them, are direct or indirect "
"children of a :ref:`Viewport <class_Viewport>`, and will be displayed "
"through it."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:19
msgid ""
"A Viewport has the property :ref:`Viewport.canvas_transform "
"<class_Viewport_property_canvas_transform>`, which allows applying a custom :"
"ref:`Transform2D <class_Transform2D>` transform to the CanvasItem hierarchy "
"it contains. Nodes such as :ref:`Camera2D <class_Camera2D>` work by changing "
"that transform."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:25
msgid ""
"Effects like scrolling are best achieved by manipulating the canvas "
"transform property. This approach is more efficient than moving the root "
"canvas item (and hence the whole scene)."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:28
msgid ""
"Usually though, we don't want *everything* in the game or app to be subject "
"to the canvas transform. Examples of this are:"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:31
msgid ""
"**Parallax Backgrounds**: Backgrounds that move slower than the rest of the "
"stage."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:33
msgid ""
"**UI**: Think of a user interface (UI) or Heads-up display (HUD) "
"superimposed on our view of the game world. We want a life counter, score "
"display and other elements to retain their screen positions even when our "
"view of the game world is changing."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:34
msgid ""
"**Transitions**: We may want visual effects used for transitions (fades, "
"blends) to remain at a fixed screen location."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:36
msgid "How can these problems be solved in a single scene tree?"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:39
msgid "CanvasLayers"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:41
msgid ""
"The answer is :ref:`CanvasLayer <class_CanvasLayer>`, which is a node that "
"adds a separate 2D rendering layer for all its children and grand-children. "
"Viewport children will draw by default at layer \"0\", while a CanvasLayer "
"will draw at any numeric layer. Layers with a greater number will be drawn "
"above those with a smaller number. CanvasLayers also have their own "
"transform and do not depend on the transform of other layers. This allows "
"the UI to be fixed in screen-space while our view on the game world changes."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:50
msgid ""
"An example of this is creating a parallax background. This can be done with "
"a CanvasLayer at layer \"-1\". The screen with the points, life counter and "
"pause button can also be created at layer \"1\"."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:54
msgid "Here's a diagram of how it looks:"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:58
msgid ""
"CanvasLayers are independent of tree order, and they only depend on their "
"layer number, so they can be instantiated when needed."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:61
msgid ""
"CanvasLayers aren't necessary to control the drawing order of nodes. The "
"standard way to ensuring that a node is  correctly drawn 'in front' or "
"'behind' others is to manipulate the order of the nodes in the scene panel. "
"Perhaps counterintuitively, the topmost nodes in the scene panel are drawn "
"on *behind* lower ones in the viewport. 2d nodes also have a property for "
"controlling their drawing order (see :ref:`Node2D.z_index "
"<class_Node2D_property_z_index>`)."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:4
msgid "Viewport and canvas transforms"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:9
msgid ""
"This is an overview of the 2D transforms going on for nodes from the moment "
"they draw their content locally to the time they are drawn onto the screen. "
"This overview discusses very low level details of the engine."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:14
msgid "Canvas transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:16
msgid ""
"As mentioned in the previous tutorial, :ref:`doc_canvas_layers`, every "
"CanvasItem node (remember that Node2D and Control based nodes use CanvasItem "
"as their common root) will reside in a *Canvas Layer*. Every canvas layer "
"has a transform (translation, rotation, scale, etc.) that can be accessed as "
"a :ref:`Transform2D <class_Transform2D>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:22
msgid ""
"Also covered in the previous tutorial, nodes are drawn by default in Layer "
"0, in the built-in canvas. To put nodes in a different layer, a :ref:"
"`CanvasLayer <class_CanvasLayer>` node can be used."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:27
msgid "Global canvas transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:29
msgid ""
"Viewports also have a Global Canvas transform (also a :ref:`Transform2D "
"<class_Transform2D>`). This is the master transform and affects all "
"individual *Canvas Layer* transforms. Generally, this transform is not of "
"much use, but is used in the CanvasItem Editor in Godot's editor."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:36
msgid "Stretch transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:38
msgid ""
"Finally, viewports have a *Stretch Transform*, which is used when resizing "
"or stretching the screen. This transform is used internally (as described "
"in :ref:`doc_multiple_resolutions`), but can also be manually set on each "
"viewport."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:43
msgid ""
"Input events received in the :ref:`MainLoop._input_event() "
"<class_MainLoop_method__input_event>` callback are multiplied by this "
"transform but lack the ones above. To convert InputEvent coordinates to "
"local CanvasItem coordinates, the :ref:`CanvasItem.make_input_local() "
"<class_CanvasItem_method_make_input_local>` function was added for "
"convenience."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:50
msgid "Transform order"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:52
msgid ""
"For a coordinate in CanvasItem local properties to become an actual screen "
"coordinate, the following chain of transforms must be applied:"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:58
msgid "Transform functions"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:60
msgid "Obtaining each transform can be achieved with the following functions:"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:63
#: ../../docs/tutorials/io/data_paths.rst:51
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:21
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:522
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:92
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:158
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:218
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:240
#: ../../docs/tutorials/misc/binary_serialization_api.rst:23
#: ../../docs/tutorials/misc/binary_serialization_api.rst:95
#: ../../docs/tutorials/misc/binary_serialization_api.rst:104
#: ../../docs/tutorials/misc/binary_serialization_api.rst:113
#: ../../docs/tutorials/misc/binary_serialization_api.rst:122
#: ../../docs/tutorials/misc/binary_serialization_api.rst:135
#: ../../docs/tutorials/misc/binary_serialization_api.rst:146
#: ../../docs/tutorials/misc/binary_serialization_api.rst:161
#: ../../docs/tutorials/misc/binary_serialization_api.rst:174
#: ../../docs/tutorials/misc/binary_serialization_api.rst:193
#: ../../docs/tutorials/misc/binary_serialization_api.rst:208
#: ../../docs/tutorials/misc/binary_serialization_api.rst:223
#: ../../docs/tutorials/misc/binary_serialization_api.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:267
#: ../../docs/tutorials/misc/binary_serialization_api.rst:298
#: ../../docs/tutorials/misc/binary_serialization_api.rst:313
#: ../../docs/tutorials/misc/binary_serialization_api.rst:322
#: ../../docs/tutorials/misc/binary_serialization_api.rst:333
#: ../../docs/tutorials/misc/binary_serialization_api.rst:343
#: ../../docs/tutorials/misc/binary_serialization_api.rst:362
#: ../../docs/tutorials/misc/binary_serialization_api.rst:374
#: ../../docs/tutorials/misc/binary_serialization_api.rst:386
#: ../../docs/tutorials/misc/binary_serialization_api.rst:399
#: ../../docs/tutorials/misc/binary_serialization_api.rst:410
#: ../../docs/tutorials/misc/binary_serialization_api.rst:421
#: ../../docs/tutorials/misc/binary_serialization_api.rst:429
#: ../../docs/tutorials/misc/binary_serialization_api.rst:442
#: ../../docs/tutorials/misc/binary_serialization_api.rst:455
#: ../../docs/tutorials/misc/binary_serialization_api.rst:470
msgid "Type"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:63
msgid "Transform"
msgstr "התמרה"

#: ../../docs/tutorials/2d/2d_transforms.rst:65
msgid "CanvasItem"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:65
msgid ""
":ref:`CanvasItem.get_global_transform() "
"<class_CanvasItem_method_get_global_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:67
msgid "CanvasLayer"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:67
msgid ""
":ref:`CanvasItem.get_canvas_transform() "
"<class_CanvasItem_method_get_canvas_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:69
msgid "CanvasLayer+GlobalCanvas+Stretch"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:69
msgid ""
":ref:`CanvasItem.get_viewport_transform() "
"<class_CanvasItem_method_get_viewport_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:72
msgid ""
"Finally, then, to convert a CanvasItem local coordinates to screen "
"coordinates, just multiply in the following order:"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:84
msgid ""
"Keep in mind, however, that it is generally not desired to work with screen "
"coordinates. The recommended approach is to simply work in Canvas "
"coordinates (``CanvasItem.get_global_transform()``), to allow automatic "
"screen resolution resizing to work properly."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:90
msgid "Feeding custom input events"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:92
msgid ""
"It is often desired to feed custom input events to the scene tree. With the "
"above knowledge, to correctly do this, it must be done the following way:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:4
msgid "Using tilemaps"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:9
msgid ""
"A tilemap is a grid of tiles used to create a game's layout. There are "
"several benefits to using :ref:`TileMap <class_TileMap>` nodes to design "
"your levels. First, they make it possible to draw the layout by \"painting\" "
"the tiles onto a grid, which is much faster than placing individual :ref:"
"`Sprite <class_Sprite>` nodes one by one. Second, they allow for much larger "
"levels because they are optimized for drawing large numbers of tiles. "
"Finally, you can add collision, occlusion, and navigation shapes to tiles, "
"adding additional functionality to the TileMap."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:23
msgid ""
"This demo we'll use the following tiles taken from Kenney's \"Abstract "
"Platformer\" art pack. You can find the complete set `here <https://kenney."
"nl/assets/abstract-platformer>`_ but for this demo we'll stick to this small "
"set."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:29
msgid "Create a new project and place the above image in the project folder."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:31
msgid ""
"When using a tileset, it's important that adjacent tiles match up. Godot's "
"default is to import 2D images using an interpolated \"filter\" mode, which "
"will result in ugly borders between the tiles. Select the image and click "
"the Import tab. Turn off ``Filter`` and click \"Reimport\". See :ref:"
"`doc_import_images` for details."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:37
msgid "TileMap node"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:39
msgid ""
"Add a new :ref:`TileMap <class_TileMap>` node to the scene. By default, a "
"TileMap uses a square grid of tiles. You can also use a perspective-based "
"\"Isometric\" mode or define your own custom tile shape."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:45
msgid ""
"Under the \"Cell\" section in the Inspector are many properties you can "
"adjust to customize your tilemap's behavior:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:52
msgid "``Cell Size``"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:51
msgid ""
"This defines the size of the grid. This should match the pixel size of your "
"tiles. The default value is ``(64, 64)``."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:56
msgid "``YSort``"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:55
msgid ""
"This causes tiles to be drawn in order of their ``Y`` position, so that "
"\"lower\" tiles are drawn on top of \"higher\" ones."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:59
msgid "``Half Offset`` and ``Tile Origin``"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:59
msgid ""
"These properties affect the position of the tile relative to the grid "
"position."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:63
msgid "``Quadrant``"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:62
msgid ""
"Defines the chunk size used for batched drawing. This can negatively affect "
"performance. Don't change it unless you know what you're doing."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:66
#, fuzzy
msgid "``Custom Transform``"
msgstr "התמרה"

#: ../../docs/tutorials/2d/using_tilemaps.rst:66
msgid "Used to alter the tile's shape. Use this if you have non-square tiles."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:68
msgid "All of these options can be left at their defaults for this demo."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:71
#, fuzzy
msgid "Creating a TileSet"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/2d/using_tilemaps.rst:73
msgid ""
"Once you've configured your tilemap, it's time to add a :ref:`TileSet "
"<class_TileSet>`. A TileSet is a :ref:`Resource <class_Resource>` that "
"contains the data about your tiles - their   textures, collision shapes, and "
"other properties. When the game runs, the TileMap combines the individual "
"tiles into a single object."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:79
msgid ""
"To add a new TileSet, click on the \"Tile Set\" property and select \"New "
"TileSet\"."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:84
msgid ""
"Click on the TileSet property, and the \"TileSet\" panel will open at the "
"bottom of the editor window:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:89
msgid ""
"First, you need to add the texture(s) that you'll use for the tiles. Click "
"the \"Add Texture(s) to TileSet\" button and select the ``tilesheet.png`` "
"image."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:92
msgid ""
"Next, click \"New Single Tile\" and drag in the image to select the tile you "
"want. Click the \"Enable Snap\" button to make it easier to select the "
"entire tile. A yellow rectangle appears around the selected tile."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:98
msgid ""
"Click on the TileMap in the scene tree, and you'll see that the newly "
"created tile now appears on the right side. Click in the viewport and you "
"can place tiles. Right-click to remove them."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:104
msgid ""
"It's easy to accidentally select and move the tilemap node. To avoid this, "
"use the node's lock button:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:112
msgid ""
"If you're making a map that needs collisions - walls, floor, or other "
"obstacles, for example - then you'll need to add collision shapes to any "
"tiles that you want to be considered \"solid\"."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:116
msgid ""
"Click \"TileSet\" at the bottom of the editor window to return to the "
"tileset tool. Click the tile you previously defined (outlined in yellow). "
"Select the \"Collision\" tab and click the \"Create a new rectangle\" "
"button. Make sure you still have grid snap enabled, then click and drag in "
"the tile. A square collision shape appears in light blue:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:124
msgid ""
"You can add occlusion and navigation shapes to the tile in the same way."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:127
msgid "Atlas tiles"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:129
msgid ""
"Rather than adding individual tiles one at a time, you can define a group of "
"tiles all at once using an atlas. This also allows you to randomly generate "
"tiles from the group."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:133
msgid "Click \"New Atlas\" and drag to select the entire tile sheet."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:137
msgid ""
"If you haven't already, make sure to change the \"Step\" in the snap "
"settings to `(64, 64)`, or your tiles may be chopped into smaller pieces. "
"You can find this in the Inspector:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:143
msgid ""
"Once you've defined the atlas you can add collision shapes to the individual "
"tiles as before. You can also click \"Icon\" to select one of the tiles to "
"represent the atlas."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:147
msgid ""
"Back in the TileMap, you can select the atlas tile and you'll see all of the "
"tiles it contains:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:152
msgid ""
"In addition to saving time when defining the tiles, this can help by "
"grouping similar tiles together when you're working with a large number of "
"tiles."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:156
msgid "Random tile priorities"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:158
msgid ""
"When drawing with atlas tiles, enabling the \"Use priority\" option causes "
"tiles to be selected at random. By default, each tile in the tileset has an "
"equal likelihood of occurring. You can change the likelihood by setting "
"different priorities for each tile. For example, a tile with priority 2 is "
"twice as likely to be selected as a tile with priority 1, and a tile with "
"priority 3 is 50% more likely to be selected than a tile with priority 2."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:166
msgid "Autotiles"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:168
msgid ""
"Autotiles allow you to define a group of tiles, then add rules to control "
"which tile gets used for drawing based on the content of adjacent cells."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:171
msgid ""
"Click \"New Autotile\" and drag to select the tiles you wish to use. You can "
"add collisions, occlusion, navigation shapes, tile priorties, and select an "
"icon tile in the same manner as for atlas tiles."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:175
msgid ""
"Tile selection is controlled by bitmasks. Bitmasks can be added by clicking "
"\"Bitmask\", then clicking parts of the tiles to add or remove bits in the "
"mask. Left-clicking an area of the tile adds a bit, right-click removes \"off"
"\", and shift-left-click sets an \"ignore\" bit."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:180
msgid ""
"Whenever Godot updates a cell using an autotile, it first creates a pattern "
"based on which adjacent cells are already set. Then, it searches the "
"autotile for a single tile with a bitmask matching the created pattern. If "
"no matching bitmask is found, the \"icon\" tile will be used instead. If "
"more than one matching bitmask is found, one of them will be selected "
"randomly, using the tile priorities."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:187
msgid ""
"The rules for matching a bitmask to a pattern depend on the tileset's "
"autotile bitmask mode. This can be set in the \"Inspector\" tab, under the "
"\"Selected Tile\" heading. Allowed values are \"2x2\", \"3x3 (minimal)\", "
"and \"3x3\"."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:191
msgid ""
"All \"on\" and \"off\" bits must be satisfied for a bitmask to match, but "
"\"ignore\" bits are ignored."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:195
msgid "2x2"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:197
msgid "In 2x2 mode, each bitmask contains four bits, one for each corner."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:199
msgid ""
"Where a bit is \"on\", all cells connected to that corner must be filled "
"using the same autotile, in order for the bitmask to match. For example, if "
"the top-left bit is set, the cell directly above, directly left, and "
"diagonally above-left must be filled."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:204
msgid ""
"Where a bit is \"off\", at least one cell connected to that corner must not "
"be set using the same autotile."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:207
msgid ""
"At least one bit must be set for the tile to be used, so a total of 15 tiles "
"would be needed to provide exactly one tile for each arrangement that this "
"mode can test for."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:211
msgid ""
"2x2 mode can only match cells that are part of a 2-by-2 block - cells with "
"no neighbors and lines only one cell wide are not supported."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:215
msgid "3x3 (minimal)"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:217
msgid ""
"In 3x3 (minimal) mode, each bitmask contains 9 bits (4 corners, 4 edges, 1 "
"center)."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:220
msgid "The 4 corner bits work the same as in 2x2 mode."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:222
msgid ""
"When an edge bit is \"on\", the cell which shares that edge must be filled. "
"When an edge bit is \"off\", the cell which shares that edge must be empty."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:225
msgid "The center bit should be \"on\" for any tile you wish to use."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:227
msgid ""
"Note that in this mode, it makes no sense for a corner bit to be \"on\" when "
"either edge bit adjacent to it is not \"on\"."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:230
msgid ""
"A total of 47 tiles would be needed to provide exactly one bitmask for each "
"arrangement that this mode can test for."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:235
msgid "3x3"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:237
msgid ""
"In 3x3 mode, each bitmaks contains 9 bits (4 corners, 4 edges, 1 center)"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:239
msgid ""
"Each bit checks a single adjacent cell. Corner bits only check diagonally "
"adjacent cells. The center bit should be \"on\" for any tile you wish to use."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:242
msgid ""
"A total of 256 tiles would be needed to provide exactly one bitmask for each "
"arrangement that this mode can test for."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:247
#, fuzzy
msgid "Disabling autotile"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/2d/using_tilemaps.rst:249
msgid ""
"When using an autotile, it is possible to turn of the autotile behaviour and "
"select tiles manually, by clicking \"Disable Autotile\" at the top of the "
"tile selection window."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:254
msgid "Autotile binding"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:256
msgid ""
"By default, autotile only checks for adjacent cells filled using the same "
"autotile. This behaviour can be overridden in order to have autotiles bind "
"to each other, or even bind to empty cells. At present, this can only be "
"done through scripting. You will need to add a script to your tileset, and "
"define a function named \"_is_tile_bound(drawn_id, neighbor_id)\". This "
"function will be called for each adjacent cell that does not contain the "
"same autotile, and should return true if you want the drawn cell to \"bind\" "
"to the neighbor cell. You can find the id of an autotile using "
"\"find_tile_by_name(name)\", empty cells are given an id of -1."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:266
msgid ""
"Note that to use this in the editor, the script should start with a \"tool\" "
"declaration, and you may need to close and reload the scene for these "
"changes to take effect."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:271
msgid "Tips and tricks"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:273
msgid ""
"If you're using a :ref:`Camera2D <class_Camera2D>` to scroll your level, you "
"may notice lines appearing between your tiles. To fix this, open Project "
"Settings and enable \"Use Pixel Snap\" in the \"Rendering/Quality\" section."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:277
msgid ""
"You can flip and rotate tiles using the icons at the top right of the editor."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:279
msgid ""
"To draw straight lines, hold :kbd:`Shift` while clicking and dragging a tile."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:281
msgid ""
"Tools such as copy, paste, and bucket fill, can be found in the \"TileMap\" "
"menu in the upper-right."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:4
msgid "Particle systems (2D)"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:9
msgid ""
"A simple (but flexible enough for most uses) particle system is provided. "
"Particle systems are used to simulate complex physical effects, such as "
"sparks, fire, magic particles, smoke, mist, etc."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:13
msgid ""
"The idea is that a \"particle\" is emitted at a fixed interval and with a "
"fixed lifetime. During its lifetime, every particle will have the same base "
"behavior. What makes each particle different from the rest and provides a "
"more organic look is the \"randomness\" associated with each parameter. In "
"essence, creating a particle system means setting base physics parameters "
"and then adding randomness to them."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:21
msgid "Particle nodes"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:23
msgid ""
"Godot provides two different nodes for 2D particles, :ref:"
"`class_Particles2D` and :ref:`class_CPUParticles2D`. Particles2D is more "
"advanced and uses the GPU to process particle effects, but that limits it to "
"higher end graphics API, and in our case to the GLES3 renderer. For projects "
"using the GLES2 backend, CPUParticles2D is a CPU-driven option with near "
"feature parity with Particles2D, but lesser performance. While Particles2D "
"is configured via a :ref:`class_ParticlesMaterial` (and optionally with a "
"custom shader), the matching options are provided via node properties in "
"CPUParticles2D (with the exception of the trail settings). You can convert a "
"Particles2D node into a CPUParticles2D node by clicking on the node in the "
"inspector, and selecting \"Convert to CPUParticles2D\" in the \"Particles\" "
"menu of the toolbar."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:36
msgid ""
"The rest of this tutorial is going to use the Particles2D node. First, add a "
"Particles2D node to your scene. After creating that node you will notice "
"that only a white dot was created, and that there is a warning icon next to "
"your Particles2D node in the inspector. This is because the node needs a "
"ParticlesMaterial to function."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:42
msgid "ParticlesMaterial"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:44
msgid ""
"To add a process material to your particles node, go to ``Process Material`` "
"in your inspector panel. Click on the box next to ``Material``, and from the "
"dropdown menu select ``New ParticlesMaterial``."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:50
msgid "Your Particles2D node should now be emitting white points downward."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:56
msgid "Texture"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:58
msgid ""
"A particle system uses a single texture (in the future this might be "
"extended to animated textures via spritesheet). The texture is set via the "
"relevant texture property:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:65
msgid "Time parameters"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:68
msgid "Lifetime"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:70
msgid ""
"The time in seconds that every particle will stay alive. When lifetime ends, "
"a new particle is created to replace it."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:73
msgid "Lifetime: 0.5"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:77
msgid "Lifetime: 4.0"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:82
msgid "One Shot"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:84
msgid ""
"When enabled, a Particles2D node will emit all of its particles once and "
"then never again."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:88
msgid "Preprocess"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:90
msgid ""
"Particle systems begin with zero particles emitted, then start emitting. "
"This can be an inconvenience when loading a scene and systems like a torch, "
"mist, etc. begin emitting the moment you enter. Preprocess is used to let "
"the system process a given number of seconds before it is actually drawn the "
"first time."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:97
msgid "Speed Scale"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:99
msgid ""
"The speed scale has a default value of ``1`` and is used to adjust the speed "
"of a particle system. Lowering the value will make the particles slower "
"while increasing the value will make the particles much faster."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:104
msgid "Explosiveness"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:106
msgid ""
"If lifetime is ``1`` and there are 10 particles, it means a particle will be "
"emitted every 0.1 seconds. The explosiveness parameter changes this, and "
"forces particles to be emitted all together. Ranges are:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:110
msgid "0: Emit particles at regular intervals (default value)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:111
msgid "1: Emit all particles simultaneously."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:113
msgid ""
"Values in the middle are also allowed. This feature is useful for creating "
"explosions or sudden bursts of particles:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:119
msgid "Randomness"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:121
msgid ""
"All physics parameters can be randomized. Random values range from ``0`` to "
"``1``. The formula to randomize a parameter is:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:129
msgid "Fixed FPS"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:131
msgid ""
"This setting can be used to set the particle system to render at a fixed "
"FPS. For instance, changing the value to ``2`` will make the particles "
"render at 2 frames per second. Note this does not slow down the particle "
"system itself."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:136
msgid "Fract Delta"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:138
msgid "This can be used to turn Fract Delta on or off."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:141
msgid "Drawing parameters"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:144
msgid "Visibility Rect"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:147
msgid ""
"The visibility rectangle controls the visibility of the particles on screen. "
"If this rectangle is outside of the viewport, the engine will not render the "
"particles on screen."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:149
msgid ""
"The rectangle's ``W`` and ``H`` properties respectively control its Width "
"and its Height. The ``X`` and ``Y`` properties control the position of the "
"upper-left corner of the rectangle, relative to the particle emitter."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:153
msgid ""
"You can have Godot generate a Visibility Rect automatically using the "
"toolbar above the 2d view. To do so, select the Particles2D node and Click "
"``Particles > Generate Visibility Rect``. Godot will simulate the "
"Particles2D node emitting particles for a few seconds and set the rectangle "
"to fit the surface the particles take."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:155
msgid ""
"You can control the emit duration with the ``Generation Time (sec)`` option. "
"The maximum value is 25 seconds. If you need more time for your particles to "
"move around, you can temporarily change the ``preprocess`` duration on the "
"Particles2D node."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:158
msgid "Local Coords"
msgstr "נקודות ציון מקומיות"

#: ../../docs/tutorials/2d/particle_systems_2d.rst:160
msgid ""
"By default this option is on, and it means that the space that particles are "
"emitted to is relative to the node. If the node is moved, all particles are "
"moved with it:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:166
msgid ""
"If disabled, particles will emit to global space, meaning that if the node "
"is moved, already emitted particles are not affected:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:172
msgid "Draw Order"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:174
msgid ""
"This controls the order in which individual particles are drawn. ``Index`` "
"means particles are drawn according to their emission order (default). "
"``Lifetime`` means they are drawn in order of remaining lifetime."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:179
msgid "ParticlesMaterial settings"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:198
msgid "Spread"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:200
msgid ""
"This parameter is the angle in degrees which will be randomly added in "
"either direction to the base ``Direction``. A spread of ``180`` will emit in "
"all directions (+/- 180). For spread to do anything the \"Initial Velocity\" "
"parameter must be greater than 0."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:208
msgid "Gravity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:210
msgid "The gravity applied to every particle."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:215
msgid "Initial Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:217
msgid ""
"Initial velocity is the speed at which particles will be emitted (in pixels/"
"sec). Speed might later be modified by gravity or other accelerations (as "
"described further below)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:224
msgid "Angular Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:226
msgid "Angular velocity is the initial angular velocity applied to particles."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:229
msgid "Spin Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:231
msgid ""
"Spin velocity is the speed at which particles turn around their center (in "
"degrees/sec)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:237
msgid "Orbit Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:239
msgid "Orbit velocity is used to make particles turn around their center."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:244
msgid "Linear Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:246
msgid "The linear acceleration applied to each particle."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:249
msgid "Radial Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:251
msgid ""
"If this acceleration is positive, particles are accelerated away from the "
"center. If negative, they are absorbed towards it."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:257
msgid "Tangential Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:259
msgid ""
"This acceleration will use the tangent vector to the center. Combining with "
"radial acceleration can do nice effects."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:265
msgid "Damping"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:267
msgid ""
"Damping applies friction to the particles, forcing them to stop. It is "
"especially useful for sparks or explosions, which usually begin with a high "
"linear velocity and then stop as they fade."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:274
msgid "Angle"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:276
msgid ""
"Determines the initial angle of the particle (in degrees). This parameter is "
"mostly useful randomized."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:282
#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:87
msgid "Scale"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:284
msgid "Determines the initial scale of the particles."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:289
msgid "Color"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:291
msgid "Used to change the color of the particles being emitted."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:294
msgid "Hue variation"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:296
msgid ""
"The ``Variation`` value sets the initial hue variation applied to each "
"particle. The ``Variation Random`` value controls the hue variation "
"randomness ratio."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:301
msgid "Emission Shapes"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:303
msgid ""
"ParticlesMaterials allow you to set an Emission Mask, which dictates the "
"area and direction in which particles are emitted. These can be generated "
"from textures in your project."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:307
msgid ""
"Ensure that a ParticlesMaterial is set, and the Particles2D node is "
"selected. A \"Particles\" menu should appear in the Toolbar:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:312
msgid "Open it and select \"Load Emission Mask\":"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:316
msgid "Then select which texture you want to use as your mask:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:320
msgid "A dialog box with several settings will appear."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:323
msgid "Emission Mask"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:325
msgid "Three types of emission masks can be generated from a texture:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:327
msgid ""
"Solid Pixels: Particles will spawn from any area of the texture, excluding "
"transparent areas."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:332
msgid ""
"Border Pixels: Particles will spawn from the outer edges of the texture."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:336
msgid ""
"Directed Border Pixels: Similar to Border Pixels, but adds extra information "
"to the mask to give particles the ability to emit away from the borders. "
"Note that an ``Initial Velocity`` will need to be set in order to utilize "
"this."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:344
msgid "Emission Colors"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:346
msgid ""
"``Capture from Pixel`` will cause the particles to inherit the color of the "
"mask at their spawn points."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:348
msgid ""
"Once you click \"OK\", the mask will be generated and set to the "
"ParticlesMaterial, under the ``Emission Shape`` section:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:352
msgid ""
"All of the values within this section have been automatically generated by "
"the \"Load Emission Mask\" menu, so they should generally be left alone."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:355
msgid ""
"An image should not be added to ``Point Texture`` or ``Color Texture`` "
"directly. The \"Load Emission Mask\" menu should always be used instead."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:4
msgid "2D movement overview"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:9
msgid ""
"Every beginner has been there: \"How do I move my character?\" Depending on "
"the style of game you're making, you may have special requirements, but in "
"general the movement in most 2D games is based on a small number of designs."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:13
msgid ""
"We'll use :ref:`KinematicBody2D <class_KinematicBody2D>` for these examples, "
"but the principles will apply to other node types (Area2D, RigidBody2D) as "
"well."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:19
#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:22
#: ../../docs/tutorials/animation/2d_skeletons.rst:30
#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:21
#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:12
#: ../../docs/tutorials/platform/customizing_html5_shell.rst:32
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:40
msgid "Setup"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:21
msgid ""
"Each example below uses the same scene setup. Start with a "
"``KinematicBody2D`` with two children: ``Sprite`` and ``CollisionShape2D``. "
"You can use the Godot icon (\"icon.png\") for the Sprite's texture or use "
"any other 2D image you have."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:25
msgid ""
"Open ``Project -> Project Settings`` and select the \"Input Map\" tab. Add "
"the following input actions (see :ref:`InputEvent <doc_inputevent>` for "
"details):"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:31
msgid "8-way movement"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:33
msgid ""
"In this scenario, you want the user to press the four directional keys (up/"
"left/down/right or W/A/S/D) and move in the selected direction. The name \"8-"
"way movement\" comes from the fact that the player can move diagonally by "
"pressing two keys at the same time."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:39
msgid "Add a script to the kinematic body and add the following code:"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:103
msgid ""
"In the ``get_input()`` function, we check for the four key events and sum "
"them up to get the velocity vector. This has the benefit of making two "
"opposite keys cancel each other out, but will also result in diagonal "
"movement being faster due to the two directions being added together."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:108
msgid ""
"We can prevent that if we *normalize* the velocity, which means we set its "
"*length* to ``1``, and multiply by the desired speed."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:111
msgid ""
"If you've never used vector math before, or need a refresher, you can see an "
"explanation of vector usage in Godot at :ref:`doc_vector_math`."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:116
msgid ""
"If the code above does nothing when you press the keys, double-check that "
"you've set up input actions correctly as described in the :ref:"
"`doc_2d_movement_setup` part of this tutorial."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:121
msgid "Rotation + movement"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:123
msgid ""
"This type of movement is sometimes called \"Asteroids-style\" because it "
"resembles how that classic arcade game worked. Pressing left/right rotates "
"the character, while up/down moves it forward or backward in whatever "
"direction it's facing."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:198
msgid ""
"Here we've added two new variables to track our rotation direction and "
"speed. Again, pressing both keys at once will cancel out and result in no "
"rotation. The rotation is applied directly to the body's ``rotation`` "
"property."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:202
msgid ""
"To set the velocity, we use the ``Vector2.rotated()`` method, so that it "
"points in the same direction as the body. ``rotated()`` is a useful vector "
"function that you can use in many circumstances where you would otherwise "
"need to apply trigonometric functions."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:208
msgid "Rotation + movement (mouse)"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:210
msgid ""
"This style of movement is a variation of the previous one. This time, the "
"direction is set by the mouse position instead of the keyboard. The "
"character will always \"look at\" the mouse pointer. The forward/back inputs "
"remain the same, however."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:269
msgid ""
"Here we're using the :ref:`Node2D <class_Node2D>` ``look_at()`` method to "
"point the player towards a given position. Without this function, you could "
"get the same effect by setting the angle like this:"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:284
msgid "Click-and-move"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:286
msgid ""
"This last example uses only the mouse to control the character. Clicking on "
"the screen will cause the player to move to the target location."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:343
msgid ""
"Note the ``distance_to()`` check we make prior to movement. Without this "
"test, the body would \"jitter\" upon reaching the target position, as it "
"moves slightly past the position and tries to move back, only to move too "
"far and repeat."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:348
msgid ""
"Uncommenting the ``look_at()`` line will also turn the body to point in its "
"direction of motion if you prefer."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:351
msgid ""
"This technique can also be used as the basis of a \"following\" character. "
"The ``target`` position can be that of any object you want to move to."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:357
msgid ""
"You may find these code samples useful as starting points for your own "
"projects. Feel free to use them and experiment with them to see what you can "
"make."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:360
msgid ""
"You can download this sample project here: :download:`2D_movement_demo.zip "
"<files/2D_movement_demo.zip>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:4
msgid "2D lights and shadows"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:9
msgid ""
"This tutorial explains how the 2D lighting works in the `lights and shadows "
"<https://github.com/godotengine/godot-demo-projects/tree/master/2d/"
"lights_and_shadows>`_ demo project. It begins with a brief description of "
"the resources used in the final demo and then describes how to make a scene "
"like the demo step by step."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:16
msgid ""
"All the resources for this tutorial can be found in the `official demo "
"repository <https://github.com/godotengine/godot-demo-projects>`_ on GitHub. "
"I suggest you download it before starting. Alternatively, it can be "
"downloaded from the Project Manager. Launch Godot and in the top bar select "
"\"Templates\" and search for \"2D Lights and Shadows Demo\"."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:24
msgid ""
"For this demo we use four textures: two for the lights, one for the shadow "
"casters, and one for the background. I've included links to them all here if "
"you want to download them separately from the demo."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:28
msgid ""
"The first is the background image (`background.png <https://raw."
"githubusercontent.com/godotengine/godot-demo-projects/master/2d/"
"lights_and_shadows/background.png>`_) used in the demo. You do not "
"necessarily need a background, but we use one for the demo."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:31
msgid ""
"The second is a plain black image (`caster.png <https://raw."
"githubusercontent.com/godotengine/godot-demo-projects/master/2d/"
"lights_and_shadows/caster.png>`_) to use as our shadow caster object. For a "
"top down game this could be a wall or any other object that casts a shadow."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:35
msgid ""
"Next is the light itself (`light.png <https://raw.githubusercontent.com/"
"godotengine/godot-demo-projects/master/2d/lights_and_shadows/light.png>`_). "
"If you click the link you will notice how large it is. The image you use for "
"a light should cover the area you want your light to cover. This image is "
"1024x1024 pixels, so you should use it to cover 1024x1024 pixels in your "
"game."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:40
msgid ""
"Lastly, we have the spotlight image (`spot.png <https://raw."
"githubusercontent.com/godotengine/godot-demo-projects/master/2d/"
"lights_and_shadows/spot.png>`_). The demo uses a blob to show where the "
"light is and the larger light image to show the effect of the light upon the "
"rest of the scene."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:52
msgid "The demo uses four different nodes:"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:49
msgid ":ref:`CanvasModulate <class_CanvasModulate>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:50
msgid ":ref:`Sprite <class_Sprite>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:51
msgid ":ref:`Light2D <class_Light2D>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:52
msgid ":ref:`LightOccluder2D <class_LightOccluder2D>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:54
msgid ""
":ref:`CanvasModulate<class_CanvasModulate>` is used to darken the scene."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:56
msgid ""
":ref:`Sprites <class_Sprite>` are used to display the textures for the light "
"blobs, the background, and for the shadow casters."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:59
msgid ""
":ref:`Light2Ds <class_Light2D>` are used to light the scene. The way a light "
"typically works is by adding a selected texture over the rest of the scene "
"to simulate lighting. But it can be used in other ways, for example masking "
"out parts of the scene."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:63
msgid ""
":ref:`LightOccluder2Ds <class_LightOccluder2D>` are used to tell the shader "
"which parts of the scene cast shadows. The shadows appear only on areas "
"covered by the :ref:`Light2D <class_Light2D>` and their direction is based "
"on the center of the :ref:`Light <class_Light2D>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:70
msgid ""
":ref:`Lights <class_Light2D>` cover the entire extent of their respective "
"Texture. They use additive blending to add the color of their texture to the "
"scene."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:75
msgid ""
":ref:`Lights <class_Light2D>` have four ``Modes``: ``Add``, ``Sub``, "
"``Mix``, and ``Mask``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:77
msgid ""
"``Add`` adds the color of the light texture to the scene. It brightens the "
"area under the light."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:79
msgid ""
"``Sub`` subtracts the color of the light from the scene. It darkens the area "
"under the light."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:81
msgid ""
"``Mix`` mixes the color of the light with the underlying scene. The "
"resulting brightness is halfway between the color of the light and the color "
"underneath."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:84
msgid ""
"``Mask`` is used to mask out areas that are covered by the light. Masked out "
"areas are hidden or revealed based on the color of the light."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:87
msgid ""
"For the demo the lights have two components, the :ref:`Light "
"<class_Light2D>` itself (which is the effect of the light), and a :ref:"
"`Sprite <class_Sprite>` blob which is an image showing the location of the "
"light source. A child :ref:`Sprite <class_Sprite>` is not necessary to make "
"a :ref:`Light <class_Light2D>` work."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:95
msgid "Shadows"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:97
msgid ""
"Shadows are made by intersecting a :ref:`Light <class_Light2D>` with a :ref:"
"`LightOccluder2D <class_LightOccluder2D>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:99
msgid ""
"By default shadows are turned off. To turn them on click on the :ref:`Light "
"<class_Light2D>` and under the Shadows section check ``Enabled``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:102
msgid ""
"In the demo we are using a :ref:`Sprite <class_Sprite>` with a Texture on it "
"to make the \"Shadow Casters\", but in reality all you need is a couple of :"
"ref:`LightOccluder2Ds <class_LightOccluder2D>`. By itself the :ref:"
"`LightOccluder2D <class_LightOccluder2D>` looks like a dark spot and in this "
"demo the :ref:`Sprite <class_Sprite>` is just a black square."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:110
msgid ""
"Now that we have covered the basics of the nodes being used, we can now walk "
"step by step through the process of making a scene like the one found in the "
"demo."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:113
msgid ""
"First add a :ref:`Sprite <class_Sprite>` and set its texture to the "
"`background image <https://raw.githubusercontent.com/godotengine/godot-demo-"
"projects/master/2d/lights_and_shadows/background.png>`_. For your game this "
"can be any background you choose. For this style of shadow it is most likely "
"to be a floor texture."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:118
msgid ""
"Next create three :ref:`Light2D's <class_Light2D>` and set their textures to "
"the `light image <https://raw.githubusercontent.com/godotengine/godot-demo-"
"projects/master/2d/lights_and_shadows/light.png>`_. You can alter their "
"color in the top section. By default shadows are turned off and the ``mode`` "
"is set to ``add``. This means that each light adds its own color to whatever "
"is underneath."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:124
msgid ""
"Next add a child :ref:`Sprite <class_Sprite>` to each of the :ref:`Light "
"<class_Light2D>` nodes, and set the :ref:`Sprite's <class_Sprite>` texture "
"to the `blob image <https://raw.githubusercontent.com/godotengine/godot-demo-"
"projects/master/2d/lights_and_shadows/spot.png>`_. Each of these should stay "
"centered on the :ref:`Light <class_Light2D>` node. The blob is the image of "
"the light itself while the :ref:`Light <class_Light2D>` shows the effect "
"that the light has on the scene. The :ref:`LightOccluder2D's "
"<class_LightOccluder2D>` will treat the position of the light as the center "
"of the :ref:`Light <class_Light2D>` node, which is why we want the blob to "
"be centered on its parent :ref:`Light <class_Light2D>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:133
msgid ""
"At the time of writing, 3.0 is the stable release version. The 3.1 "
"development branch contains many changes to the animation system, so the "
"animations in the demo will not be covered here. See :ref:"
"`doc_introduction_2d_animation` for more information."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:137
msgid ""
"Right now the scene should look too bright. This is because all three lights "
"are adding color to the scene. This is why the demo uses a :ref:"
"`CanvasModulate <class_CanvasModulate>` in the scene. The :ref:"
"`CanvasModulate <class_CanvasModulate>` multiples the entire viewport by a "
"specific color."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:141
msgid ""
"Add a :ref:`CanvasModulate <class_CanvasModulate>` to the scene and set its "
"color to ``rgb(70, 70, 70)``. This will make the scene sufficiently dark to "
"see the effects of the lights distinctly."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:146
msgid "Now we add the shadow casters."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:148
msgid ""
"The demo uses a :ref:`Node <class_Node2D>` named \"casters\" to organize the "
"shadow casters. Add a :ref:`Node2D <class_Node2D>` to the scene. It will be "
"used to group all the shadow casters together. This way we can show and hide "
"them all at the same time."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:152
msgid ""
"Each shadow caster is made of a :ref:`Sprite <class_Sprite>`, with a :ref:"
"`LightOccluder2D <class_LightOccluder2D>` child. For the demo the :ref:"
"`Sprite <class_Sprite>` has a texture set to the `caster image <https://raw."
"githubusercontent.com/godotengine/godot-demo-projects/master/2d/"
"lights_and_shadows/caster.png>`_ and nothing else. The child :ref:"
"`LightOccluder2D <class_LightOccluder2D>` is where all the magic happens. In "
"a game the :ref:`Sprite <class_Sprite>` could be more than a black box; it "
"could be an image of whatever object is casting the shadow: a wall, a "
"magical chest, or anything else."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:160
msgid ""
":ref:`LightOccluder2Ds <class_LightOccluder2D>` tell the game what shape the "
"occluder has. They hold an :ref:`OccluderPolygon2D "
"<class_OccluderPolygon2D>`, which is a container for a polygon and some "
"other information. For this demo, since our wall is a square, we set "
"``Polygon`` to a square. The other default settings are fine."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:165
msgid ""
"The first setting, ``Closed`` can be either ``on`` or ``off``. A closed "
"polygon occludes light coming from all directions. An open polygon only "
"occludes light from one direction"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:168
msgid ""
"``Cull Mode`` lets you select which direction gets culled. The default is "
"``Disabled``, meaning the occluder will cast a shadow no matter which side "
"the light is on. The other two settings ``Clockwise`` and ``Counter-"
"Clockwise`` refer to the winding order of the vertices of the polygon. The "
"winding order is used to determine which side of the line is inside the "
"polygon. Only outward facing lines cast shadows."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:173
msgid ""
"To illustrate the difference, here is an image of a :ref:`LightOccluder2D "
"<class_LightOccluder2D>` with ``Closed`` set to ``off`` in the "
"corresponding :ref:`OccluderPolygon2D <class_OccluderPolygon2D>`, so that "
"the lines of the polygon can be seen:"
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:179
msgid "``Cull Mode`` is set to ``Disabled``. All three lines cast shadows."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:183
msgid ""
"``Cull Mode`` is set to ``Clockwise``. Only the top and right lines cast "
"shadows."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:187
msgid ""
"``Cull Mode`` is set to ``Counter-Clockwise``. Only the bottom line casts a "
"shadow. If ``Closed`` was set to ``on`` there would be an additional "
"vertical line on the left which would cast a shadow as well."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:191
msgid ""
"When you have added the :ref:`LightOccluder2Ds <class_LightOccluder2D>` the "
"shadows still won't appear. You need to go back into the :ref:`Light2Ds "
"<class_Light2D>` and under the Shadow section set ``Enable`` to ``on``. This "
"turns on shadows with hard edges like in the image below."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:197
msgid ""
"To give the shadows that nice, soft edge look we set the variables "
"``filter``, ``filter smooth``, and ``gradient length``. Godot supports "
"`Percentage Closer Filtering <https://developer.nvidia.com/gpugems/GPUGems/"
"gpugems_ch11.html>`_ (PCF), which takes multiple samples of the shadow map "
"around a pixel and blurs them to create a smooth shadow effect. The higher "
"the number of samples the smoother the shadow will look, but the slower it "
"will run. That is why Godot provides 3-13 samples by default and allows you "
"to choose. The demo uses PCF7."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:206
msgid ""
"This is a shadow rendered with the demo's settings. ``gradient length`` is "
"set to ``1.3``, ``filter smooth`` is set to ``11.1``, and ``filter`` is set "
"to ``PCF7``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:211
msgid ""
"``filter`` is set to ``PCF13``. Notice how the shadow becomes wider, this is "
"because the distance between samples is based on the variable ``filter "
"smooth``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:214
msgid ""
"In order to make use of filtering you need to set the ``filter smooth`` "
"variable. This dictates how far apart the samples are. If you want the soft "
"area to extend quite far, you can increase the size of ``filter smooth``. "
"However, with few samples and a large filter smooth, you can see lines "
"forming between the samples."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:221
msgid "``filter smooth`` is set to ``30``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:223
msgid ""
"The different :ref:`Light <class_Light2D>` nodes in the demo use different "
"values for filter smooth. Play around with it and see what you like."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:228
msgid "``filter smooth`` is set to ``0``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:230
msgid ""
"Lastly, there is the variable ``gradient length``. For some smooth shadows "
"it is preferable not to have the shadow start immediately on the object, as "
"this produces a hard edge. The gradient length variable creates a smooth "
"gradient to begin the shadow to reduce the effect of the hard edge."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:236
msgid "``gradient length`` is set to ``0``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:240
msgid "``gradient length`` is set to ``10``."
msgstr ""

#: ../../docs/tutorials/2d/2d_lights_and_shadows.rst:242
msgid ""
"You will need to play around with the options a bit to find settings that "
"suit your project. There is no right solution for everyone, which is why "
"Godot provides so much flexibility. Just keep in mind that the higher "
"``filter`` set the more expensive the shadows will be."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:4
#, fuzzy
msgid "2D meshes"
msgstr "אותות"

#: ../../docs/tutorials/2d/2d_meshes.rst:9
msgid ""
"In 3D, meshes are used to display the world. In 2D, they are rare as images "
"are used more often. Godot's 2D engine is a pure two-dimensional engine, so "
"it can't really display 3D meshes directly (although it can be done via "
"``Viewport`` and ``ViewportTexture``)."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:13
msgid ""
"If you are interested in displaying 3D meshes on a 2D viewport, see the :ref:"
"`doc_viewport_as_texture` tutorial."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:15
msgid ""
"2D meshes are meshes that contain two-dimensional geometry (Z can be omitted "
"or ignored) instead of 3D. You can experiment creating them yourself using "
"``SurfaceTool`` from code and displaying them in a ``MeshInstance2D`` node."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:18
msgid ""
"Currently, the only way to generate a 2D mesh within the editor is by either "
"importing an OBJ file as a mesh, or converting it from a Sprite."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:21
msgid "Optimizing pixels drawn"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:23
msgid ""
"This workflow is useful for optimizing 2D drawing in some situations. When "
"drawing large images with transparency, Godot will draw the whole quad to "
"the screen. The large transparent areas will still be drawn."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:25
msgid ""
"This can affect performance, especially on mobile devices, when drawing very "
"large images (generally screen sized), or layering multiple images on top of "
"each other with large transparent areas (for example, when using "
"``ParallaxBackground``)."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:28
msgid ""
"Converting to a mesh will ensure that only the opaque parts will be drawn "
"and the rest will be ignored."
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:31
msgid "Converting Sprites to 2D meshes"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:33
msgid ""
"You can take advantage of this optimization by converting a ``Sprite`` to a "
"``MeshInstance2D``. Start with an image that contains large amounts of "
"transparency on the edges, like this tree:"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:38
msgid "Put it in a ``Sprite`` and select \"Convert to 2D Mesh\" from the menu:"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:42
msgid ""
"A dialog will appear, showing a preview of how the 2D mesh will be created:"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:46
msgid ""
"The default values are good enough for many cases, but you can change growth "
"and simplification according to your needs:"
msgstr ""

#: ../../docs/tutorials/2d/2d_meshes.rst:50
msgid ""
"Finally, push the ``Convert 2D Mesh`` button and your Sprite will be "
"replaced:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:4
msgid "Custom drawing in 2D"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:7
#: ../../docs/tutorials/io/encrypting_save_games.rst:7
msgid "Why?"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:9
msgid ""
"Godot has nodes to draw sprites, polygons, particles, and all sorts of "
"stuff. For most cases, this is enough; but not always. Before crying in "
"fear, angst, and rage because a node to draw that specific *something* does "
"not exist... it would be good to know that it is possible to easily make any "
"2D node (be it :ref:`Control <class_Control>` or :ref:`Node2D "
"<class_Node2D>` based) draw custom commands. It is *really* easy to do it, "
"too."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:17
msgid "But..."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:19
msgid ""
"Custom drawing manually in a node is *really* useful. Here are some examples "
"why:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:22
msgid ""
"Drawing shapes or logic that is not handled by nodes (example: making a node "
"that draws a circle, an image with trails, a special kind of animated "
"polygon, etc)."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:25
msgid ""
"Visualizations that are not that compatible with nodes: (example: a tetris "
"board). The tetris example uses a custom draw function to draw the blocks."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:28
msgid ""
"Drawing a large number of simple objects. Custom drawing avoids the overhead "
"of using nodes which makes it less memory intensive and potentially faster."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:31
msgid ""
"Making a custom UI control. There are plenty of controls available, but it's "
"easy to run into the need to make a new, custom one."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:35
msgid "OK, how?"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:37
msgid ""
"Add a script to any :ref:`CanvasItem <class_CanvasItem>` derived node, like :"
"ref:`Control <class_Control>` or :ref:`Node2D <class_Node2D>`. Then override "
"the ``_draw()`` function."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:57
msgid ""
"Draw commands are described in the :ref:`CanvasItem <class_CanvasItem>` "
"class reference. There are plenty of them."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:61
msgid "Updating"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:63
msgid ""
"The ``_draw()`` function is only called once, and then the draw commands are "
"cached and remembered, so further calls are unnecessary."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:66
msgid ""
"If re-drawing is required because a state or something else changed, simply "
"call :ref:`CanvasItem.update() <class_CanvasItem_method_update>` in that "
"same node and a new ``_draw()`` call will happen."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:70
msgid ""
"Here is a little more complex example, a texture variable that will be "
"redrawn if modified:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:114
msgid ""
"In some cases, it may be desired to draw every frame. For this, just call "
"``update()`` from the ``_process()`` callback, like this:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:146
msgid "An example: drawing circular arcs"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:148
msgid ""
"We will now use the custom drawing functionality of the Godot Engine to draw "
"something that Godot doesn't provide functions for. As an example, Godot "
"provides a ``draw_circle()`` function that draws a whole circle. However, "
"what about drawing a portion of a circle? You will have to code a function "
"to perform this and draw it yourself."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:154
msgid "Arc function"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:156
msgid ""
"An arc is defined by its support circle parameters, that is, the center "
"position and the radius. The arc itself is then defined by the angle it "
"starts from and the angle at which it stops. These are the 4 arguments that "
"we have to provide to our drawing function. We'll also provide the color "
"value, so we can draw the arc in different colors if we wish."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:161
msgid ""
"Basically, drawing a shape on the screen requires it to be decomposed into a "
"certain number of points linked from one to the next. As you can imagine, "
"the more points your shape is made of, the smoother it will appear, but the "
"heavier it will also be in terms of processing cost. In general, if your "
"shape is huge (or in 3D, close to the camera), it will require more points "
"to be drawn without it being angular-looking. On the contrary, if your shape "
"is small (or in 3D, far from the camera), you may decrease its number of "
"points to save processing costs; this is known as *Level of Detail (LOD)*. "
"In our example, we will simply use a fixed number of points, no matter the "
"radius."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:201
msgid ""
"Remember the number of points our shape has to be decomposed into? We fixed "
"this number in the ``nb_points`` variable to a value of ``32``. Then, we "
"initialize an empty ``PoolVector2Array``, which is simply an array of "
"``Vector2``\\ s."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:205
msgid ""
"The next step consists of computing the actual positions of these 32 points "
"that compose an arc. This is done in the first for-loop: we iterate over the "
"number of points for which we want to compute the positions, plus one to "
"include the last point. We first determine the angle of each point, between "
"the starting and ending angles."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:210
msgid ""
"The reason why each angle is decreased by 90° is that we will compute 2D "
"positions out of each angle using trigonometry (you know, cosine and sine "
"stuff...). However, to be simple, ``cos()`` and ``sin()`` use radians, not "
"degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to "
"start counting at 12 o'clock. So we decrease each angle by 90° in order to "
"start counting from 12 o'clock."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:216
msgid ""
"The actual position of a point located on a circle at angle ``angle`` (in "
"radians) is given by ``Vector2(cos(angle), sin(angle))``. Since ``cos()`` "
"and ``sin()`` return values between -1 and 1, the position is located on a "
"circle of radius 1. To have this position on our support circle, which has a "
"radius of ``radius``, we simply need to multiply the position by ``radius``. "
"Finally, we need to position our support circle at the ``center`` position, "
"which is performed by adding it to our ``Vector2`` value. Finally, we insert "
"the point in the ``PoolVector2Array`` which was previously defined."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:224
msgid ""
"Now, we need to actually draw our points. As you can imagine, we will not "
"simply draw our 32 points: we need to draw everything that is between each "
"of them. We could have computed every point ourselves using the previous "
"method, and drew it one by one. But this is too complicated and inefficient "
"(except if explicitly needed), so we simply draw lines between each pair of "
"points. Unless the radius of our support circle is big, the length of each "
"line between a pair of points will never be long enough to see them. If that "
"were to happen, we would simply need to increase the number of points."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:234
msgid "Draw the arc on the screen"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236
msgid ""
"We now have a function that draws stuff on the screen; it is time to call it "
"inside the ``_draw()`` function:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:268
msgid "Arc polygon function"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:270
msgid ""
"We can take this a step further and not only write a function that draws the "
"plain portion of the disc defined by the arc, but also its shape. The method "
"is exactly the same as before, except that we draw a polygon instead of "
"lines:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:310
msgid "Dynamic custom drawing"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312
msgid ""
"All right, we are now able to draw custom stuff on the screen. However, it "
"is static; let's make this shape turn around the center. The solution to do "
"this is simply to change the angle_from and angle_to values over time. For "
"our example, we will simply increment them by 50. This increment value has "
"to remain constant or else the rotation speed will change accordingly."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:318
msgid ""
"First, we have to make both angle_from and angle_to variables global at the "
"top of our script. Also note that you can store them in other nodes and "
"access them using ``get_node()``."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:340
msgid "We make these values change in the _process(delta) function."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:342
msgid ""
"We also increment our angle_from and angle_to values here. However, we must "
"not forget to ``wrap()`` the resulting values between 0 and 360°! That is, "
"if the angle is 361°, then it is actually 1°. If you don't wrap these "
"values, the script will work correctly, but the angle values will grow "
"bigger and bigger over time until they reach the maximum integer value Godot "
"can manage (``2^31 - 1``). When this happens, Godot may crash or produce "
"unexpected behavior."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:349
msgid ""
"Finally, we must not forget to call the ``update()`` function, which "
"automatically calls ``_draw()``. This way, you can control when you want to "
"refresh the frame."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:389
msgid ""
"Also, don't forget to modify the ``_draw()`` function to make use of these "
"variables:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:413
msgid ""
"Let's run! It works, but the arc is rotating insanely fast! What's wrong?"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:416
msgid ""
"The reason is that your GPU is actually displaying the frames as fast as it "
"can. We need to \"normalize\" the drawing by this speed; to achieve that, we "
"have to make use of the ``delta`` parameter of the ``_process()`` function. "
"``delta`` contains the time elapsed between the two last rendered frames. It "
"is generally small (about 0.0003 seconds, but this depends on your "
"hardware), so using ``delta`` to control your drawing ensures that your "
"program runs at the same speed on everybody's hardware."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:424
msgid ""
"In our case, we simply need to multiply our ``rotation_angle`` variable by "
"``delta`` in the ``_process()`` function. This way, our 2 angles will be "
"increased by a much smaller value, which directly depends on the rendering "
"speed."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:458
msgid "Let's run again! This time, the rotation displays fine!"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:461
#: ../../docs/tutorials/content/procedural_geometry/index.rst:73
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:130
msgid "Tools"
msgstr "כלים"

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:463
msgid ""
"Drawing your own nodes might also be desired while running them in the "
"editor to use as a preview or visualization of some feature or behavior."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:467
msgid ""
"Remember to use the \"tool\" keyword at the top of the script (check the :"
"ref:`doc_gdscript` reference if you forgot what this does)."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:4
#, fuzzy
msgid "2D Sprite animation"
msgstr "אנימציות"

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:9
msgid ""
"In this tutorial, you'll learn how to create 2D animated characters with the "
"AnimatedSprite class and the AnimationPlayer. Typically, when you create or "
"download an animated character, it will come in one of two ways: as "
"individual images or as a single sprite sheet containing all the animation's "
"frames.  Both can be animated in Godot with the AnimatedSprite class."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:14
msgid ""
"First, we'll use :ref:`AnimatedSprite <class_AnimatedSprite>` to animate a "
"collection of individual images. Then we will animate a sprite sheet using "
"this class.  Finally, we will learn another way to animate a sprite sheet "
"with :ref:`AnimationPlayer <class_AnimationPlayer>` and the *Animation* "
"property of :ref:`Sprite <class_Sprite>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:19
msgid ""
"Art for the following examples by https://opengameart.org/users/ansimuz and "
"by https://opengameart.org/users/tgfcoder"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:23
msgid "Individual images with AnimatedSprite"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:25
msgid ""
"In this scenario, you have a collection of images, each containing one of "
"your character's animation frames. For this example, we'll use the following "
"animation:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:31
msgid ""
"You can download the images here: :download:`run_animation.zip <files/"
"run_animation.zip>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:34
msgid ""
"Unzip the images and place them in your project folder. Set up your scene "
"tree with the following nodes:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:39
#: ../../docs/tutorials/2d/2d_sprite_animation.rst:143
msgid ""
"The root node could also be :ref:`Area2D <class_Area2D>` or :ref:"
"`RigidBody2D <class_RigidBody2D>`. The animation will still be made in the "
"same way. Once the animation is completed, you can assign a shape to the "
"CollisionShape2D. See :ref:`Physics Introduction <doc_physics_introduction>` "
"for more information."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:46
msgid ""
"Now select the ``AnimatedSprite`` and in its *SpriteFrames* property, select "
"\"New SpriteFrames\"."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:51
msgid ""
"Click on the new SpriteFrames resource and you'll see a new panel appear at "
"the bottom of the editor window:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:56
msgid ""
"From the FileSystem dock on the left side, drag the 8 individual images into "
"the center part of the SpriteFrames panel. On the left side, change the name "
"of the animation from \"default\" to \"run\"."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:62
msgid ""
"Back in the Inspector, check the box for the *Playing* property. You should "
"now see the animation playing in the viewport. However, it is a bit slow. To "
"fix this, change the *Speed (FPS)* setting in the SpriteFrames panel to 10."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:66
msgid ""
"You can add additional animations by clicking the \"New Animation\" button "
"and adding additional images."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:70
#, fuzzy
msgid "Controlling the animation"
msgstr "אנימציות"

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:72
msgid ""
"Once the animation is complete, you can control the animation via code using "
"the ``play()`` and ``stop()`` methods. Here is a brief example to play the "
"animation while the right arrow key is held, and stop it when the key is "
"released."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:90
#, fuzzy
msgid "Sprite sheet with AnimatedSprite"
msgstr "אנימציות"

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:92
msgid ""
"You can also easily animate from a sprite sheet with the class "
"``AnimatedSprite``.  We will use this public domain sprite sheet:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:96
msgid ""
"Right-click the image and choose \"Save Image As\" to download it, and then "
"copy the image into your project folder."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:98
msgid ""
"Set up your scene tree the same way you did previously when using individual "
"images.  Select the ``AnimatedSprite`` and in its *SpriteFrames* property, "
"select \"New SpriteFrames\"."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:101
msgid ""
"Click on the new SpriteFrames resource.  This time, when the bottom panel "
"appears, select \"Add frames from a Sprite Sheet\"."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:105
msgid "You will be prompted to open a file.  Select your sprite sheet."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:107
msgid ""
"A new window will open, showing your sprite sheet.  The first thing you will "
"need to do is to change the number of vertical and horizontal images in your "
"sprite sheet.  In this sprite sheet, we have four images horizontally and "
"two images vertically."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:111
msgid ""
"Next, select the frames from the sprite sheet that you want to include in "
"your animation.  We will select the top four, then click \"Add 4 frames\" to "
"create the animation."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:115
msgid ""
"You will now see your animation under the list of animations in the bottom "
"panel.  Double click on default to change the name of the animation to jump."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:119
msgid ""
"Finally, check Playing on the  AnimatedSprite in the inspector to see your "
"frog jump!"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:125
#, fuzzy
msgid "Sprite sheet with AnimationPlayer"
msgstr "אנימציות"

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:127
msgid ""
"Another way that you can animate when using a sprite sheet is to use a "
"standard :ref:`Sprite <class_Sprite>` node to display the texture, and then "
"animating the change from texture to texture with :ref:`AnimationPlayer "
"<class_AnimationPlayer>`."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:131
msgid "Consider this sprite sheet, which contains 6 frames of animation:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:135
msgid ""
"Right-click the image and choose \"Save Image As\" to download, then copy "
"the image into your project folder."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:138
msgid ""
"Our goal is to display these images one after another in a loop. Start by "
"setting up your scene tree:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:150
msgid ""
"Drag the spritesheet into the Sprite's *Texture* property, and you'll see "
"the whole sheet displayed on the screen. To slice it up into individual "
"frames, expand the *Animation* section in the Inspector and set the "
"*Hframes* to ``6``. *Hframes* and *Vframes* are the number of horizontal and "
"vertical frames in your sprite sheet."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:158
msgid ""
"Now try changing the value of the *Frame* property. You'll see that it "
"ranges from ``0`` to ``5`` and the image displayed by the Sprite changes "
"accordingly. This is the property we'll be animating."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:162
msgid ""
"Select the ``AnimationPlayer`` and click the \"Animation\" button followed "
"by \"New\". Name the new animation \"walk\". Set the animation length to "
"``0.6`` and click the \"Loop\" button so that our animation will repeat."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:168
msgid ""
"Now select the ``Sprite`` node and click the key icon to add a new track."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:172
msgid ""
"Continue adding frames at each point in the timeline (``0.1`` seconds by "
"default), until you have all the frames from 0 to 5. You'll see the frames "
"actually appearing in the animation track:"
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:178
msgid "Press \"Play\" on the animation to see how it looks."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:183
#, fuzzy
msgid "Controlling an AnimationPlayer animation"
msgstr "אנימציות"

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:185
msgid ""
"Like with AnimatedSprite, you can control the animation via code using the "
"``play()`` and ``stop()`` methods. Again, here is an example to play the "
"animation while the right arrow key is held, and stop it when the key is "
"released."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:202
msgid ""
"If updating both an animation and a separate property at once (for example, "
"a platformer may update the sprite's ``h_flip``/``v_flip`` properties when a "
"character turns while starting a 'turning' animation), it's important to "
"keep in mind that ``play()`` isn't applied instantly. Instead, it's applied "
"the next time the :ref:`AnimationPlayer <class_AnimationPlayer>` is "
"processed. This may end up being on the next frame, causing a 'glitch' "
"frame, where the property change was applied but the animation was not. If "
"this turns out to be a problem, after calling ``play()``, you can call "
"``advance(0)`` to update the animation immediately."
msgstr ""

#: ../../docs/tutorials/2d/2d_sprite_animation.rst:215
msgid ""
"These examples illustrate the two classes you can use in Godot for 2D "
"animation. ``AnimationPlayer`` is a bit more complex than "
"``AnimatedSprite``, but it provides additional functionality, since you can "
"also animate other properties like position or scale. The class "
"``AnimationPlayer`` can also be used with an ``AnimatedSprite``.  Experiment "
"to see what works best for your needs."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:4
msgid "Introduction to 3D"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:6
msgid ""
"Creating a 3D game can be challenging. That extra Z coordinate makes many of "
"the common techniques that helped to make 2D games simple no longer work. To "
"aid in this transition, it is worth mentioning that Godot uses similar APIs "
"for 2D and 3D. Most nodes are the same and are present in both 2D and 3D "
"versions. In fact, it is worth checking the 3D platformer tutorial, or the "
"3D kinematic character tutorials, which are almost identical to their 2D "
"counterparts."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:14
msgid ""
"In 3D, math is a little more complex than in 2D, so also checking the :ref:"
"`doc_vector_math` entry in the wiki (which was especially created for game "
"developers, not mathematicians or engineers) will help pave the way for you "
"to develop 3D games efficiently."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:20
msgid "Spatial node"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:22
msgid ""
":ref:`Node2D <class_Node2D>` is the base node for 2D. :ref:`Control "
"<class_Control>` is the base node for everything GUI. Following this "
"reasoning, the 3D engine uses the :ref:`Spatial <class_Spatial>` node for "
"everything 3D."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:29
msgid ""
"Spatial nodes have a local transform, which is relative to the parent node "
"(as long as the parent node is also of **or inherits from** the type "
"Spatial). This transform can be accessed as a 4×3 :ref:`Transform "
"<class_Transform>`, or as 3 :ref:`Vector3 <class_Vector3>` members "
"representing location, Euler rotation (X, Y and Z angles) and scale."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:39
msgid "3D content"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:41
msgid ""
"Unlike 2D, where loading image content and drawing is straightforward, 3D is "
"a little more difficult. The content needs to be created with special 3D "
"tools (usually referred to as DCCs) and exported to an exchange file format "
"in order to be imported in Godot (3D formats are not as standardized as "
"images)."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:48
msgid "DCC-created models"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:53
msgid ""
"There are two pipelines to import 3D models in Godot. The first and most "
"common one is by :ref:`doc_importing_3d_scenes`, which allows you to import "
"entire scenes (just as they look in the DCC), including animation, skeletal "
"rigs, blend shapes, etc."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:58
msgid ""
"The second pipeline is by importing simple .OBJ files as mesh resources, "
"which can be then put inside a :ref:`MeshInstance <class_MeshInstance>` node "
"for display."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:63
msgid "Generated geometry"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:65
msgid ""
"It is possible to create custom geometry by using the :ref:`ArrayMesh "
"<class_ArrayMesh>` resource directly. Simply create your arrays and use the :"
"ref:`ArrayMesh.add_surface_from_arrays() "
"<class_ArrayMesh_method_add_surface_from_arrays>` function. A helper class "
"is also available, :ref:`SurfaceTool <class_SurfaceTool>`, which provides a "
"more straightforward API and helpers for indexing, generating normals, "
"tangents, etc."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:72
msgid ""
"In any case, this method is meant for generating static geometry (models "
"that will not be updated often), as creating vertex arrays and submitting "
"them to the 3D API has a significant performance cost."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:77
msgid "Immediate geometry"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:79
msgid ""
"If, instead, there is a requirement to generate simple geometry that will be "
"updated often, Godot provides a special node, :ref:`ImmediateGeometry "
"<class_ImmediateGeometry>`, which provides an OpenGL 1.x style immediate-"
"mode API to create points, lines, triangles, etc."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:86
msgid "2D in 3D"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:88
msgid ""
"While Godot packs a powerful 2D engine, many types of games use 2D in a 3D "
"environment. By using a fixed camera (either orthogonal or perspective) that "
"does not rotate, nodes such as :ref:`Sprite3D <class_Sprite3D>` and :ref:"
"`AnimatedSprite3D <class_AnimatedSprite3D>` can be used to create 2D games "
"that take advantage of mixing with 3D backgrounds, more realistic parallax, "
"lighting/shadow effects, etc."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:96
msgid ""
"The disadvantage is, of course, that added complexity and reduced "
"performance in comparison to plain 2D, as well as the lack of reference of "
"working in pixels."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:101
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10
msgid "Environment"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:103
msgid ""
"Besides editing a scene, it is often common to edit the environment. Godot "
"provides a :ref:`WorldEnvironment <class_WorldEnvironment>` node that allows "
"changing the background color, mode (as in, put a skybox), and applying "
"several types of built-in post-processing effects. Environments can also be "
"overridden in the Camera."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:110
msgid "3D viewport"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:112
msgid ""
"Editing 3D scenes is done in the 3D tab. This tab can be selected manually, "
"but it will be automatically enabled when a Spatial node is selected."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:118
msgid ""
"Default 3D scene navigation controls are similar to Blender (aiming to have "
"some sort of consistency in the free software pipeline..), but options are "
"included to customize mouse buttons and behavior to be similar to other "
"tools in the Editor Settings:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:126
msgid "Coordinate system"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:128
msgid ""
"Godot uses the `metric <https://en.wikipedia.org/wiki/Metric_system>`__ "
"system for everything. 3D Physics and other areas are tuned for this, so "
"attempting to use a different scale is usually a bad idea (unless you know "
"what you are doing)."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:133
msgid ""
"When working with 3D assets, it's always best to work in the correct scale "
"(set your DCC to metric). Godot allows scaling post-import and, while this "
"works in most cases, in rare situations it may introduce floating-point "
"precision issues (and thus, glitches or artifacts) in delicate areas, such "
"as rendering or physics, so make sure your artists always work in the right "
"scale!"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:140
msgid ""
"The Y coordinate is used for \"up\", though for most objects that need "
"alignment (like lights, cameras, capsule collider, vehicle, etc.), the Z "
"axis is used as a \"pointing towards\" direction. This convention roughly "
"means that:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:145
msgid "**X** is sides"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:146
msgid "**Y** is up/down"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:147
msgid "**Z** is front/back"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:150
msgid "Space and manipulation gizmos"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:152
msgid ""
"Moving objects in the 3D view is done through the manipulator gizmos. Each "
"axis is represented by a color: Red, Green, Blue represent X, Y, Z "
"respectively. This convention applies to the grid and other gizmos too (and "
"also to the shader language, ordering of components for Vector3, Color, "
"etc.)."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:160
msgid "Some useful keybindings:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:162
msgid ""
"To snap placement or rotation, press :kbd:`Ctrl` while moving, scaling or "
"rotating."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:164
msgid "To center the view on the selected object, press :kbd:`F`."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:167
msgid "View menu"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:169
msgid ""
"The view options are controlled by the \"View\" menu in the viewport's "
"toolbar."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:173
msgid "You can hide the gizmos in the 3D view of the editor through this menu:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:177
msgid ""
"To hide a specific type of gizmos, you can toggle them off in the \"View\" "
"menu."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:182
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:40
msgid "Default environment"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:184
msgid ""
"When created from the Project Manager, the 3D environment has a default sky."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:188
msgid ""
"Given how physically based rendering works, it is advised to always try to "
"work with a default environment in order to provide indirect and reflected "
"light to your objects."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:193
msgid "Cameras"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:195
msgid ""
"No matter how many objects are placed in the 3D space, nothing will be "
"displayed unless a :ref:`Camera <class_Camera>` is also added to the scene. "
"Cameras can work in either orthogonal or perspective projections:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:202
msgid ""
"Cameras are associated with (and only display to) a parent or grandparent "
"viewport. Since the root of the scene tree is a viewport, cameras will "
"display on it by default, but if sub-viewports (either as render target or "
"picture-in-picture) are desired, they need their own children cameras to "
"display."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:210
msgid ""
"When dealing with multiple cameras, the following rules are enforced for "
"each viewport:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:213
msgid ""
"If no cameras are present in the scene tree, the first one that enters it "
"will become the active camera. Further cameras entering the scene will be "
"ignored (unless they are set as *current*)."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:216
msgid ""
"If a camera has the \"*current*\" property set, it will be used regardless "
"of any other camera in the scene. If the property is set, it will become "
"active, replacing the previous camera."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:219
msgid ""
"If an active camera leaves the scene tree, the first camera in tree-order "
"will take its place."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:225
msgid ""
"There is no limitation on the number of lights, nor of types of lights, in "
"Godot. As many as desired can be added (as long as performance allows)."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:4
#, fuzzy
msgid "Using 3D transforms"
msgstr "התמרה"

#: ../../docs/tutorials/3d/using_transforms.rst:9
msgid ""
"If you have never made 3D games before, working with rotations in three "
"dimensions can be confusing at first. Coming from 2D, the natural way of "
"thinking is along the lines of *\"Oh, it's just like rotating in 2D, except "
"now rotations happen in X, Y and Z\"*."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:12
msgid ""
"At first this seems easy and for simple games, this way of thinking may even "
"be enough. Unfortunately, it's often incorrect."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:14
msgid ""
"Angles in three dimensions are most commonly referred to as \"Euler Angles\"."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:18
msgid ""
"Euler angles were introduced by mathematician Leonhard Euler in the early "
"1700s."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:22
msgid ""
"This way of representing 3D rotations was groundbreaking at the time, but it "
"has several shortcomings when used in game development (which is to be "
"expected from a guy with a funny hat). The idea of this document is to "
"explain why, as well as outlining best practices for dealing with transforms "
"when programming 3D games."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:28
msgid "Problems of Euler angles"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:30
msgid ""
"While it may seem intuitive that each axis has a rotation, the truth is that "
"it's just not practical."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:33
msgid "Axis order"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:35
msgid ""
"The main reason for this is that there isn't a *unique* way to construct an "
"orientation from the angles. There isn't a standard mathematical function "
"that takes all the angles together and produces an actual 3D rotation. The "
"only way an orientation can be produced from angles is to rotate the object "
"angle by angle, in an *arbitrary order*."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:39
msgid ""
"This could be done by first rotating in *X*, then *Y* and then in *Z*. "
"Alternatively, you could first rotate in *Y*, then in *Z* and finally in "
"*X*. Anything works, but depending on the order, the final orientation of "
"the object will *not necessarily be the same*. Indeed, this means that there "
"are several ways to construct an orientation from 3 different angles, "
"depending on *the order of the rotations*."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:43
msgid ""
"Following is a visualization of rotation axes (in X, Y, Z order) in a gimbal "
"(from Wikipedia). As you can see, the orientation of each axis depends on "
"the rotation of the previous one:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:47
msgid ""
"You may be wondering how this affects you. Let's look at a practical example:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:49
msgid ""
"Imagine you are working on a first-person controller (e.g. an FPS game). "
"Moving the mouse left and right controls your view angle parallel to the "
"ground, while moving it up and down moves the player's view up and down."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:51
msgid ""
"In this case to achieve the desired effect, rotation must be applied first "
"in the *Y* axis (\"up\" in this case, since Godot uses a \"Y-Up\" "
"orientation), followed by rotation in the *X* axis."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:55
msgid ""
"If we were to apply rotation in the *X* axis first, and then in *Y*, the "
"effect would be undesired:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:59
msgid ""
"Depending on the type of game or effect desired, the order in which you want "
"axis rotations to be applied may differ. Therefore, applying rotations in X, "
"Y, and Z is not enough: you also need a *rotation order*."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:62
#: ../../docs/tutorials/math/interpolation.rst:4
msgid "Interpolation"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:64
msgid ""
"Another problem with using Euler angles is interpolation. Imagine you want "
"to transition between two different camera or enemy positions (including "
"rotations). One logical way to approach this is to interpolate the angles "
"from one position to the next. One would expect it to look like this:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:68
msgid "But this does not always have the expected effect when using angles:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:72
msgid "The camera actually rotated the opposite direction!"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:74
msgid "There are a few reasons this may happen:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:76
msgid ""
"Rotations don't map linearly to orientation, so interpolating them does not "
"always result in the shortest path (i.e., to go from ``270`` to ``0`` "
"degrees is not the same as going from ``270`` to ``360``, even though the "
"angles are equivalent)."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:77
msgid ""
"Gimbal lock is at play (first and last rotated axis align, so a degree of "
"freedom is lost). See `Wikipedia's page on Gimbal Lock <https://en.wikipedia."
"org/wiki/Gimbal_lock>`_ for a detailed explanation of this problem."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:80
msgid "Say no to Euler angles"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:82
msgid ""
"The result of all this is that you should **not use** the ``rotation`` "
"property of :ref:`class_Spatial` nodes in Godot for games. It's there to be "
"used mainly in the editor, for coherence with the 2D engine, and for simple "
"rotations (generally just one axis, or even two in limited cases). As much "
"as you may be tempted, don't use it."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:84
msgid "Instead, there is a better way to solve your rotation problems."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:87
msgid "Introducing transforms"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:89
msgid ""
"Godot uses the :ref:`class_Transform` datatype for orientations. Each :ref:"
"`class_Spatial` node contains a ``transform`` property which is relative to "
"the parent's transform, if the parent is a Spatial-derived type."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:91
msgid ""
"It is also possible to access the world coordinate transform via the "
"``global_transform`` property."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:93
msgid ""
"A transform has a :ref:`class_Basis` (transform.basis sub-property), which "
"consists of three :ref:`class_Vector3` vectors. These are accessed via the "
"``transform.basis`` property and can be accessed directly by ``transform."
"basis.x``, ``transform.basis.y``, and ``transform.basis.z``. Each vector "
"points in the direction its axis has been rotated, so they effectively "
"describe the node's total rotation. The scale (as long as it's uniform) can "
"also be inferred from the length of the axes. A *basis* can also be "
"interpreted as a 3x3 matrix and used as ``transform.basis[x][y]``."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:95
msgid "A default basis (unmodified) is akin to:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:123
msgid "This is also an analog of a 3x3 identity matrix."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:125
msgid ""
"Following the OpenGL convention, ``X`` is the *Right* axis, ``Y`` is the "
"*Up* axis and ``Z`` is the *Forward* axis."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:127
msgid ""
"Together with the *basis*, a transform also has an *origin*. This is a "
"*Vector3* specifying how far away from the actual origin ``(0, 0, 0)`` this "
"transform is. Combining the *basis* with the *origin*, a *transform* "
"efficiently represents a unique translation, rotation, and scale in space."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:132
msgid ""
"One way to visualize a transform is to look at an object's 3D gizmo while in "
"\"local space\" mode."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:136
msgid ""
"The gizmo's arrows show the ``X``, ``Y``, and ``Z`` axes (in red, green, and "
"blue respectively) of the basis, while the gizmo's center is at the object's "
"origin."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:140
msgid ""
"For more information on the mathematics of vectors and transforms, please "
"read the :ref:`doc_vector_math` tutorials."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:143
msgid "Manipulating transforms"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:145
msgid ""
"Of course, transforms are not as straightforward to manipulate as angles and "
"have problems of their own."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:147
msgid ""
"It is possible to rotate a transform, either by multiplying its basis by "
"another (this is called accumulation), or by using the rotation methods."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:164
msgid "A method in Spatial simplifies this:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:181
msgid "This rotates the node relative to the parent node."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:183
msgid ""
"To rotate relative to object space (the node's own transform), use the "
"following:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:197
msgid "Precision errors"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:199
msgid ""
"Doing successive operations on transforms will result in a loss of precision "
"due to floating-point error. This means the scale of each axis may no longer "
"be exactly ``1.0``, and they may not be exactly ``90`` degrees from each "
"other."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:201
msgid ""
"If a transform is rotated every frame, it will eventually start deforming "
"over time. This is unavoidable."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:203
msgid ""
"There are two different ways to handle this. The first is to "
"*orthonormalize* the transform after some time (maybe once per frame if you "
"modify it every frame):"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:214
msgid ""
"This will make all axes have ``1.0`` length again and be ``90`` degrees from "
"each other. However, any scale applied to the transform will be lost."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:216
msgid ""
"It is recommended you not scale nodes that are going to be manipulated; "
"scale their children nodes instead (such as MeshInstance). If you absolutely "
"must scale the node, then re-apply it at the end:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:230
msgid "Obtaining information"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:232
msgid ""
"You might be thinking at this point: **\"Ok, but how do I get angles from a "
"transform?\"**. The answer again is: you don't. You must do your best to "
"stop thinking in angles."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:234
msgid ""
"Imagine you need to shoot a bullet in the direction your player is facing. "
"Just use the forward axis (commonly ``Z`` or ``-Z``)."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:247
msgid ""
"Is the enemy looking at the player? Use the dot product for this (see the :"
"ref:`doc_vector_math` tutorial for an explanation of the dot product):"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:266
msgid "Strafe left:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:283
msgid "Jump:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:302
msgid "All common behaviors and logic can be done with just vectors."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:305
msgid "Setting information"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:307
msgid ""
"There are, of course, cases where you want to set information to a "
"transform. Imagine a first person controller or orbiting camera. Those are "
"definitely done using angles, because you *do want* the transforms to happen "
"in a specific order."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:309
msgid ""
"For such cases, keep the angles and rotations *outside* the transform and "
"set them every frame. Don't try to retrieve and re-use them because the "
"transform is not meant to be used this way."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:311
msgid "Example of looking around, FPS style:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:353
msgid ""
"As you can see, in such cases it's even simpler to keep the rotation "
"outside, then use the transform as the *final* orientation."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:356
msgid "Interpolating with quaternions"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:358
msgid ""
"Interpolating between two transforms can efficiently be done with "
"quaternions. More information about how quaternions work can be found in "
"other places around the Internet. For practical use, it's enough to "
"understand that pretty much their main use is doing a closest path "
"interpolation. As in, if you have two rotations, a quaternion will smoothly "
"allow interpolation between them using the closest axis."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:360
msgid "Converting a rotation to quaternion is straightforward."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:383
msgid ""
"The :ref:`class_Quat` type reference has more information on the datatype "
"(it can also do transform accumulation, transform points, etc., though this "
"is used less often). If you interpolate or apply operations to quaternions "
"many times, keep in mind they need to be eventually normalized. Otherwise, "
"they will also suffer from numerical precision errors."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:389
msgid ""
"Quaternions are useful when doing camera/path/etc. interpolations, as the "
"result will always be correct and smooth."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:392
msgid "Transforms are your friend"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:394
msgid ""
"For most beginners, getting used to working with transforms can take some "
"time. However, once you get used to them, you will appreciate their "
"simplicity and power."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:396
msgid ""
"Don't hesitate to ask for help on this topic in any of Godot's `online "
"communities <https://godotengine.org/community>`_ and, once you become "
"confident enough, please help others!"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:1
#, fuzzy
msgid "optimization"
msgstr "אנימציות"

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:7
msgid "Optimizing 3D performance"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:12
msgid ""
"Godot follows a balanced performance philosophy. In the performance world, "
"there are always trade-offs, which consist of trading speed for usability "
"and flexibility. Some practical examples of this are:"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:16
msgid ""
"Rendering objects efficiently in high amounts is easy, but when a large "
"scene must be rendered, it can become inefficient. To solve this, visibility "
"computation must be added to the rendering, which makes rendering less "
"efficient, but, at the same time, fewer objects are rendered, so efficiency "
"overall improves."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:21
msgid ""
"Configuring the properties of every material for every object that needs to "
"be rendered is also slow. To solve this, objects are sorted by material to "
"reduce the costs, but at the same time sorting has a cost."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:25
msgid ""
"In 3D physics a similar situation happens. The best algorithms to handle "
"large amounts of physics objects (such as SAP) are slow at insertion/removal "
"of objects and ray-casting. Algorithms that allow faster insertion and "
"removal, as well as ray-casting, will not be able to handle as many active "
"objects."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:31
msgid ""
"And there are many more examples of this! Game engines strive to be general "
"purpose in nature, so balanced algorithms are always favored over algorithms "
"that might be fast in some situations and slow in others.. or algorithms "
"that are fast but make usability more difficult."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:36
msgid ""
"Godot is not an exception and, while it is designed to have backends "
"swappable for different algorithms, the default ones (or more like, the only "
"ones that are there for now) prioritize balance and flexibility over "
"performance."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:41
msgid ""
"With this clear, the aim of this tutorial is to explain how to get the "
"maximum performance out of Godot."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:45
#: ../../docs/tutorials/viewports/viewports.rst:174
msgid "Rendering"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:47
msgid ""
"3D rendering is one of the most difficult areas to get performance from, so "
"this section will have a list of tips."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:51
msgid "Reuse shaders and materials"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:53
msgid ""
"The Godot renderer is a little different to what is out there. It's designed "
"to minimize GPU state changes as much as possible. :ref:"
"`class_SpatialMaterial` does a good job at reusing materials that need "
"similar shaders but, if custom shaders are used, make sure to reuse them as "
"much as possible. Godot's priorities will be like this:"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:60
msgid ""
"**Reusing Materials**: The fewer different materials in the scene, the "
"faster the rendering will be. If a scene has a huge amount of objects (in "
"the hundreds or thousands) try reusing the materials or in the worst case "
"use atlases."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:64
msgid ""
"**Reusing Shaders**: If materials can't be reused, at least try to re-use "
"shaders (or SpatialMaterials with different parameters but the same "
"configuration)."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:68
msgid ""
"If a scene has, for example, 20.000 objects with 20.000 different materials "
"each, rendering will be slow. If the same scene has 20.000 objects, but only "
"uses 100 materials, rendering will be blazingly fast."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:74
msgid "Pixel cost vs vertex cost"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:76
msgid ""
"It is a common thought that the lower the number of polygons in a model, the "
"faster it will be rendered. This is *really* relative and depends on many "
"factors."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:80
msgid ""
"On a modern PC and console, vertex cost is low. GPUs originally only "
"rendered triangles, so all the vertices:"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:83
msgid "Had to be transformed by the CPU (including clipping)."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:85
msgid "Had to be sent to the GPU memory from the main RAM."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:87
msgid ""
"Nowadays, all this is handled inside the GPU, so the performance is "
"extremely high. 3D artists usually have the wrong feeling about polycount "
"performance because 3D DCCs (such as Blender, Max, etc.) need to keep "
"geometry in CPU memory in order for it to be edited, reducing actual "
"performance. Truth is, a model rendered by a 3D engine is much more optimal "
"than how 3D DCCs display them."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:94
msgid ""
"On mobile devices, the story is different. PC and Console GPUs are brute-"
"force monsters that can pull as much electricity as they need from the power "
"grid. Mobile GPUs are limited to a tiny battery, so they need to be a lot "
"more power efficient."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:99
msgid ""
"To be more efficient, mobile GPUs attempt to avoid *overdraw*. This means, "
"the same pixel on the screen being rendered (as in, with lighting "
"calculation, etc.) more than once. Imagine a town with several buildings, "
"GPUs don't know what is visible and what is hidden until they draw it. A "
"house might be drawn and then another house in front of it (rendering "
"happened twice for the same pixel!). PC GPUs normally don't care much about "
"this and just throw more pixel processors to the hardware to increase "
"performance (but this also increases power consumption)."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:109
msgid ""
"On mobile, pulling more power is not an option, so a technique called \"Tile "
"Based Rendering\" is used (almost every mobile hardware uses a variant of "
"it), which divides the screen into a grid. Each cell keeps the list of "
"triangles drawn to it and sorts them by depth to minimize *overdraw*. This "
"technique improves performance and reduces power consumption, but takes a "
"toll on vertex performance. As a result, fewer vertices and triangles can be "
"processed for drawing."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:117
msgid ""
"Generally, this is not so bad, but there is a corner case on mobile that "
"must be avoided, which is to have small objects with a lot of geometry "
"within a small portion of the screen. This forces mobile GPUs to put a lot "
"of strain on a single screen cell, considerably decreasing performance (as "
"all the other cells must wait for it to complete in order to display the "
"frame)."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:124
msgid ""
"To make it short, do not worry about vertex count so much on mobile, but "
"avoid concentration of vertices in small parts of the screen. If, for "
"example, a character, NPC, vehicle, etc. is far away (so it looks tiny), use "
"a smaller level of detail (LOD) model instead."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:129
msgid ""
"An extra situation where vertex cost must be considered is objects that have "
"extra processing per vertex, such as:"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:132
msgid "Skinning (skeletal animation)"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:133
msgid "Morphs (shape keys)"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:134
msgid "Vertex Lit Objects (common on mobile)"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:137
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:108
msgid "Texture compression"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:139
msgid ""
"Godot offers to compress textures of 3D models when imported (VRAM "
"compression). Video RAM compression is not as efficient in size as PNG or "
"JPG when stored, but increases performance enormously when drawing."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:143
msgid ""
"This is because the main goal of texture compression is bandwidth reduction "
"between memory and the GPU."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:146
msgid ""
"In 3D, the shapes of objects depend more on the geometry than the texture, "
"so compression is generally not noticeable. In 2D, compression depends more "
"on shapes inside the textures, so the artifacts resulting from 2D "
"compression are more noticeable."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:151
msgid ""
"As a warning, most Android devices do not support texture compression of "
"textures with transparency (only opaque), so keep this in mind."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:155
msgid "Transparent objects"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:157
msgid ""
"As mentioned before, Godot sorts objects by material and shader to improve "
"performance. This, however, can not be done on transparent objects. "
"Transparent objects are rendered from back to front to make blending with "
"what is behind work. As a result, please try to keep transparent objects to "
"a minimum! If an object has a small section with transparency, try to make "
"that section a separate material."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:165
msgid "Level of detail (LOD)"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:167
msgid ""
"As also mentioned before, using objects with fewer vertices can improve "
"performance in some cases. Godot has a simple system to change level of "
"detail, :ref:`GeometryInstance <class_GeometryInstance>` based objects have "
"a visibility range that can be defined. Having several GeometryInstance "
"objects in different ranges works as LOD."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:175
msgid "Use instancing (MultiMesh)"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:177
msgid ""
"If several identical objects have to be drawn in the same place or nearby, "
"try using :ref:`MultiMesh <class_MultiMesh>` instead. MultiMesh allows the "
"drawing of dozens of thousands of objects at very little performance cost, "
"making it ideal for flocks, grass, particles, etc."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:184
msgid "Bake lighting"
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:186
msgid ""
"Small lights are usually not a performance issue. Shadows a little more. In "
"general, if several lights need to affect a scene, it's ideal to bake it (:"
"ref:`doc_baked_lightmaps`). Baking can also improve the scene quality by "
"adding indirect light bounces."
msgstr ""

#: ../../docs/tutorials/3d/optimizing_3d_performance.rst:191
msgid ""
"If working on mobile, baking to texture is recommended, since this method is "
"even faster."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:4
msgid "3D rendering limitations"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:9
msgid ""
"Due to their focus on performance, real-time rendering engines have many "
"limitations. Godot's renderer is no exception. To work effectively with "
"those limitations, you need to understand them."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:14
msgid "Texture size limits"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:16
msgid ""
"On desktops and laptops, textures larger than 8192×8192 may not be supported "
"on older devices. You can check your target GPU's limitations on `GPUinfo."
"org <https://www.gpuinfo.org/>`__."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:20
msgid ""
"Mobile GPUs are typically limited to 4096×4096 textures. Also, some mobile "
"GPUs don't support repeating non-power-of-two-sized textures. Therefore, if "
"you want your texture to display correctly on all platforms, you should "
"avoid using textures larger than 4096×4096 and use a power of two size if "
"the texture needs to repeat."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:27
msgid "Color banding"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:29
msgid ""
"When using the GLES3 or Vulkan renderers, Godot's 3D engine renders "
"internally in HDR. However, the rendering output will be tonemapped to a low "
"dynamic range so it can be displayed on the screen. This can result in "
"visible banding, especially when using untextured materials. This can also "
"be seen in 2D projects when using smooth gradient textures."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:35
msgid "There are several ways to alleviate banding. Here are a few examples:"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:37
msgid ""
"Bake some noise into your textures. This is mainly effective in 2D, e.g. for "
"vignetting effects."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:39
msgid ""
"Implement a debanding shader as a :ref:`screen-reading shader <doc_screen-"
"reading_shaders>`. Godot currently doesn't provide a built-in debanding "
"shader, but this may be added in a future release."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:45
msgid ""
"See `Banding in Games: A Noisy Rant <http://loopit.dk/banding_in_games."
"pdf>`__ for more details about banding and ways to combat it."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:49
msgid "Depth buffer precision"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:51
msgid ""
"To sort objects in 3D space, rendering engines rely on a *depth buffer* "
"(also called *Z-buffer*). This buffer has a finite precision: 24-bit on "
"desktop platforms, sometimes 16-bit on mobile platforms (for performance "
"reasons). If two different objects end up on the same buffer value, then Z-"
"fighting will occur. This will materialize as textures flickering back and "
"forth as the camera moves or rotates."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:58
msgid ""
"To make the depth buffer more precise over the rendered area, you should "
"*increase* the Camera node's **Near** property. However, be careful: if you "
"set it too high, players will be able to see through nearby geometry. You "
"should also *decrease* the Camera node's **Far** property to the lowest "
"permissible value for your use case, though keep in mind it won't impact "
"precision as much as the **Near** property."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:65
msgid ""
"If you only need high precision when the player can see far away, you could "
"change it dynamically based on the game conditions. For instance, if the "
"player enters an airplane, the **Near** property can be temporarily "
"increased to avoid Z-fighting in the distance. It can then be decreased once "
"the player leaves the airplane."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:71
msgid ""
"Depending on the scene and viewing conditions, you may also be able to move "
"the Z-fighting objects further apart without the difference being visible to "
"the player."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:76
msgid "Transparency sorting"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:78
msgid ""
"In Godot, transparent materials are drawn after opaque materials. "
"Transparent objects are sorted back to front before being drawn based on the "
"Node3D's position, not the vertex position in world space. Due to this, "
"overlapping objects may often be sorted out of order. To fix improperly "
"sorted objects, tweak the material's :ref:`Render Priority "
"<class_Material_property_render_priority>` property. This will force "
"specific materials to appear in front or behind of other transparent "
"materials. Even then, this may not always be sufficient."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:86
msgid ""
"Some rendering engines feature *order-independent transparency* techniques "
"to alleviate this, but this is costly on the GPU. Godot currently doesn't "
"provide this feature. There are still several ways to avoid this problem:"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:90
msgid ""
"Only make materials transparent if you actually need it. If a material only "
"has a small transparent part, consider splitting it into a separate "
"material. This will allow the opaque part to cast shadows and may also "
"improve performance."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:95
msgid ""
"If you want a material to fade with distance, use the SpatialMaterial "
"distance fade mode **Pixel Dither** or **Object Dither** instead of "
"**PixelAlpha**. This will make the material opaque. This way, it can also "
"cast shadows."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:101
msgid "Multi-sample antialiasing"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:103
msgid ""
"Multi-sample antialiasing (MSAA) takes multiple *coverage* samples at the "
"edges of polygons when rendering objects. It does not increase the number of "
"*color* samples used to render a scene. Here's what this means in practice:"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:107
msgid ""
"Edges of meshes will be smoothed out nicely (as well as supersampling would)."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:108
msgid ""
"Transparent materials that use *alpha testing* (1-bit transparency) won't be "
"smoothed out."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:109
msgid ""
"Specular aliasing (\"sparkles\" that appear on reflective surfaces) won't be "
"reduced."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:111
msgid ""
"There are several ways to work around this limitation depending on your "
"performance budget:"
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:113
msgid ""
"To make specular aliasing less noticeable, open the Project Settings and "
"enable **Rendering > Quality > Screen Space Filters > Screen Space Roughness "
"Limiter**. This filter has a moderate cost on performance. It should be "
"enabled only if you actually need it."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:118
msgid ""
"Enable FXAA in addition to (or instead of) MSAA. Since FXAA is a screen-"
"space antialiasing method, it will smooth out anything. As a downside, it "
"will also make the scene appear blurrier, especially at resolutions below "
"1440p."
msgstr ""

#: ../../docs/tutorials/3d/3d_rendering_limitations.rst:122
msgid ""
"Render the scene at a higher resolution, then display it in a "
"ViewportTexture that matches the window size. Make sure to enable **Filter** "
"on the ViewportTexture flags. This technique is called *supersampling* and "
"is very slow. Its use is generally only recommended for offline rendering."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:4
msgid "Spatial Material"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:9
msgid ""
"``SpatialMaterial`` is a default 3D material that aims to provide most of "
"the features artists look for in a material, without the need for writing "
"shader code. However, it can be converted to shader code if additional "
"functionality is needed."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:13
msgid "This tutorial explains most parameters present in ``SpatialMaterial``."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:15
msgid ""
"There are three ways to add a ``SpatialMaterial`` to an object. It can be "
"added in the *Material* property of the mesh. It can be added in the "
"*Material* property of the node using the mesh (such as a MeshInstance "
"node), or in the *Material Override* property of the node using the mesh."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:22
msgid ""
"If you add a material to the mesh itself, every time that mesh is used it "
"will have that material. If you add a material to the node using the mesh, "
"the material will only be used by that node, it will also override the "
"material property of the mesh. If a material is added in the *Material "
"Override* property of the node, it will only be used by that node. It will "
"also override the regular material property of the node and the material "
"property of the mesh."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:32
msgid ""
"Spatial materials have many flags determining the general usage of a "
"material."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:37
msgid "Transparent"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:39
msgid ""
"In Godot, materials are not transparent unless specifically configured to "
"be. The main reason behind this is that transparent materials are rendered "
"using a different technique (sorted from back to front and rendered in "
"order)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:43
msgid ""
"This technique is less efficient (many state changes happen) and makes the "
"materials unusable with many mid- and post-processing effects (such as SSAO, "
"SSR, etc.) that require perfectly opaque geometry."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:47
msgid ""
"For this reason, materials in Godot are assumed opaque unless specified "
"otherwise. The main settings that enable transparency are:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:50
msgid "Transparent flag (this one)"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:51
msgid "Blend mode set to other than \"Mix\""
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:52
msgid "Enabling distance or proximity fade"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:55
msgid "Use Shadow to Opacity"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:57
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:75
msgid ""
"Lighting modifies the alpha so shadowed areas are opaque and non-shadowed "
"areas are transparent. Useful for overlaying shadows onto a camera feed in "
"AR."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:61
msgid "Unshaded"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:63
msgid ""
"In most cases it is common for materials to be affected by lighting (shaded)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:65
msgid ""
"However, in some cases you might want to show just the albedo (color) and "
"ignore the rest. Toggling this flag on will remove all shading and display "
"pure, unlit color."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:72
msgid "Vertex Lighting"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:74
msgid ""
"Godot has a more or less uniform cost per pixel thanks to depth pre-pass. "
"All lighting calculations are made by running the lighting shader on every "
"pixel."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:77
msgid ""
"As these calculations are costly, performance can be brought down "
"considerably in some corner cases such as drawing several layers of "
"transparency (which is common in particle systems). Switching to per-vertex "
"lighting may help in these cases."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:82
msgid ""
"Additionally, on low-end or mobile devices, switching to vertex lighting can "
"considerably increase rendering performance."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:87
msgid ""
"Keep in mind that when vertex lighting is enabled, only directional lighting "
"can produce shadows (for performance reasons)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:91
msgid "No Depth Test"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:93
msgid ""
"In order for close objects to appear over far away objects, depth testing is "
"performed. Disabling it has the result of objects appearing over (or under) "
"everything else."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:97
msgid ""
"Disabling this makes the most sense for drawing indicators in world space, "
"and works very well with the *Render Priority* property of Material (see the "
"bottom of this page)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:104
msgid "Use Point Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:106
msgid ""
"This option is only effective when the geometry rendered is made of points "
"(generally it's made of triangles when imported from 3D DCCs). If so, then "
"those points can be resized (see below)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:111
msgid "World Triplanar"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:113
msgid ""
"When using triplanar mapping (see below, in the UV1 and UV2 settings), "
"triplanar is computed in object local space. This option makes triplanar "
"work in world space."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:118
msgid "Fixed Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:120
msgid ""
"This causes the object to be rendered at the same size no matter the "
"distance. This is useful mostly for indicators (no depth test and high "
"render priority) and some types of billboards."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:125
msgid "Do Not Receive Shadows"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:127
msgid ""
"Makes the object not receive any kind of shadow that would otherwise be cast "
"onto it."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:131
msgid "Disable Ambient Light"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:133
msgid ""
"Makes the object not receive any kind of ambient lighting that would "
"otherwise light it."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:137
msgid "Ensure Correct Normals"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:139
msgid "Fixes normals when non-uniform scaling is used."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:142
msgid "Vertex Color"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:144
msgid ""
"This setting allows choosing what is done by default to vertex colors that "
"come from your 3D modelling application. By default, they are ignored."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:150
msgid "Use as Albedo"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:152
msgid "Choosing this option means vertex color is used as albedo color."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:155
msgid "Is sRGB"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:157
msgid ""
"Most 3D DCCs will likely export vertex colors as sRGB, so toggling this "
"option on will help them look correct."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:161
#: ../../docs/tutorials/platform/services_for_ios.rst:87
#: ../../docs/tutorials/platform/services_for_ios.rst:127
#: ../../docs/tutorials/platform/services_for_ios.rst:198
#: ../../docs/tutorials/platform/services_for_ios.rst:242
#: ../../docs/tutorials/platform/services_for_ios.rst:387
msgid "Parameters"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:163
msgid ""
"``SpatialMaterial`` also has several configurable parameters to tweak many "
"aspects of the rendering:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:169
msgid "Diffuse Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:171
msgid ""
"Specifies the algorithm used by diffuse scattering of light when hitting the "
"object. The default is *Burley*. Other modes are also available:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:174
msgid ""
"**Burley:** Default mode, the original Disney Principled PBS diffuse "
"algorithm."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:175
msgid "**Lambert:** Is not affected by roughness."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:176
msgid ""
"**Lambert Wrap:** Extends Lambert to cover more than 90 degrees when "
"roughness increases. Works great for hair and simulating cheap subsurface "
"scattering. This implementation is energy conserving."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:179
msgid ""
"**Oren Nayar:** This implementation aims to take microsurfacing into account "
"(via roughness). Works well for clay-like materials and some types of cloth."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:181
msgid ""
"**Toon:** Provides a hard cut for lighting, with smoothing affected by "
"roughness. It is recommended you disable sky contribution from your "
"environment's ambient light settings or disable ambient light in the spatial "
"material to achieve a better effect."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:189
msgid "Specular Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:191
msgid ""
"Specifies how the specular blob will be rendered. The specular blob "
"represents the shape of a light source reflected in the object."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:194
msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:195
msgid ""
"**Blinn:** Common in previous-generation engines. Not worth using nowadays, "
"but left here for the sake of compatibility."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:197
msgid "**Phong:** Same as above."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:198
msgid ""
"**Toon:** Creates a toon blob, which changes size depending on roughness."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:199
msgid "**Disabled:** Sometimes the blob gets in the way. Begone!"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:204
msgid "Blend Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:206
msgid ""
"Controls the blend mode for the material. Keep in mind that any mode other "
"than *Mix* forces the object to go through the transparent pipeline."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:209
msgid ""
"**Mix:** Default blend mode, alpha controls how much the object is visible."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:210
msgid ""
"**Add:** Object is blended additively, nice for flares or some fire-like "
"effects."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:212
msgid "**Sub:** Object is subtracted."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:213
msgid "**Mul:** Object is multiplied."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:218
msgid "Cull Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:220
msgid ""
"Determines which side of the object is not drawn when backfaces are rendered:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:222
msgid "**Back:** The back of the object is culled when not visible (default)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:223
msgid "**Front:** The front of the object is culled when not visible."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:224
msgid ""
"**Disabled:** Used for objects that are double-sided (no culling is "
"performed)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:227
msgid "Depth Draw Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:229
msgid "Specifies when depth rendering must take place."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:231
msgid "**Opaque Only (default):** Depth is only drawn for opaque objects."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:232
msgid ""
"**Always:** Depth draw is drawn for both opaque and transparent objects."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:233
msgid ""
"**Never:** No depth draw takes place (do not confuse this with the No Depth "
"Test option above)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:235
msgid ""
"**Depth Pre-Pass:** For transparent objects, an opaque pass is made first "
"with the opaque parts, then transparency is drawn above. Use this option "
"with transparent grass or tree foliage."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:242
msgid "Line Width"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:244
msgid ""
"When drawing lines, specify the width of the lines being drawn. This option "
"is not available on most modern hardware."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:248
msgid "Point Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:250
msgid "When drawing points, specify the point size in pixels."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:253
msgid "Billboard Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:255
msgid ""
"Enables billboard mode for drawing materials. This controls how the object "
"faces the camera:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:258
msgid "**Disabled:** Billboard mode is disabled."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:259
msgid ""
"**Enabled:** Billboard mode is enabled, the object's -Z axis will always "
"face the camera."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:261
msgid ""
"**Y-Billboard:** The object's X axis will always be aligned with the camera."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:262
msgid ""
"**Particles:** Most suited for particle systems, because it allows "
"specifying animation options."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:267
msgid "The above options are only enabled for Particle Billboard."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:270
msgid "Billboard Keep Scale"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:272
msgid "Enables scaling a mesh in billboard mode."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:275
msgid "Grow"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:277
msgid "Grows the object vertices in the direction pointed by their normals:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:281
msgid ""
"This is commonly used to create cheap outlines. Add a second material pass, "
"make it black and unshaded, reverse culling (Cull Front), and add some grow:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:288
msgid "Use Alpha Scissor"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:290
msgid ""
"When transparency other than ``0`` or ``1`` is not needed, it's possible to "
"set a threshold to prevent the object from rendering semi-transparent pixels."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:295
msgid ""
"This renders the object via the opaque pipeline, which is faster and allows "
"it to use mid- and post-process effects such as SSAO, SSR, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:299
msgid "Material colors, maps and channels"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:301
msgid ""
"Besides the parameters, what defines materials themselves are the colors, "
"textures, and channels. Godot supports an extensive list of them. They are "
"described in detail below:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:306
msgid "Albedo"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:308
msgid ""
"*Albedo* is the base color for the material, on which all the other settings "
"operate. When set to *Unshaded*, this is the only color that is visible. In "
"previous versions of Godot, this channel was named *Diffuse*. The change of "
"name mainly happened because, in PBR (Physically Based Rendering), this "
"color affects many more calculations than just the diffuse lighting path."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:314
msgid "Albedo color and texture can be used together as they are multiplied."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:316
msgid ""
"*Alpha channel* in albedo color and texture is also used for the object "
"transparency. If you use a color or texture with *alpha channel*, make sure "
"to either enable transparency or *alpha scissoring* for it to work."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:321
msgid "Metallic"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:323
msgid ""
"Godot uses a metallic model over competing models due to its simplicity. "
"This parameter defines how reflective the material is. The more reflective, "
"the less diffuse/ambient light affects the material and the more light is "
"reflected. This model is called \"energy-conserving\"."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:328
msgid ""
"The *Specular* parameter is a general amount for the reflectivity (unlike "
"*Metallic*, this is not energy-conserving, so leave it at ``0.5`` and don't "
"touch it unless you need to)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:332
msgid ""
"The minimum internal reflectivity is ``0.04``, so it's impossible to make a "
"material completely unreflective, just like in real life."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:338
msgid "Roughness"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:340
msgid ""
"*Roughness* affects the way reflection happens. A value of ``0`` makes it a "
"perfect mirror while a value of ``1`` completely blurs the reflection "
"(simulating natural microsurfacing). Most common types of materials can be "
"achieved with the right combination of *Metallic* and *Roughness*."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:348
msgid "Emission"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:350
msgid ""
"*Emission* specifies how much light is emitted by the material (keep in mind "
"this does not include light surrounding geometry unless :ref:`doc_gi_probes` "
"are used). This value is added to the resulting final image and is not "
"affected by other lighting in the scene."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:358
msgid "Normal map"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:360
msgid ""
"Normal mapping allows you to set a texture that represents finer shape "
"detail. This does not modify geometry, only the incident angle for light. In "
"Godot, only the red and green channels of normal maps are used for better "
"compression and wider compatibility."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:379
msgid "Rim"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:381
msgid ""
"Some fabrics have small micro-fur that causes light to scatter around it. "
"Godot emulates this with the *Rim* parameter. Unlike other rim lighting "
"implementations, which just use the emission channel, this one actually "
"takes light into account (no light means no rim). This makes the effect "
"considerably more believable."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:388
msgid ""
"Rim size depends on roughness, and there is a special parameter to specify "
"how it must be colored. If *Tint* is ``0``, the color of the light is used "
"for the rim. If *Tint* is ``1``, then the albedo of the material is used. "
"Using intermediate values generally works best."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:394
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:61
msgid "Clearcoat"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:396
#: ../../docs/tutorials/3d/spatial_material.rst:405
#: ../../docs/tutorials/3d/spatial_material.rst:427
#: ../../docs/tutorials/3d/spatial_material.rst:440
#: ../../docs/tutorials/3d/spatial_material.rst:460
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:140
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:196
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:222
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:268
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:301
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:354
msgid "*This feature is only available when using the GLES3 backend.*"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:398
msgid ""
"The *Clearcoat* parameter is used to add a secondary pass of transparent "
"coat to the material. This is common in car paint and toys. In practice, "
"it's a smaller specular blob added on top of the existing material."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:403
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:60
msgid "Anisotropy"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:407
msgid ""
"This changes the shape of the specular blob and aligns it to tangent space. "
"Anisotropy is commonly used with hair, or to make materials such as brushed "
"aluminum more realistic. It works especially well when combined with "
"flowmaps."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:414
msgid "Ambient Occlusion"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:416
msgid ""
"It is possible to specify a baked ambient occlusion map. This map affects "
"how much ambient light reaches each surface of the object (it does not "
"affect direct light by default). While it is possible to use Screen-Space "
"Ambient Occlusion (SSAO) to generate ambient occlusion, nothing beats the "
"quality of a well-baked AO map. It is recommended to bake ambient occlusion "
"whenever possible."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:425
msgid "Depth"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:429
msgid ""
"Setting a depth map on a material produces a ray-marched search to emulate "
"the proper displacement of cavities along the view direction. This is not "
"real added geometry, but an illusion of depth. It may not work for complex "
"objects, but it produces a realistic depth effect for textures. For best "
"results, *Depth* should be used together with normal mapping."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:438
msgid "Subsurface Scattering"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:442
msgid ""
"This effect emulates light that penetrates an object's surface, is "
"scattered, and then comes out. It is useful to create realistic skin, "
"marble, colored liquids, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:449
msgid "Transmission"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:451
msgid ""
"This controls how much light from the lit side (visible to light) is "
"transferred to the dark side (opposite from the light). This works well for "
"thin objects such as plant leaves, grass, human ears, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:458
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:58
msgid "Refraction"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:462
msgid ""
"When refraction is enabled, it supersedes alpha blending, and Godot attempts "
"to fetch information from behind the object being rendered instead. This "
"allows distorting the transparency in a way similar to refraction in real "
"life."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:469
msgid "Detail"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:471
msgid ""
"Godot allows using secondary albedo and normal maps to generate a detail "
"texture, which can be blended in many ways. By combining this with secondary "
"UV or triplanar modes, many interesting textures can be achieved."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:477
msgid "There are several settings that control how detail is used."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:479
msgid ""
"Mask: The detail mask is a black and white image used to control where the "
"blending takes place on a texture. White is for the detail textures, Black "
"is for the regular material textures, different shades of gray are for "
"partial blending of the material textures and detail textures."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:484
msgid ""
"Blend Mode: These four modes control how the textures are blended together."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:486
msgid ""
"Mix: Combines pixel values of both textures. At black, only show the "
"material texture, at white, only show the detail texture. Values of gray "
"create a smooth blend between the two."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:490
msgid ""
"Add: Adds pixel values of one Texture with the other. Unlike mix mode both "
"textures are completely mixed at white parts of a mask and not at gray "
"parts. The original texture is mostly unchanged at black"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:494
msgid ""
"Sub: Subtracts pixel values of one texture with the other. The second "
"texture is completely subtracted at white parts of a mask with only a little "
"subtraction in black parts, gray parts being different levels of subtraction "
"based on the exact texture."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:499
msgid ""
"Mul: Multiplies the RGB channel numbers for each pixel from the top texture "
"with the values for the corresponding pixel from the bottom texture."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:502
msgid ""
"Albedo: This is where you put an albedo texture you want to blend. If "
"nothing is in this slot it will be interpreted as white by default."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:505
msgid ""
"Normal: This is where you put a normal texture you want to blend. If nothing "
"is in this slot it will be interpreted as a flat normal map. This can still "
"be used even if the material does not have normal map enabled."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:510
msgid "UV1 and UV2"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:512
msgid ""
"Godot supports two UV channels per material. Secondary UV is often useful "
"for ambient occlusion or emission (baked light). UVs can be scaled and "
"offset, which is useful when using repeating textures."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:517
msgid "Triplanar Mapping"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:519
msgid ""
"Triplanar mapping is supported for both UV1 and UV2. This is an alternative "
"way to obtain texture coordinates, sometimes called \"Autotexture\". "
"Textures are sampled in X, Y and Z and blended by the normal. Triplanar "
"mapping can be performed in either world space or object space."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:524
msgid ""
"In the image below, you can see how all primitives share the same material "
"with world triplanar, so the brick texture continues smoothly between them."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:530
msgid "Proximity and distance fade"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:532
msgid ""
"Godot allows materials to fade by proximity to each other as well as "
"depending on the distance from the viewer. Proximity fade is useful for "
"effects such as soft particles or a mass of water with a smooth blending to "
"the shores. Distance fade is useful for light shafts or indicators that are "
"only present after a given distance."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:538
msgid ""
"Keep in mind enabling these enables alpha blending, so abusing them for an "
"entire scene is usually not a good idea."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:544
msgid "Render priority"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:546
msgid ""
"The rendering order of objects can be changed, although this is mostly "
"useful for transparent objects (or opaque objects that perform depth draw "
"but no color draw, such as cracks on the floor)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:4
msgid "Lights and shadows"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:9
msgid ""
"Light sources emit light that mixes with the materials and produces a "
"visible result. Light can come from several types of sources in a scene:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:12
msgid ""
"From the Material itself in the form of the emission color (though it does "
"not affect nearby objects unless baked)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:14
msgid "Light Nodes: Directional, Omni and Spot."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:15
msgid "Ambient Light in the :ref:`Environment <class_Environment>`."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:17
msgid "Baked Light (read :ref:`doc_baked_lightmaps`)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:19
msgid ""
"The emission color is a material property. You can read more about it in "
"the :ref:`doc_spatial_material` tutorial."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:23
msgid "Light nodes"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:25
msgid ""
"There are three types of light nodes: `Directional light`_, `Omni light`_ "
"and `Spot light`_. Let's take a look at the common parameters for lights:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:31
msgid "Each one has a specific function:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:33
msgid "**Color**: Base color for emitted light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:34
msgid ""
"**Energy**: Energy multiplier. This is useful for saturating lights or "
"working with :ref:`doc_high_dynamic_range`."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:35
msgid ""
"**Indirect Energy**: Secondary multiplier used with indirect light (light "
"bounces). This works in baked light or GIProbe."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:36
msgid ""
"**Negative**: Light becomes subtractive instead of additive. It's sometimes "
"useful to manually compensate some dark corners."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:37
msgid ""
"**Specular**: Affects the intensity of the specular blob in objects affected "
"by this light. At zero, this light becomes a pure diffuse light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:38
msgid ""
"**Bake Mode**: Sets the bake mode for the light. For more information see :"
"ref:`doc_baked_lightmaps`"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:39
msgid ""
"**Cull Mask**: Objects that are in the selected layers below will be "
"affected by this light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:42
msgid "Shadow mapping"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:44
msgid ""
"Lights can optionally cast shadows. This gives them greater realism (light "
"does not reach occluded areas), but it can incur a bigger performance cost. "
"There is a list of generic shadow parameters, each also has a specific "
"function:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:48
msgid "**Enabled**: Check to enable shadow mapping in this light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:49
msgid ""
"**Color**: Areas occluded are multiplied by this color. It is black by "
"default, but it can be changed to tint shadows."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:50
msgid ""
"**Bias**: When this parameter is too small, self shadowing occurs. When too "
"large, shadows separate from the casters. Tweak to what works best for you."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:51
msgid ""
"**Contact**: Performs a short screen-space raycast to reduce the gap "
"generated by the bias. Contact shadows are only available when using the "
"GLES3 backend."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:52
msgid ""
"**Reverse Cull Faces**: Some scenes work better when shadow mapping is "
"rendered with face-culling inverted."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:54
msgid ""
"Below is an image of what tweaking bias looks like. Default values work for "
"most cases, but in general it depends on the size and complexity of geometry."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:59
msgid "Finally, if gaps can't be solved, the **Contact** option can help:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:63
msgid ""
"Any sort of bias issues can always be fixed by increasing the shadow map "
"resolution, although that may lead to decreased performance on low-end "
"hardware."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:67
msgid "Directional light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:69
msgid ""
"This is the most common type of light and represents a light source very far "
"away (such as the sun). It is also the cheapest light to compute and should "
"be used whenever possible (although it's not the cheapest shadow-map to "
"compute, but more on that later)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:73
msgid ""
"Directional light models an infinite number of parallel light rays covering "
"the whole scene. The directional light node is represented by a big arrow "
"which indicates the direction of the light rays. However, the position of "
"the node does not affect the lighting at all and can be anywhere."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:80
msgid ""
"Every face whose front-side is hit by the light rays is lit, while the "
"others stay dark. Most light types have specific parameters, but directional "
"lights are pretty simple in nature, so they don't."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:84
msgid "Directional shadow mapping"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:86
msgid ""
"To compute shadow maps, the scene is rendered (only depth) from an "
"orthogonal point of view that covers the whole scene (or up to the max "
"distance). There is, however, a problem with this approach because objects "
"closer to the camera receive blocky shadows."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:92
msgid ""
"To fix this, a technique named \"Parallel Split Shadow Maps\" (or PSSM) is "
"used. This splits the view frustum in 2 or 4 areas. Each area gets its own "
"shadow map. This allows small areas close to the viewer to have the same "
"shadow resolution as a huge, far-away area."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:97
msgid "With this, shadows become more detailed:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:101
msgid "To control PSSM, a number of parameters are exposed:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:105
msgid ""
"Each split distance is controlled relative to the camera far (or shadow "
"**Max Distance** if greater than zero), so *0.0* is the eye position and "
"*1.0* is where the shadow ends at a distance. Splits are in-between. Default "
"values generally work well, but tweaking the first split a bit is common to "
"give more detail to close objects (like a character in a third person game)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:111
msgid ""
"Always make sure to set a shadow *Max Distance* according to what the scene "
"needs. A lower maximum distance will result in better-looking shadows."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:114
msgid ""
"Sometimes, the transition between a split and the next can look bad. To fix "
"this, the **\"Blend Splits\"** option can be turned on, which sacrifices "
"detail in exchange for smoother transitions:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:120
msgid ""
"The **\"Normal Bias\"** parameter can be used to fix special cases of self "
"shadowing when objects are perpendicular to the light. The only downside is "
"that it makes the shadow a bit thinner."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:126
msgid ""
"The **\"Bias Split Scale\"** parameter can control extra bias for the splits "
"that are far away. If self shadowing occurs only on the splits far away, "
"this value can fix them."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:129
msgid "Finally, the **\"Depth Range\"** has two settings:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:131
msgid ""
"**Stable**: Keeps the shadow stable while the camera moves, and the blocks "
"that appear in the outline when close to the shadow edges remain in-place. "
"This is the default and generally desired, but it reduces the effective "
"shadow resolution."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:132
msgid ""
"**Optimized**: Tries to achieve the maximum resolution available at any "
"given time. This may result in a \"moving saw\" effect on shadow edges, but "
"at the same time the shadow looks more detailed (so this effect may be "
"subtle enough to be forgiven)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:134
msgid "Just experiment which setting works better for your scene."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:136
msgid ""
"Shadowmap size for directional lights can be changed in Project Settings -> "
"Rendering -> Quality:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:140
msgid ""
"Increasing it can solve bias problems, but decrease performance. Shadow "
"mapping is an art of tweaking."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:143
msgid "Omni light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:145
msgid ""
"Omni light is a point source that emits light spherically in all directions "
"up to a given radius."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:150
msgid ""
"In real life, light attenuation is an inverse function, which means omni "
"lights don't have a radius. This is a problem because it means computing "
"several omni lights would become demanding."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:153
msgid ""
"To solve this, a *Range* is introduced together with an attenuation function."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:157
msgid ""
"These two parameters allow tweaking how this works visually in order to find "
"aesthetically pleasing results."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:163
msgid "Omni shadow mapping"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:165
msgid ""
"Omni light shadow mapping is relatively straightforward. The main issue that "
"needs to be considered is the algorithm used to render it."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:168
msgid ""
"Omni Shadows can be rendered as either **\"Dual Paraboloid\" or \"Cube Mapped"
"\"**. The former renders quickly, but can cause deformations, while the "
"later is more correct, but costlier."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:174
msgid ""
"If the objects being rendered are mostly irregular, Dual Paraboloid is "
"usually enough. In any case, as these shadows are cached in a shadow atlas "
"(more on that at the end), it may not make a difference in performance for "
"most scenes."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:179
msgid "Spot light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:181
msgid ""
"Spot lights are similar to omni lights, except they emit light only into a "
"cone (or \"cutoff\"). They are useful to simulate flashlights, car lights, "
"reflectors, spots, etc. This type of light is also attenuated towards the "
"opposite direction it points to."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:188
msgid ""
"Spot lights share the same **Range** and **Attenuation** as **OmniLight**, "
"and add two extra parameters:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:190
msgid "**Angle**: The aperture angle of the light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:191
msgid ""
"**Angle Attenuation**: The cone attenuation, which helps soften the cone "
"borders."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:194
msgid "Spot shadow mapping"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:196
msgid ""
"Spots don't need any parameters for shadow mapping. Keep in mind that, at "
"more than 89 degrees of aperture, shadows stop functioning for spots, and "
"you should consider using an Omni light instead."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:200
msgid "Shadow atlas"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:202
msgid ""
"Unlike Directional lights, which have their own shadow texture, Omni and "
"Spot lights are assigned to slots of a shadow atlas. This atlas can be "
"configured in Project Settings -> Rendering -> Quality -> Shadow Atlas."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:207
msgid ""
"The resolution applies to the whole Shadow Atlas. This atlas is divided into "
"four quadrants:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:211
msgid ""
"Each quadrant can be subdivided to allocate any number of shadow maps; the "
"following is the default subdivision:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:215
msgid ""
"The allocation logic is simple. The biggest shadow map size (when no "
"subdivision is used) represents a light the size of the screen (or bigger). "
"Subdivisions (smaller maps) represent shadows for lights that are further "
"away from view and proportionally smaller."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:220
msgid "Every frame, the following procedure is performed for all lights:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:222
msgid ""
"Check if the light is on a slot of the right size. If not, re-render it and "
"move it to a larger/smaller slot."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:223
msgid ""
"Check if any object affecting the shadow map has changed. If it did, re-"
"render the light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:224
msgid ""
"If neither of the above has happened, nothing is done, and the shadow is "
"left untouched."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:226
msgid ""
"If the slots in a quadrant are full, lights are pushed back to smaller "
"slots, depending on size and distance."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:228
msgid ""
"This allocation strategy works for most games, but you may want to use a "
"separate one in some cases (for example, a top-down game where all lights "
"are around the same size and quadrants may all have the same subdivision)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:232
msgid "Shadow filter quality"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:234
msgid ""
"The filter quality of shadows can be tweaked. This can be found in Project "
"Settings -> Rendering -> Quality -> Shadows. Godot supports no filter, PCF5 "
"and PCF13."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:240
msgid "It affects the blockyness of the shadow outline:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:4
msgid "Reflection probes"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:9
msgid ""
"As stated in the :ref:`doc_spatial_material`, objects can show reflected or "
"diffuse light. Reflection probes are used as a source of reflected and "
"ambient light for objects inside their area of influence."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:12
msgid ""
"A probe of this type captures the surroundings (as a sort of 360 degrees "
"image), and stores versions of it with increasing levels of *blur*. This is "
"used to simulate roughness in materials, as well as ambient lighting."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:15
msgid ""
"While these probes are an efficient way of storing reflections, they have a "
"few shortcomings:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:17
msgid ""
"They are efficient to render, but expensive to compute. This leads to a "
"default behavior where they only capture on scene load."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:18
msgid ""
"They work best for rectangular shaped rooms or places, otherwise the "
"reflections shown are not as faithful (especially when roughness is 0)."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:23
msgid ""
"Create a ReflectionProbe node and wrap it around the area where you want to "
"have reflections:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:27
msgid ""
"This should result in immediate local reflections. If you are using a Sky "
"texture, reflections are by default blended with it."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:30
msgid ""
"By default, on interiors, reflections may appear not to have much "
"consistence. In this scenario, make sure to tick the *\"Box Correct\"* "
"property."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:36
msgid ""
"This setting changes the reflection from an infinite skybox to reflecting a "
"box the size of the probe:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:41
msgid ""
"Adjusting the box walls may help improve the reflection a bit, but it will "
"always look best in box shaped rooms."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:44
msgid ""
"The probe captures the surrounding from the center of the gizmo. If, for "
"some reason, the room shape or contents occlude the center, it can be "
"displaced to an empty place by moving the handles in the center:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:50
msgid ""
"By default, shadow mapping is disabled when rendering probes (only in the "
"rendered image inside the probe, not the actual scene). This is a simple way "
"to save on performance and memory. If you want shadows in the probe, they "
"can be toggled on/off with the *Enable Shadow* setting:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:57
msgid ""
"Finally, keep in mind that you may not want the Reflection Probe to render "
"some objects. A typical scenario is an enemy inside the room which will move "
"around. To keep objects from being rendered in the reflections, use the "
"*Cull Mask* setting:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:65
#: ../../docs/tutorials/3d/gi_probes.rst:88
msgid "Interior vs exterior"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:67
msgid ""
"If you are using reflection probes in an interior setting, it is recommended "
"that the **Interior** property be enabled. This stops the probe from "
"rendering the sky and also allows custom ambient lighting settings."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:73
msgid ""
"When probes are set to **Interior**, custom constant ambient lighting can be "
"specified per probe. Just choose a color and an energy."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:76
msgid ""
"Optionally, you can blend this ambient light with the probe diffuse capture "
"by tweaking the **Ambient Contribution** property (0.0 means pure ambient "
"color, while 1.0 means pure diffuse capture)."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:81
msgid "Blending"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:83
msgid ""
"Multiple reflection probes can be used, and Godot will blend them where they "
"overlap using a smart algorithm:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:87
msgid ""
"As you can see, this blending is never perfect (after all, these are box "
"reflections, not real reflections), but these artifacts are only visible "
"when using perfectly mirrored reflections. Normally, scenes have normal "
"mapping and varying levels of roughness, which can hide this."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:93
msgid ""
"Alternatively, Reflection Probes work well blended together with Screen "
"Space Reflections to solve these problems. Combining them makes local "
"reflections appear more faithful, while probes are only used as a fallback "
"when no screen-space information is found:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:99
msgid ""
"Finally, blending interior and exterior probes is the recommended approach "
"when making levels that combine both interiors and exteriors. Near the door, "
"a probe can be marked as *exterior* (so it will get sky reflections) while "
"on the inside, it can be interior."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:104
msgid "Reflection atlas"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:106
msgid ""
"In the current renderer implementation, all probes are the same size and are "
"fit into a Reflection Atlas. The size and amount of probes can be customized "
"in Project Settings -> Quality -> Reflections"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:110
msgid ""
"The default setting of Atlas Subdiv: 8 will allow up to 16 reflection probes "
"in a scene. This value needs to be increased if you need more reflection "
"probes."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:4
msgid "GI Probes"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:9
msgid ""
"This feature is only available when using the GLES3 backend. :ref:"
"`doc_baked_lightmaps` can be used as an alternative when using the GLES2 "
"renderer."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:13
msgid ""
"Just like with :ref:`doc_reflection_probes`, and as stated in the :ref:"
"`doc_spatial_material`, objects can show reflected or diffuse light. GI "
"Probes are similar to Reflection Probes, but they use a different and more "
"complex technique to produce indirect light and reflections."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:18
msgid ""
"The strength of GI Probes is real-time, high quality, indirect light. While "
"the scene needs a quick pre-bake for the static objects that will be used, "
"lights can be added, changed or removed, and this will be updated in real-"
"time. Dynamic objects that move within one of these probes will also receive "
"indirect lighting from the scene automatically."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:24
msgid ""
"Just like with ``ReflectionProbe``, ``GIProbe`` can be blended (in a bit "
"more limited way), so it is possible to provide full real-time lighting for "
"a stage without having to resort to lightmaps."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:28
msgid "The main downsides of ``GIProbe`` are:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:30
msgid ""
"A small amount of light leaking can occur if the level is not carefully "
"designed. This must be artist-tweaked."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:31
msgid ""
"Performance requirements are higher than for lightmaps, so it may not run "
"properly in low-end integrated GPUs (may need to reduce resolution)."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:32
msgid ""
"Reflections are voxelized, so they don't look as sharp as with "
"``ReflectionProbe``. However, in exchange they are volumetric, so any room "
"size or shape works for them. Mixing them with Screen Space Reflection also "
"works well."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:33
msgid ""
"They consume considerably more video memory than Reflection Probes, so they "
"must be used with care in the right subdivision sizes."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:38
msgid ""
"Just like a ``ReflectionProbe``, simply set up the ``GIProbe`` by wrapping "
"it around the geometry that will be affected."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:43
msgid ""
"Afterwards, make sure to enable the geometry will be baked. This is "
"important in order for ``GIProbe`` to recognize objects, otherwise they will "
"be ignored:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:48
msgid ""
"Once the geometry is set up, push the Bake button that appears on the 3D "
"editor toolbar to begin the pre-baking process:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:54
msgid "Adding lights"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:56
msgid ""
"Unless there are materials with emission, ``GIProbe`` does nothing by "
"default. Lights need to be added to the scene to have an effect."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:59
msgid ""
"The effect of indirect light can be viewed quickly (it is recommended you "
"turn off all ambient/sky lighting to tweak this, though, as shown below):"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:64
msgid ""
"In some situations, though, indirect light may be too weak. Lights have an "
"indirect multiplier to tweak this:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:69
msgid ""
"And, as ``GIProbe`` lighting updates in real-time, this effect is immediate:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:74
msgid "Reflections"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:76
msgid ""
"For very metallic materials with low roughness, it's possible to appreciate "
"voxel reflections. Keep in mind that these have far less detail than "
"Reflection Probes or Screen Space Reflections, but fully reflect "
"volumetrically."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:82
msgid ""
"``GIProbe``\\ s can be easily mixed with Reflection Probes and Screen Space "
"Reflections, as a full 3-stage fallback-chain. This allows to have precise "
"reflections where needed:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:90
msgid ""
"GI Probes normally allow mixing with lighting from the sky. This can be "
"disabled when turning on the *Interior* setting."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:95
msgid ""
"The difference becomes clear in the image below, where light from the sky "
"goes from spreading inside to being ignored."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:100
msgid ""
"As complex buildings may mix interiors with exteriors, combining GIProbes "
"for both parts works well."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:104
msgid "Tweaking"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:106
msgid "GI Probes support a few parameters for tweaking:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:110
msgid ""
"**Subdiv** Subdivision used for the probe. The default (128) is generally "
"good for small- to medium-sized areas. Bigger subdivisions use more memory."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:111
msgid "**Extents** Size of the probe. Can be tweaked from the gizmo."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:112
msgid ""
"**Dynamic Range** Maximum light energy the probe can absorb. Higher values "
"allow brighter light, but with less color detail."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:113
msgid ""
"**Energy** Multiplier for all the probe. Can be used to make the indirect "
"light brighter (although it's better to tweak this from the light itself)."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:114
msgid "**Propagation** How much light propagates through the probe internally."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:115
msgid ""
"**Bias** Value used to avoid self-occlusion when doing voxel cone tracing, "
"should generally be above 1.0 (1==voxel size)."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:116
msgid ""
"**Normal Bias** Alternative type of bias useful for some scenes. Experiment "
"with this one if regular bias does not work."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:117
msgid "**Interior** Allows mixing with lighting from the sky."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:118
msgid "**Compress** Currently broken. Do not use."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:119
msgid ""
"**Data** Contains the light baked data after baking. If you are saving the "
"data it should be saved as a .res file."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:122
msgid "Quality"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:124
msgid ""
"``GIProbe``\\ s are quite demanding. It is possible to use lower quality "
"voxel cone tracing in exchange for more performance."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:4
msgid "Baked lightmaps"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:9
msgid ""
"Baked lightmaps are an alternative workflow for adding indirect (or baked) "
"lighting to a scene. Unlike the :ref:`doc_gi_probes` approach, baked "
"lightmaps work fine on low-end PCs and mobile devices, as they consume "
"almost no resources at run-time."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:14
msgid ""
"Unlike ``GIProbe``\\ s, Baked Lightmaps are completely static. Once baked, "
"they can't be modified at all. They also don't provide the scene with "
"reflections, so using :ref:`doc_reflection_probes` together with it on "
"interiors (or using a Sky on exteriors) is a requirement to get good quality."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:19
msgid ""
"As they are baked, they have fewer problems than ``GIProbe`` regarding light "
"bleeding, and indirect light can look better if using Raytrace mode on high "
"quality setting (but baking can take a while)."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:23
msgid ""
"In the end, deciding which indirect lighting approach is better depends on "
"your use case. In general, GIProbe looks better and is much easier to set "
"up. For mobile or low-end compatibility, though, Baked Lightmaps are your "
"only choice."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:29
msgid "Visual comparison"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:31
msgid ""
"Here are some comparisons of how Baked Lightmaps vs. GIProbe look. Notice "
"that lightmaps are more accurate, but also suffer from the fact that "
"lighting is on an unwrapped texture, so transitions and resolution may not "
"be that good. GIProbe looks less accurate (as it's an approximation), but "
"smoother overall."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:42
msgid ""
"First of all, before the lightmapper can do anything, the objects to be "
"baked need an UV2 layer and a texture size. An UV2 layer is a set of "
"secondary texture coordinates that ensures any face in the object has its "
"own place in the UV map. Faces must not share pixels in the texture."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:47
msgid ""
"There are a few ways to ensure your object has a unique UV2 layer and "
"texture size:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:50
msgid "Unwrap from your 3D DCC"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:52
msgid ""
"One option is to do it from your favorite 3D app. This approach is generally "
"not recommended, but it's explained first so that you know it exists. The "
"main advantage is that, on complex objects that you may want to re-import a "
"lot, the texture generation process can be quite costly within Godot, so "
"having it unwrapped before import can be faster."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:58
msgid "Simply do an unwrap on the second UV2 layer."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:62
msgid ""
"And import normally. Remember you will need to set the texture size on the "
"mesh after import."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:67
msgid ""
"If you use external meshes on import, the size will be kept. Be wary that "
"most unwrappers in 3D DCCs are not quality oriented, as they are meant to "
"work quickly. You will mostly need to use seams or other techniques to "
"create better unwrapping."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:73
msgid "Unwrap from within Godot"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:75
msgid ""
"Godot has an option to unwrap meshes and visualize the UV channels. It can "
"be found in the Mesh menu:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:80
msgid ""
"This will generate a second set of UV2 coordinates which can be used for "
"baking, and it will also set the texture size automatically."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:84
msgid "Unwrap on scene import"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:86
msgid ""
"This is probably the best approach overall. The only downside is that, on "
"large models, unwrapping can take a while on import. Just select the "
"imported scene in the filesystem dock, then go to the Import tab. There, the "
"following option can be modified:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:93
msgid ""
"The **Light Baking** mode needs to be set to **\"Gen Lightmaps\"**. A texel "
"size in world units must also be provided, as this will determine the final "
"size of the lightmap texture (and, in consequence, the UV padding in the "
"map)."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:97
msgid ""
"The effect of setting this option is that all meshes within the scene will "
"have their UV2 maps properly generated."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:100
msgid ""
"As a word of warning: When reusing a mesh within a scene, keep in mind that "
"UVs will be generated for the first instance found. If the mesh is re-used "
"with different scales (and the scales are wildly different, more than half "
"or twice), this will result in inefficient lightmaps. Just don't reuse a "
"source mesh at different scales if you are planning to use lightmapping."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:107
msgid "Checking UV2"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:109
msgid ""
"In the mesh menu mentioned before, the UV2 texture coordinates can be "
"visualized. Make sure, if something is failing, to check that the meshes "
"have these UV2 coordinates:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:115
msgid "Setting up the scene"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:117
msgid ""
"Before anything is done, a **BakedLightmap** Node needs to be added to a "
"scene. This will enable light baking on all nodes (and sub-nodes) in that "
"scene, even on instanced scenes."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:123
msgid ""
"A sub-scene can be instanced several times, as this is supported by the "
"baker, and each will be assigned a lightmap of its own (just make sure to "
"respect the rule about scaling mentioned before):"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:128
msgid "Configure bounds"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:130
msgid ""
"Lightmap needs an approximate volume of the area affected because it uses it "
"to transfer light to dynamic objects inside it (more on that later). Just "
"cover the scene with the volume as you do with ``GIProbe``:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:137
msgid "Setting up meshes"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:139
msgid ""
"For a **MeshInstance** node to take part in the baking process, it needs to "
"have the \"Use in Baked Light\" property enabled."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:144
msgid ""
"When auto-generating lightmaps on scene import, this is enabled "
"automatically."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:147
msgid "Setting up lights"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:149
msgid ""
"Lights are baked with indirect light by default. This means that "
"shadowmapping and lighting are still dynamic and affect moving objects, but "
"light bounces from that light will be baked."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:153
msgid ""
"Lights can be disabled (no bake) or be fully baked (direct and indirect). "
"This can be controlled from the **Bake Mode** menu in lights:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:158
msgid "The modes are:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:160
msgid ""
"**Disabled:** Light is ignored in baking. Keep in mind hiding a light will "
"have no effect for baking, so this must be used instead."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:161
msgid ""
"**Indirect:** This is the default mode. Only indirect lighting will be baked."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:162
msgid ""
"**All:** Both indirect and direct lighting will be baked. If you don't want "
"the light to appear twice (dynamically and statically), simply hide it."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:165
msgid "Baking quality"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:167
msgid ""
"``BakedLightmap`` uses, for simplicity, a voxelized version of the scene to "
"compute lighting. Voxel size can be adjusted with the **Bake Subdiv** "
"parameter. More subdivision results in more detail, but also takes more time "
"to bake."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:171
msgid ""
"In general, the defaults are good enough. There is also a **Capture "
"Subdivision** (that must always be equal to or less than the main "
"subdivision), which is used for capturing light in dynamic objects (more on "
"that later). Its default value is also good enough for most cases."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:178
msgid ""
"Besides the capture size, quality can be modified by setting the **Bake "
"Mode**. Two modes of capturing indirect are provided:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:183
msgid ""
"**Voxel Cone**: Trace: Is the default one; it's less precise, but faster. "
"Looks similar to (but slightly better than) ``GIProbe``."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:184
msgid ""
"**Ray Tracing**: This method is more precise, but can take considerably "
"longer to bake. If used in low or medium quality, some scenes may produce "
"grain."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:187
msgid "Baking"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:189
msgid ""
"To begin the bake process, just push the big **Bake Lightmaps** button on "
"top when selecting the ``BakedLightmap`` node:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:194
msgid ""
"This can take from seconds to minutes (or hours) depending on scene size, "
"bake method and quality selected."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:198
msgid "Configuring bake"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:200
msgid "Several more options are present for baking:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:202
msgid ""
"**Bake Subdiv**: The Godot lightmapper uses a grid to transfer light "
"information around; the default value is fine and should work for most "
"cases. Increase it in case you want better lighting on small details or your "
"scene is large."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:203
msgid ""
"**Capture Subdiv**: This is the grid used for real-time capture information "
"(lighting dynamic objects). Default value is generally OK, it's usually "
"smaller than Bake Subdiv and can't be larger than it."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:204
msgid ""
"**Bake Quality**: Three bake quality modes are provided, Low, Medium and "
"High. Higher quality takes more time."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:205
msgid ""
"**Bake Mode**: The baker can use two different techniques: *Voxel Cone "
"Tracing* (fast, but approximate), or *RayTracing* (slow, but accurate)."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:206
msgid ""
"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in "
"``GIProbe``."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:207
msgid ""
"**HDR**: If disabled, lightmaps are smaller, but can't capture any light "
"over white (1.0)."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:208
msgid ""
"**Image Path**: Where lightmaps will be saved. By default, on the same "
"directory as the scene (\".\"), but can be tweaked."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:209
msgid "**Extents**: Size of the area affected (can be edited visually)"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:210
msgid ""
"**Light Data**: Contains the light baked data after baking. Textures are "
"saved to disk, but this also contains the capture data for dynamic objects, "
"which can be a bit heavy. If you are using .tscn formats (instead of .scn), "
"you can save it to disk."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:213
msgid "Dynamic objects"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:215
msgid ""
"In other engines or lightmapper implementations, you are required to "
"manually place small objects called \"lightprobes\" all around the level to "
"generate *capture* data. This is used to, then, transfer the light to "
"dynamic objects that move around the scene."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:220
msgid ""
"However, this implementation of lightmapping uses a different method. The "
"process is automatic, so you don't have to do anything. Just move your "
"objects around, and they will be lit accordingly. Of course, you have to "
"make sure you set up your scene bounds accordingly or it won't work."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:4
msgid "Environment and post-processing"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:6
msgid ""
"Godot 3 provides a redesigned Environment resource, as well as a new post-"
"processing system with many available effects right out of the box."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:12
msgid ""
"The Environment resource stores all the information required for controlling "
"rendering environment. This includes sky, ambient lighting, tone mapping, "
"effects, and adjustments. By itself it does nothing, but it becomes enabled "
"once used in one of the following locations in order of priority:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:18
msgid "Camera node"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:20
msgid ""
"An Environment can be set to a camera. It will have priority over any other "
"setting."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:24
msgid ""
"This is mostly useful when wanting to override an existing environment, but "
"in general it's a better idea to use the option below."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:28
msgid "WorldEnvironment node"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:30
msgid ""
"The WorldEnvironment node can be added to any scene, but only one can exist "
"per active scene tree. Adding more than one will result in a warning."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:35
msgid ""
"Any Environment added has higher priority than the default Environment "
"(explained below). This means it can be overridden on a per-scene basis, "
"which makes it quite useful."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:42
msgid ""
"A default environment can be set, which acts as a fallback when no "
"Environment was set to a Camera or WorldEnvironment. Just head to Project "
"Settings -> Rendering -> Environment:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:48
msgid ""
"New projects created from the Project Manager come with a default "
"environment (``default_env.tres``). If one needs to be created, save it to "
"disk before referencing it here."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:53
msgid "Environment options"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:55
msgid ""
"Following is a detailed description of all environment options and how they "
"are intended to be used."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:61
msgid ""
"The Background section contains settings on how to fill the background "
"(parts of the screen where objects were not drawn). In Godot 3.0, the "
"background not only serves the purpose of displaying an image or color, it "
"can also change how objects are affected by ambient and reflected light."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:68
msgid "There are many ways to set the background:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:70
msgid ""
"**Clear Color** uses the default clear color defined by the project. The "
"background will be a constant color."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:71
msgid "**Custom Color** is like Clear Color, but with a custom color value."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:72
msgid ""
"**Sky** lets you define a panorama sky (a 360 degree sphere texture) or a "
"procedural sky (a simple sky featuring a gradient and an optional sun). "
"Objects will reflect it and absorb ambient light from it."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73
msgid ""
"**Color+Sky** lets you define a sky (as above), but uses a constant color "
"value for drawing the background. The sky will only be used for reflection "
"and ambient light."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:76
msgid "Ambient Light"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:78
msgid ""
"Ambient (as defined here) is a type of light that affects every piece of "
"geometry with the same intensity. It is global and independent of lights "
"that might be added to the scene."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82
msgid ""
"There are two types of ambient light: the *Ambient Color* (which is a "
"constant color multiplied by the material albedo) and then one obtained from "
"the *Sky* (as described before, but a sky needs to be set as background for "
"this to be enabled)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:89
msgid ""
"When a *Sky* is set as background, it's possible to blend between ambient "
"color and sky using the **Sky Contribution** setting (this value is 1.0 by "
"default for convenience, so only the sky affects objects)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:93
msgid "Here is a comparison of how different ambient light affects a scene:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:97
msgid ""
"Finally, there is an **Energy** setting, which is a multiplier. It's useful "
"when working with HDR."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:100
msgid ""
"In general, ambient light should only be used for simple scenes, large "
"exteriors, or for performance reasons (ambient light is cheap), as it does "
"not provide the best lighting quality. It's better to generate ambient light "
"from ReflectionProbe or GIProbe, which will more faithfully simulate how "
"indirect light propagates. Below is a comparison, in terms of quality, "
"between using a flat ambient color and a GIProbe:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:109
msgid ""
"Using one of the methods described above, objects get constant ambient "
"lighting replaced by ambient light from the probes."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:84
msgid "Fog"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:115
msgid ""
"Fog, as in real life, makes distant objects fade away into an uniform color. "
"The physical effect is actually pretty complex, but Godot provides a good "
"approximation. There are two kinds of fog in Godot:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119
msgid ""
"**Depth Fog:** This one is applied based on the distance from the camera."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:120
msgid ""
"**Height Fog:** This one is applied to any objects below (or above) a "
"certain height, regardless of the distance from the camera."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124
msgid ""
"Both of these fog types can have their curve tweaked, making their "
"transition more or less sharp."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:126
msgid "Two properties can be tweaked to make the fog effect more interesting:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:128
msgid ""
"The first is **Sun Amount**, which makes use of the Sun Color property of "
"the fog. When looking towards a directional light (usually a sun), the color "
"of the fog will be changed, simulating the sunlight passing through the fog."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132
msgid ""
"The second is **Transmit Enabled** which simulates more realistic light "
"transmittance. In practice, it makes light stand out more across the fog."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:138
msgid "Tonemap"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:142
msgid ""
"Selects the tone-mapping curve that will be applied to the scene, from a "
"short list of standard curves used in the film and game industry. Tone "
"mapping can make light and dark areas more homogeneous, even though the "
"result is not that strong. Tone mapping options are:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:147
msgid ""
"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:148
msgid ""
"**Exposure:** Tone mapping exposure which simulates amount of light received "
"over time."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:149
msgid ""
"**White:** Tone mapping white, which simulates where in the scale white is "
"located (by default 1.0)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:152
msgid "Auto Exposure (HDR)"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:156
msgid ""
"Even though, in most cases, lighting and texturing are heavily artist "
"controlled, Godot supports a simple high dynamic range implementation with "
"the auto exposure mechanism. This is generally used for the sake of realism "
"when combining interior areas with low light and outdoors. Auto exposure "
"simulates the camera (or eye) in an effort to adapt between light and dark "
"locations and their different amounts of light."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:165
msgid ""
"The simplest way to use auto exposure is to make sure outdoor lights (or "
"other strong lights) have energy beyond 1.0. This is done by tweaking their "
"**Energy** multiplier (on the Light itself). To make it consistent, the "
"**Sky** usually needs to use the energy multiplier too, to match with the "
"directional light. Normally, values between 3.0 and 6.0 are enough to "
"simulate indoor-outdoor conditions."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:171
msgid ""
"By combining Auto Exposure with *Glow* post processing (more on that below), "
"pixels that go over the tonemap **White** will bleed to the glow buffer, "
"creating the typical bloom effect in photography."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:177
msgid ""
"The user-controllable values in the Auto Exposure section come with sensible "
"defaults, but you can still tweak them:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:182
msgid ""
"**Scale:** Value to scale the lighting. Brighter values produce brighter "
"images, smaller ones produce darker ones."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:183
msgid ""
"**Min Luma:** Minimum luminance that auto exposure will aim to adjust for. "
"Luminance is the average of the light in all the pixels of the screen."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:184
msgid ""
"**Max Luma:** Maximum luminance that auto exposure will aim to adjust for."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:185
msgid ""
"**Speed:** Speed at which luminance corrects itself. The higher the value, "
"the faster correction happens."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:188
msgid "Mid- and post-processing effects"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:190
msgid ""
"A large amount of widely-used mid- and post-processing effects are supported "
"in the Environment."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:194
msgid "Screen-Space Reflections (SSR)"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:198
msgid ""
"While Godot supports three sources of reflection data (Sky, ReflectionProbe, "
"and GIProbe), they may not provide enough detail for all situations. "
"Scenarios where Screen Space Reflections make the most sense are when "
"objects are in contact with each other (object over floor, over a table, "
"floating on water, etc)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:205
msgid ""
"The other advantage (even if only enabled to a minimum), is that it works in "
"real-time (while the other types of reflections are pre-computed). This can "
"be used to make characters, cars, etc. reflect on surrounding surfaces when "
"moving around."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209
msgid ""
"A few user-controlled parameters are available to better tweak the technique:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:211
msgid ""
"**Max Steps** determines the length of the reflection. The bigger this "
"number, the more costly it is to compute."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:212
msgid ""
"**Fade In** allows adjusting the fade-in curve, which is useful to make the "
"contact area softer."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:213
msgid ""
"**Fade Out** allows adjusting the fade-out curve, so the step limit fades "
"out softly."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:214
msgid ""
"**Depth Tolerance** can be used for screen-space-ray hit tolerance to gaps. "
"The bigger the value, the more gaps will be ignored."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:215
msgid ""
"**Roughness** will apply a screen-space blur to approximate roughness in "
"objects with this material characteristic."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:217
msgid ""
"Keep in mind that screen-space-reflections only work for reflecting opaque "
"geometry. Transparent objects can't be reflected."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220
msgid "Screen-Space Ambient Occlusion (SSAO)"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:224
msgid ""
"As mentioned in the **Ambient** section, areas where light from light nodes "
"does not reach (either because it's outside the radius or shadowed) are lit "
"with ambient light. Godot can simulate this using GIProbe, ReflectionProbe, "
"the Sky, or a constant ambient color. The problem, however, is that all the "
"methods proposed previously act more on a larger scale (large regions) than "
"at the smaller geometry level."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:231
msgid ""
"Constant ambient color and Sky are the same everywhere, while GI and "
"Reflection probes have more local detail, but not enough to simulate "
"situations where light is not able to fill inside hollow or concave features."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:235
msgid ""
"This can be simulated with Screen Space Ambient Occlusion. As you can see in "
"the image below, its purpose is to make sure concave areas are darker, "
"simulating a narrower path for the light to enter:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:241
msgid ""
"It is a common mistake to enable this effect, turn on a light, and not be "
"able to appreciate it. This is because SSAO only acts on *ambient* light, "
"not direct light."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:244
msgid ""
"This is why, in the image above, the effect is less noticeable under the "
"direct light (on the left). If you want to force SSAO to work with direct "
"light too, use the **Light Affect** parameter (even though this is not "
"correct, some artists like how it looks)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248
msgid ""
"SSAO looks best when combined with a real source of indirect light, like "
"GIProbe:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252
msgid "Tweaking SSAO is possible with several parameters:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:256
msgid ""
"**Radius/Intensity:** To control the radius or intensity of the occlusion, "
"these two parameters are available. Radius is in world (Metric) units."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257
msgid ""
"**Radius2/Intensity2:** A Secondary radius/intensity can be used. Combining "
"a large and a small radius AO generally works well."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:258
msgid ""
"**Bias:** This can be tweaked to solve self occlusion, though the default "
"generally works well enough."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:259
msgid ""
"**Light Affect:** SSAO only affects ambient light, but increasing this "
"slider can make it also affect direct light. Some artists prefer this effect."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:260
msgid ""
"**Ao Channel Affect:** If a value of zero is used, only the material's AO "
"texture will be used for ambient occlusion; SSAO will not be applied. Values "
"greater than 0 multiply the AO texture by the SSAO effect to varying "
"degrees. This does not affect materials without an AO texture."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:261
msgid ""
"**Quality:** Depending on quality, SSAO will take more samples over a sphere "
"for every pixel. High quality only works well on modern GPUs."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:262
msgid ""
"**Blur:** Type of blur kernel used. The 1x1 kernel is a simple blur that "
"preserves local detail better, but is not as efficient (generally works "
"better with the high quality setting above), while 3x3 will soften the image "
"better (with a bit of dithering-like effect), but does not preserve local "
"detail as well."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263
msgid ""
"**Edge Sharpness**: This can be used to preserve the sharpness of edges "
"(avoids areas without AO on creases)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:266
msgid "Depth of Field / Far Blur"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:270
msgid ""
"This effect simulates focal distance on high end cameras. It blurs objects "
"behind a given range. It has an initial **Distance** with a **Transition** "
"region (in world units):"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:290
msgid ""
"The **Amount** parameter controls the amount of blur. For larger blurs, "
"tweaking the **Quality** may be needed in order to avoid artifacts."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:280
msgid "Depth of Field / Near Blur"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:284
msgid ""
"This effect simulates focal distance on high end cameras. It blurs objects "
"close to the camera (acts in the opposite direction as far blur). It has an "
"initial **Distance** with a **Transition** region (in world units):"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:293
msgid ""
"It is common to use both blurs together to focus the viewer's attention on a "
"given object:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:299
msgid "Glow"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:303
msgid ""
"In photography and film, when light amount exceeds the maximum supported by "
"the media (be it analog or digital), it generally bleeds outwards to darker "
"regions of the image. This is simulated in Godot with the **Glow** effect."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:309
msgid ""
"By default, even if the effect is enabled, it will be weak or invisible. One "
"of two conditions need to happen for it to actually show:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:312
msgid ""
"The light in a pixel surpasses the **HDR Threshold** (where 0 is all light "
"surpasses it, and 1.0 is light over the tonemapper **White** value). "
"Normally, this value is expected to be at 1.0, but it can be lowered to "
"allow more light to bleed. There is also an extra parameter, **HDR Scale**, "
"that allows scaling (making brighter or darker) the light surpassing the "
"threshold."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:316
msgid ""
"The Bloom effect has a value set greater than 0. As it increases, it sends "
"the whole screen to the glow processor at higher amounts."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320
msgid "Both will cause the light to start bleeding out of the brighter areas."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:322
msgid "Once glow is visible, it can be controlled with a few extra parameters:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:324
msgid ""
"**Intensity** is an overall scale for the effect, it can be made stronger or "
"weaker (0.0 removes it)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:325
msgid ""
"**Strength** is how strong the gaussian filter kernel is processed. Greater "
"values make the filter saturate and expand outwards. In general, changing "
"this is not needed, as the size can be more efficiently adjusted with the "
"**Levels**."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:327
msgid "The **Blend Mode** of the effect can also be changed:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:329
msgid ""
"**Additive** is the strongest one, as it just adds the glow effect over the "
"image with no blending involved. In general, it's too strong to be used, but "
"can look good with low intensity Bloom (produces a dream-like effect)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:330
msgid ""
"**Screen** is the default one. It ensures glow never brights more than "
"itself and works great as an all around."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:331
msgid ""
"**Softlight** is the weakest one, producing only a subtle color disturbance "
"around the objects. This mode works best on dark scenes."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:332
msgid ""
"**Replace** can be used to blur the whole screen or debug the effect. It "
"just shows the glow effect without the image below."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:334
msgid ""
"To change the glow effect size and shape, Godot provides **Levels**. Smaller "
"levels are strong glows that appear around objects, while large levels are "
"hazy glows covering the whole screen:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:340
msgid ""
"The real strength of this system, though, is to combine levels to create "
"more interesting glow patterns:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345
msgid ""
"Finally, as the highest layers are created by stretching small blurred "
"images, it is possible that some blockiness may be visible. Enabling "
"**Bicubic Upscaling** gets rids of it, at a minimal performance cost."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:352
msgid "Adjustments"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:356
msgid ""
"At the end of processing, Godot offers the possibility to do some standard "
"image adjustments."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:361
msgid ""
"The first one is being able to change the typical Brightness, Contrast, and "
"Saturation:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:366
msgid ""
"The second is by supplying a color correction gradient. A regular black to "
"white gradient like the following one will produce no effect:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:371
msgid ""
"But creating custom ones will allow to map each channel to a different color:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:4
msgid "Light transport in game engines"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:9
msgid ""
"Normally, an artist does all the 3D modelling, then all the texturing, looks "
"at their awesome looking model in the 3D DCC and says \"looks fantastic, "
"ready for integration!\" then goes into the game, lighting is setup and the "
"game runs."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:14
msgid ""
"So at what point does all this \"HDR\" business come into play? To "
"understand the answer, we need to look at how displays behave."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:17
msgid ""
"Your display outputs linear light ratios from some maximum to some minimum "
"intensity. Modern game engines perform complex math on linear light values "
"in their respective scenes. So what's the problem?"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:21
msgid ""
"The display has a limited range of intensity, depending on the display type. "
"The game engine renders to an unlimited range of intensity values, however. "
"While \"maximum intensity\" means something to an sRGB display, it has no "
"bearing in the game engine; there is only a potentially infinitely wide "
"range of intensity values generated per frame of rendering."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:27
msgid ""
"This means that some transformation of the scene light intensity, also known "
"as *scene-referred* light ratios, need to be transformed and mapped to fit "
"within the particular output range of the chosen display. This can be most "
"easily understood if we consider virtually photographing our game engine "
"scene through a virtual camera. Here, our virtual camera would apply a "
"particular camera rendering transform to the scene data, and the output "
"would be ready for display on a particular display type."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:36
msgid "Computer displays"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:38
msgid ""
"Almost all displays require a nonlinear encoding for the code values sent to "
"them. The display in turn, using its unique transfer characteristic, "
"\"decodes\" the code value into linear light ratios of output, and projects "
"the ratios out of the uniquely colored lights at each reddish, greenish, and "
"blueish emission site."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:44
msgid ""
"For a majority of computer displays, the specifications of the display are "
"outlined in accordance with IEC 61966-2-1, also known as the 1996 sRGB "
"specification. This specification outlines how an sRGB display is to behave, "
"including the color of the lights in the LED pixels as well as the transfer "
"characteristics of the input (OETF) and output (EOTF)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:50
msgid ""
"Not all displays use the same OETF and EOTF as a computer display. For "
"example, television broadcast displays use the BT.1886 EOTF. However, Godot "
"currently only supports sRGB displays."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:54
msgid ""
"The sRGB standard is based around the nonlinear relationship between the "
"current to light output of common desktop computing CRT displays."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:59
msgid ""
"The mathematics of a scene-referred model require that we multiply the scene "
"by different values to adjust the intensities and exposure to different "
"light ranges. The transfer function of the display can't appropriately "
"render the wider dynamic range of the game engine's scene output using the "
"simple transfer function of the display. A more complex approach to encoding "
"is required."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:67
msgid "Scene linear & asset pipelines"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:69
msgid ""
"Working in scene-linear sRGB is not as simple as just pressing a switch. "
"First, imported image assets must be converted to linear light ratios on "
"import. Even when linearized, those assets may not be perfectly well-suited "
"for use as textures, depending on how they were generated."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:74
#, fuzzy
msgid "There are two ways to do this:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/tutorials/3d/high_dynamic_range.rst:77
msgid "sRGB transfer function to display linear ratios on image import"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:79
msgid ""
"This is the easiest method of using sRGB assets, but it's not the most "
"ideal. One issue with this is loss of quality. Using 8 bits per channel to "
"represent linear light ratios is not sufficient to quantize the values "
"correctly. These textures may also be compressed later, which can exacerbate "
"the problem."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:85
msgid "Hardware sRGB transfer function to display linear conversion"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:87
msgid ""
"The GPU will do the conversion after reading the texel using floating-point. "
"This works fine on PC and consoles, but most mobile devices don't support "
"it, or they don't support it on compressed texture formats (iOS for example)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:92
msgid "Scene linear to display referred nonlinear"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:94
msgid ""
"After all the rendering is done, the scene linear render requires "
"transforming to a suitable output such as an sRGB display. To do this, "
"enable sRGB conversion in the current :ref:`Environment <class_Environment>` "
"(more on that below)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:98
msgid ""
"Keep in mind that the **sRGB -> Display Linear** and **Display Linear -> "
"sRGB** conversions must always be **both** enabled. Failing to enable one of "
"them will result in horrible visuals suitable only for avant-garde "
"experimental indie games."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:104
msgid "Parameters of HDR"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:106
msgid ""
"HDR settings can be found in the :ref:`Environment <class_Environment>` "
"resource. Most of the time, these are found inside a :ref:`WorldEnvironment "
"<class_WorldEnvironment>` node or set in a Camera node. For more "
"information, see :ref:`doc_environment_and_post_processing`."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:4
msgid "Using gridmaps"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:9
msgid ""
":ref:`Gridmaps <class_GridMap>` are a tool for creating 3D game levels, "
"similar to the way :ref:`TileMap <doc_using_tilemaps>` works in 2D. You "
"start with a predefined collection of 3D meshes (a :ref:`class_MeshLibrary`) "
"that can be placed on a grid, as if you were building a level with an "
"unlimited amount of Lego blocks."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:15
msgid ""
"Collisions and navigation can also be added to the meshes, just like you "
"would do with the tiles of a tilemap."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:19
msgid "Example project"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:21
msgid ""
"To learn how GridMaps work, start by downloading the sample project: :"
"download:`gridmap_demo.zip <files/gridmap_demo.zip>`."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:24
msgid ""
"Unzip this project and add it to the Project Manager using the \"Import\" "
"button."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:28
msgid "Creating a MeshLibrary"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:30
msgid ""
"To begin, you need a :ref:`class_MeshLibrary`, which is a collection of "
"individual meshes that can be used in the gridmap. Open the "
"\"MeshLibrary_Source.tscn\" scene to see an example of how to set up the "
"mesh library."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:36
msgid ""
"As you can see, this scene has a :ref:`class_Spatial` node as its root, and "
"a number of :ref:`class_MeshInstance` node children."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:39
msgid ""
"If you don't need any physics in your scene, then you're done. However, in "
"most cases you'll want to assign collision bodies to the meshes."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:43
msgid "Collisions"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:45
msgid ""
"You can manually assign a :ref:`class_StaticBody` and :ref:"
"`class_CollisionShape` to each mesh. Alternatively, you can use the \"Mesh\" "
"menu to automatically create the collision body based on the mesh data."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:51
msgid ""
"Note that a \"Convex\" collision body will work better for simple meshes. "
"For more complex shapes, select \"Create Trimesh Static Body\". Once each "
"mesh has a physics body and collision shape assigned, your mesh library is "
"ready to be used."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:62
msgid ""
"Only the materials from within the meshes are used when generating the mesh "
"library. Materials set on the node will be ignored."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:66
msgid "Exporting the MeshLibrary"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:68
msgid ""
"To export the library, click on Scene -> Convert To.. -> MeshLibrary.., and "
"save it as a resource."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:73
msgid ""
"You can find an already exported MeshLibrary in the project named "
"\"MeshLibrary.tres\"."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:76
msgid "Using GridMap"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:78
msgid ""
"Create a new scene and add a GridMap node. Add the mesh library by dragging "
"the resource file from the FileSystem dock and dropping it in the \"Theme\" "
"property in the Inspector."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:84
msgid ""
"The \"Cell/Size\" property should be set to the size of your meshes. You can "
"leave it at the default value for the demo. Set the \"Center Y\" property to "
"\"Off\"."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:87
msgid ""
"Now you can start designing the level by choosing a tile from the palette "
"and placing it with Left-Click in the editor window. To remove a tile, hold :"
"kbd:`Shift` and use Right-click."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:91
msgid ""
"Click on the \"GridMap\" menu to see options and shortcuts. For example, "
"pressing :kbd:`S` rotates a tile around the y-axis."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:96
msgid ""
"Holding :kbd:`Shift` and dragging with the left mouse button will draw a "
"selection box. You can duplicate or clear the selected area using the "
"respective menu options."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:102
msgid ""
"In the menu, you can also change the axis you're drawing on, as well as "
"shift the drawing plane higher or lower on its axis."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:108
msgid "Using GridMap in code"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:110
msgid ""
"See :ref:`class_GridMap` for details on the node's methods and member "
"variables."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:4
msgid "Using MultiMeshInstance"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:9
msgid ""
"In a normal scenario, you would use a :ref:`MeshInstance "
"<class_MeshInstance>` node to display a 3D mesh like a human model for the "
"main character, but in some cases, you would like to create multiple "
"instances of the same mesh in a scene. You *could* duplicate the same node "
"multiple times and adjust the transforms manually. This may be a tedious "
"process and the result may look mechanical. Also, this method is not "
"conducive to rapid iterations. :ref:`MultiMeshInstance "
"<class_MultiMeshInstance>` is one of the possible solutions to this problem."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:18
msgid ""
"MultiMeshInstance, as the name suggests, creates multiple copies of a "
"MeshInstance over a surface of a specific mesh. An example would be having a "
"tree mesh populate a landscape mesh with trees of random scales and "
"orientations."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:23
msgid "Setting up the nodes"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:25
msgid ""
"The basic setup requires three nodes: the MultiMeshInstance node and two "
"MeshInstance nodes."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:28
msgid ""
"One node is used as the target, the mesh that you want to place multiple "
"meshes on. In the tree example, this would be the landscape."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:31
msgid ""
"The other node is used as the source, the mesh that you want to have "
"duplicated. In the tree case, this would be the tree itself."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34
msgid ""
"In our example, we would use a :ref:`Spatial <class_Spatial>` node as the "
"root node of the scene. Your scene tree would look like this:"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:39
msgid "For simplicity's sake, this tutorial uses built-in primitives."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:41
msgid ""
"Now you have everything ready. Select the MultiMeshInstance node and look at "
"the toolbar, you should see an extra button called ``MultiMesh`` next to "
"``View``. Click it and select *Populate surface* in the dropdown menu. A new "
"window titled *Populate MultiMesh* will pop up."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:51
msgid "MultiMesh settings"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:53
msgid "Below are descriptions of the options."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:56
msgid "Target Surface"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:58
msgid ""
"The mesh used as the target surface on which to place copies of your source "
"mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62
msgid "Source Mesh"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:64
msgid "The mesh you want duplicated on the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:67
msgid "Mesh Up Axis"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69
msgid "The axis used as the up axis of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:72
msgid "Random Rotation"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74
msgid "Randomizing the rotation around the up axis of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77
msgid "Random Tilt"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:79
msgid "Randomizing the overall rotation of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82
msgid "Random Scale"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:84
msgid "Randomizing the scale of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:89
msgid ""
"The scale of the source mesh that will be placed over the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:92
msgid "Amount"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:94
msgid "The amount of mesh instances placed over the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:96
msgid ""
"Select the target surface. In the tree case, this should be the landscape "
"node. The source mesh should be the tree node. Adjust the other parameters "
"according to your preference. Press ``Populate`` and multiple copies of the "
"source mesh will be placed over the target mesh. If you are satisfied with "
"the result, you can delete the mesh instance used as the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:102
msgid "The end result should look like this:"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:106
msgid ""
"To change the result, repeat the previous steps with different parameters."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:4
msgid "CSG"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:6
msgid ""
"CSG stands for **Constructive Solid Geometry**, and is a tool to combine "
"basic shapes or custom meshes to create more complex shapes. In 3D modelling "
"software, CSG is mostly known as \"Boolean Operators\"."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:10
msgid ""
"Level prototyping is one of the main uses of CSG in Godot. This technique "
"allows users to create simple versions of most common shapes by combining "
"primitives. Interior environments can be created by using inverted "
"primitives."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:14
msgid ""
"The CSG nodes in Godot are mainly intended for prototyping. There is no "
"built-in support for UV mapping or editing 3D polygons (though extruded 2D "
"polygons can be used with the CSGPolygon node)."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:18
msgid ""
"If you're looking for an easy to use level design tool for a project, you "
"may want to use `Qodot <https://github.com/Shfty/qodot-plugin>`__ instead. "
"It lets you design levels using `TrenchBroom <https://kristianduske.com/"
"trenchbroom/>`__ and import them in Godot."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:27
#, fuzzy
msgid "Introduction to CSG nodes"
msgstr "מבוא"

#: ../../docs/tutorials/3d/csg_tools.rst:29
msgid ""
"Like other features of Godot, CSG is supported in the form of nodes. These "
"are the CSG nodes:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:32
msgid ":ref:`CSGBox <class_CSGBox>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:33
msgid ":ref:`CSGCylinder <class_CSGCylinder>` (also supports cone)"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:34
msgid ":ref:`CSGSphere <class_CSGSphere>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:35
msgid ":ref:`CSGTorus <class_CSGTorus>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:36
msgid ":ref:`CSGPolygon <class_CSGPolygon>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:37
msgid ":ref:`CSGMesh <class_CSGMesh>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:38
msgid ":ref:`CSGCombiner <class_CSGcombiner>`"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:45
msgid "CSG tools features"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:47
msgid "Every CSG node supports 3 kinds of boolean operations:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:49
msgid ""
"**Union:** Geometry of both primitives is merged, intersecting geometry is "
"removed."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:51
msgid ""
"**Intersection:** Only intersecting geometry remains, the rest is removed."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:52
msgid ""
"**Subtraction:** The second shape is subtracted from the first, leaving a "
"dent with its shape."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:60
msgid "CSGPolygon"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:62
msgid ""
"The :ref:`CSGPolygon <class_CSGPolygon>` node extrude along a Polygon drawn "
"in 2D (in X, Y coordinates) in the following ways:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:65
msgid "**Depth:** Extruded back a given amount."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:66
msgid "**Spin:** Extruded while spinning around its origin."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:67
msgid ""
"**Path:** Extruded along a Path node. This operation is commonly called "
"lofting."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:74
msgid ""
"The **Path** mode must be provided with a :ref:`Path <class_Path>` node to "
"work. In the Path node, draw the path and the polygon in CSGPolygon will "
"extrude along the given path."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:80
#, fuzzy
msgid "Custom meshes"
msgstr "אותות"

#: ../../docs/tutorials/3d/csg_tools.rst:82
msgid ""
"Any mesh can be used for :ref:`CSGMesh <class_CSGMesh>`; the mesh can be "
"modelled in other software and imported into Godot. Multiple materials are "
"supported. There are some restrictions for geometry:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:86
msgid "it must be closed,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:87
msgid "it must not self-intersect,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:88
msgid "it must not contain internal faces,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:89
msgid "every edge must connect to only two other faces."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:94
msgid "CSGCombiner"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:96
msgid ""
"The :ref:`CSGCombiner <class_CSGCombiner>` node is an empty shape used for "
"organization. It will only combine children nodes."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:100
msgid "Processing order"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:102
msgid ""
"Every CSG node will first process its children nodes and their operations: "
"union, intersection or subtraction, in tree order, and apply them to itself "
"one after the other."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:106
msgid ""
"In the interest of performance, make sure CSG geometry remains relatively "
"simple, as complex meshes can take a while to process. If adding objects "
"together (such as table and room objects), create them as separate CSG "
"trees. Forcing too many objects in a single tree will eventually start "
"affecting performance. Only use binary operations where you actually need "
"them."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:114
msgid "Prototyping a level"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:116
msgid "We will prototype a room to practice the use of CSG tools."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:118
msgid ""
"Working in **Orthogonal** projection gives a better view when combining the "
"CSG shapes."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:121
msgid "Our level will contain these objects:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:123
msgid "a room,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:124
msgid "a bed,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:125
msgid "a lamp,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:126
msgid "a desk,"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:127
msgid "a bookshelf."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:129
msgid "Create a scene with a Spatial node as root node."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:131
msgid ""
"The default lighting of the environment doesn't provide clear shading at "
"some angles. Change the display mode using **Display Overdraw** in the 3D "
"viewport menu, or add a DirectionalLight node to help you see clearly."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:138
msgid ""
"Create a CSGBox and name it ``room``, enable **Invert Faces** and change the "
"dimensions of your room."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:145
msgid "Next, create a CSGCombiner and name it ``desk``."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:147
msgid "A desk has one surface and 4 legs:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:149
msgid ""
"Create 1 CSGBox children node in **Union** mode for the surface and adjust "
"the dimensions."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:151
msgid ""
"Create 4 CSGBox children nodes in **Union** mode for the legs and adjust the "
"dimensions."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:154
msgid "Adjust their placement to resemble a desk."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:158
msgid ""
"CSG nodes inside a CSGCombiner will only process their operation within the "
"combiner. Therefore, CSGCombiners are used to organize CSG nodes."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:162
msgid "Create a CSGCombiner and name it ``bed``."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:164
msgid ""
"Our bed consists of 3 parts: the bed, the mattress and a pillow. Create a "
"CSGBox and adjust its dimension for the bed. Create another CSGBox and "
"adjust its dimension for the mattress."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:170
msgid ""
"We will create another CSGCombiner named ``pillow`` as the child of  "
"``bed``. The scene tree should look like this:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:175
msgid ""
"We will combine 3 CSGSphere nodes in **Union** mode to form a pillow. Scale "
"the Y axis of the spheres and enable **Smooth Faces**."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:180
msgid ""
"Select the ``pillow`` node and switch the mode to **Subtraction**; the "
"combined spheres will cut a hole into the mattress."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:185
msgid ""
"Try to re-parent the ``pillow`` node to the root ``Spatial`` node; the hole "
"will disappear."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:188
msgid ""
"This is to illustrate the effect of CSG processing order. Since the root "
"node is not a CSG node, the CSGCombiner nodes are the end of the operations; "
"this shows the use of CSGCombiner to organize the CSG scene."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:193
msgid ""
"Undo the re-parent after observing the effect. The bed you've built should "
"look like this:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:198
msgid "Create a CSGCombiner and name it ``lamp``."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:200
msgid ""
"A lamp consists of 3 parts: the stand, the pole and the lampshade. Create a "
"CSGCylinder, enable the **Cone** option and make it the stand. Create "
"another CSGCylinder and adjust the dimensions to use it as a pole."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:206
msgid ""
"We will use a CSGPolygon for the lampshade. Use the **Spin** mode for the "
"CSGPolygon and draw a `trapezoid <https://en.wikipedia.org/wiki/Trapezoid>`_ "
"while in **Front View** (numeric keypad 1); this shape will extrude around "
"the origin and form the lampshade."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:217
msgid "Adjust the placement of the 3 parts to make it look like a lamp."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:221
msgid "Create a CSGCombiner and name it ``bookshelf``."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:223
msgid ""
"We will use 3 CSGBox nodes for the bookshelf. Create a CSGBox and adjust its "
"dimensions; this will be the size of the bookshelf."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:228
msgid ""
"Duplicate the CSGBox and shorten the dimensions of each axis and change the "
"mode to **Subtraction**."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:235
msgid ""
"You've almost built a shelf. Create one more CSGBox for dividing the shelf "
"into two levels."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:240
msgid ""
"Position your furniture in your room as you like and your scene should look "
"this:"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:245
msgid ""
"You've successfully prototyped a room level with the CSG tools in Godot. CSG "
"tools can be used for designing all kinds of levels, such as a maze or a "
"city; explore its limitations when designing your game."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:250
msgid "Using prototype textures"
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:252
msgid ""
"Godot's :ref:`doc_spatial_material` supports *triplanar mapping*, which can "
"be used to automatically apply a texture to arbitrary objects without "
"distortion. This is handy when using CSG as Godot doesn't support editing UV "
"maps on CSG nodes yet. Triplanar mapping is relatively slow, which usually "
"restricts its usage to organic surfaces like terrain. Still, when "
"prototyping, it can be used to quickly apply textures to CSG-based levels."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:259
msgid ""
"If you need some textures for prototyping, Kenney made a `set of CC0-"
"licensed prototype textures <https://kenney.nl/assets/prototype-textures>`__."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:262
#, fuzzy
msgid "There are two ways to apply a material to a CSG node:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/tutorials/3d/csg_tools.rst:264
msgid ""
"Applying it to a CSGCombiner node as a material override (**Geometry > "
"Material Override** in the Inspector). This will affect its children "
"automatically, but will make it impossible to change the material in "
"individual children."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:268
msgid ""
"Applying a material to individual nodes (**Material** in the Inspector). "
"This way, each CSG node can have its own appearance. Subtractive CSG nodes "
"will apply their material to the nodes they're \"digging\" into."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:272
msgid ""
"To apply triplanar mapping to a CSG node, select it, go to the Inspector, "
"click the **[empty]** text next to **Material Override** (or **Material** "
"for individual CSG nodes). Choose **New SpatialMaterial**. Click the newly "
"created material's icon to edit it. Unfold the **Albedo** section and load a "
"texture into the **Texture** property. Now, unfold the **Uv1** section and "
"check **Triplanar**. You can change the texture offset and scale on each "
"axis by playing with the **Scale** and **Offset** properties just above. "
"Higher values in the **Scale** property will cause the texture to repeat "
"more often."
msgstr ""

#: ../../docs/tutorials/3d/csg_tools.rst:281
msgid ""
"You can copy a SpatialMaterial to reuse it across CSG nodes. To do so, click "
"the dropdown arrow next to a material property in the Inspector and choose "
"**Copy**. To paste it, select the node you'd like to apply the material "
"onto, click the dropdown arrow next to its material property then choose "
"**Paste**."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/index.rst:2
msgid "FPS tutorial"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:4
msgid "Part 1"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:7
msgid "Tutorial introduction"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:11
msgid ""
"This tutorial series will show you how to make a single player FPS game."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:13
msgid "Throughout the course of this tutorial series, we will cover how:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:15
msgid "To make a first person character that can move, sprint, and jump."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:16
msgid ""
"To make a simple animation state machine for handling animation transitions."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:17
msgid ""
"To add three weapons to the first person character, each using a different "
"way to handle bullet collisions:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:18
msgid "A knife (using an :ref:`Area <class_Area>`)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:19
msgid "A pistol (Bullet scenes)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:20
msgid "A rifle (using a :ref:`Raycast <class_Raycast>`)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:21
msgid "To add two different types of grenades to the first person character:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:22
msgid "A normal grenade"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:23
msgid "A sticky grenade"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:24
msgid ""
"To add the ability to grab and throw :ref:`RigidBody <class_RigidBody>` nodes"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:25
msgid "To add joypad input for the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:26
msgid "To add ammo and reloading for all weapons that consume ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:27
msgid "To add ammo and health pick ups"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:28
msgid "In two sizes: big and small"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:29
msgid "To add an automatic turret"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:30
msgid "That can fire using bullet objects or a :ref:`Raycast <class_Raycast>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:31
msgid "To add targets that break when they've taken enough damage"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:32
msgid "To add sounds that play when the guns fire."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:33
msgid "To add a simple main menu:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:34
msgid "With an options menu for changing how the game runs"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:35
msgid "With a level select screen"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:36
msgid "To add a universal pause menu we can access anywhere"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:38
msgid ""
"While this tutorial can be completed by beginners, it is highly advised to "
"complete :ref:`doc_your_first_game`, if you are new to Godot and/or game "
"development **before** going through this tutorial series."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:43
msgid ""
"Remember: Making 3D games is much harder than making 2D games. If you do not "
"know how to make 2D games, you will likely struggle making 3D games."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:46
msgid ""
"This tutorial assumes you have experience working with the Godot editor, "
"basic programming experience in GDScript, and basic experience in game "
"development."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:49
msgid ""
"You can find the start assets for this tutorial here: :download:"
"`Godot_FPS_Starter.zip <files/Godot_FPS_Starter.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:51
msgid ""
"The provided starter assets contain an animated 3D model, a bunch of 3D "
"models for making levels, and a few scenes already configured for this "
"tutorial."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:54
msgid ""
"All assets provided (unless otherwise noted) were originally created by "
"TwistedTwigleg, with changes/additions by the Godot community. All original "
"assets provided for this tutorial are released under the ``MIT`` license."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:57
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1029
msgid ""
"Feel free to use these assets however you want! All original assets belong "
"to the Godot community, with the other assets belonging to those listed "
"below:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:59
msgid ""
"The skybox is created by **StumpyStrust** on OpenGameArt. The skybox used is "
"licensed under ``CC0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:62
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1034
msgid ""
"The font used is **Titillium-Regular**, and is licensed under the ``SIL Open "
"Font License, Version 1.1``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:64
msgid ""
"You can find the finished project for each part at the bottom of each part's "
"page"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:67
#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:7
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:7
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:7
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:7
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:7
msgid "Part overview"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:69
msgid ""
"In this part we will be making a first person player that can move around "
"the environment."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:74
msgid ""
"By the end of this part, you will have a working first-person character who "
"can move around the game environment, sprint, look around with a mouse based "
"first person camera, jump into the air, and turn a flash light on and off."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:78
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:62
msgid "Getting everything ready"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:80
msgid "Launch Godot and open up the project included in the starter assets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:82
msgid ""
"While these assets are not necessarily required to use the scripts provided "
"in this tutorial, they will make the tutorial much easier to follow, as "
"there are several pre-setup scenes we will be using throughout the tutorial "
"series."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:86
msgid ""
"First, open the project settings and go to the \"Input Map\" tab. You'll "
"find several actions have already been defined. We will be using these "
"actions for our player. Feel free to change the keys bound to these actions "
"if you want."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:92
msgid "Let's take a second to see what we have in the starter assets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:94
msgid ""
"Included in the starter assets are several scenes. For example, in ``res://"
"`` we have 14 scenes, most of which we will be visiting as we go through "
"this tutorial series."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:97
msgid "For now let's open up ``Player.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:99
msgid ""
"There are a bunch of scenes and a few textures in the ``Assets`` folder. You "
"can look at these if you want, but we will not be exploring through "
"``Assets`` in this tutorial series. ``Assets`` contains all the models used "
"for each of the levels, as well as some textures and materials."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:104
msgid "Making the FPS movement logic"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:106
msgid ""
"Once you have ``Player.tscn`` open, let's take a quick look at how it is set "
"up"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:110
msgid ""
"First, notice how the player's collision shapes are set up. Using a vertical "
"pointing capsule as the collision shape for the player is fairly common in "
"most first person games."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:113
msgid ""
"We are adding a small square to the 'feet' of the player so the player does "
"not feel like they are balancing on a single point."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:116
msgid ""
"We do want the 'feet' slightly higher than the bottom of the capsule so we "
"can roll over slight edges. Where to place the 'feet' is dependent on your "
"levels and how you want your player to feel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:119
msgid ""
"Many times the player will notice the collision shape being circular when "
"they walk to an edge and slide off. We are adding the small square at the "
"bottom of the capsule to reduce sliding on, and around, edges."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:123
msgid ""
"Another thing to notice is how many nodes are children of "
"``Rotation_Helper``. This is because ``Rotation_Helper`` contains all the "
"nodes we want to rotate on the ``X`` axis (up and down). The reason behind "
"this is so we can rotate ``Player`` on the ``Y`` axis, and "
"``Rotation_helper`` on the ``X`` axis."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:128
msgid ""
"Had we not used ``Rotation_helper``, we would've likely had cases of "
"rotating on both the ``X`` and ``Y`` axes simultaneously, potentially "
"further degenerating into a state of rotation on all three axes in some "
"cases."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:132
msgid "See :ref:`using transforms <doc_using_transforms>` for more information"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:136
msgid "Attach a new script to the ``Player`` node and call it ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:138
msgid ""
"Let's program our player by adding the ability to move around, look around "
"with the mouse, and jump. Add the following code to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:375
msgid "This is a lot of code, so let's break it down function by function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:377
msgid ""
"While copy and pasting code is ill advised, as you can learn a lot from "
"manually typing the code in, you can copy and paste the code from this page "
"directly into the script editor."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:380
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:242
msgid ""
"If you do this, all the code copied will be using spaces instead of tabs."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:382
msgid ""
"To convert the spaces to tabs in the script editor, click the \"edit\" menu "
"and select \"Convert Indent To Tabs\". This will convert all the spaces into "
"tabs. You can select \"Convert Indent To Spaces\" to convert tabs back into "
"spaces."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:387
msgid ""
"First, we define some class variables to dictate how our player will move "
"about the world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:389
msgid ""
"Throughout this tutorial, **variables defined outside functions will be "
"referred to as \"class variables\"**. This is because we can access any of "
"these variables from any place in the script."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:393
msgid "Let's go through each of the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:395
msgid "``GRAVITY``: How strong gravity pulls us down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:396
msgid "``vel``: Our :ref:`KinematicBody <class_KinematicBody>`'s velocity."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:397
msgid ""
"``MAX_SPEED``: The fastest speed we can reach. Once we hit this speed, we "
"will not go any faster."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:398
msgid "``JUMP_SPEED``: How high we can jump."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:399
msgid ""
"``ACCEL``: How quickly we accelerate. The higher the value, the sooner we "
"get to max speed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:400
msgid ""
"``DEACCEL``: How quickly we are going to decelerate. The higher the value, "
"the sooner we will come to a complete stop."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:401
msgid ""
"``MAX_SLOPE_ANGLE``: The steepest angle our :ref:`KinematicBody "
"<class_KinematicBody>` will consider as a 'floor'."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:402
msgid "``camera``: The :ref:`Camera <class_Camera>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:403
msgid ""
"``rotation_helper``: A :ref:`Spatial <class_Spatial>` node holding "
"everything we want to rotate on the X axis (up and down)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:404
msgid ""
"``MOUSE_SENSITIVITY``: How sensitive the mouse is. I find a value of "
"``0.05`` works well for my mouse, but you may need to change it based on how "
"sensitive your mouse is."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:406
msgid ""
"You can tweak many of these variables to get different results. For example, "
"by lowering ``GRAVITY`` and/or increasing ``JUMP_SPEED`` you can get a more "
"'floaty' feeling character. Feel free to experiment!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:410
msgid ""
"You may have noticed that ``MOUSE_SENSITIVITY`` is written in all caps like "
"the other constants, but ``MOUSE_SENSITIVITY`` is not a constant."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:412
msgid ""
"The reason behind this is we want to treat it like a constant variable (a "
"variable that cannot change) throughout our script, but we want to be able "
"to change the value later when we add customizable settings. So, in an "
"effort to remind ourselves to treat it like a constant, it's named in all "
"caps."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:417
msgid "Now let's look at the ``_ready`` function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:419
msgid ""
"First we get the ``camera`` and ``rotation_helper`` nodes and store them "
"into their variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:421
msgid ""
"Then we need to set the mouse mode to captured, so the mouse cannot leave "
"the game window."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:423
msgid ""
"This will hide the mouse and keep it at the center of the screen. We do this "
"for two reasons: The first reason being we do not want the player to see "
"their mouse cursor as they play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:426
msgid ""
"The second reason is because we do not want the cursor to leave the game "
"window. If the cursor leaves the game window there could be instances where "
"the player clicks outside the window, and then the game would lose focus. To "
"assure neither of these issues happens, we capture the mouse cursor."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:430
msgid ""
"See :ref:`Input documentation <class_Input>` for the various mouse modes. We "
"will only be using ``MOUSE_MODE_CAPTURED`` and ``MOUSE_MODE_VISIBLE`` in "
"this tutorial series."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:435
msgid "Next let's take a look at ``_physics_process``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:437
msgid ""
"All we're doing in ``_physics_process`` is calling two functions: "
"``process_input`` and ``process_movement``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:439
msgid ""
"``process_input`` will be where we store all the code relating to player "
"input. We want to call it first, before anything else, so we have fresh "
"player input to work with."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:442
msgid ""
"``process_movement`` is where we'll send all the data necessary to the :ref:"
"`KinematicBody <class_KinematicBody>` so it can move through the game world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:447
msgid "Let's look at ``process_input`` next:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:449
msgid "First we set ``dir`` to an empty :ref:`Vector3 <class_Vector3>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:451
msgid ""
"``dir`` will be used for storing the direction the player intends to move "
"towards. Because we do not want the player's previous input to effect the "
"player beyond a single ``process_movement`` call, we reset ``dir``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:454
msgid ""
"Next we get the camera's global transform and store it as well, into the "
"``cam_xform`` variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:456
msgid ""
"The reason we need the camera's global transform is so we can use its "
"directional vectors. Many have found directional vectors confusing, so let's "
"take a second to explain how they work:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:461
msgid ""
"World space can be defined as: The space in which all objects are placed in, "
"relative to a constant origin point. Every object, no matter if it is 2D or "
"3D, has a position in world space."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:464
msgid ""
"To put it another way: world space is the space in a universe where every "
"object's position, rotation, and scale can be measured by a single, known, "
"fixed point called the origin."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:467
msgid ""
"In Godot, the origin is at position ``(0, 0, 0)`` with a rotation of ``(0, "
"0, 0)`` and a scale of ``(1, 1, 1)``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:469
msgid ""
"When you open up the Godot editor and select a :ref:`Spatial "
"<class_Spatial>` based node, a gizmo pops up. Each of the arrows points "
"using world space directions by default."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:472
msgid ""
"If you want to move using the world space directional vectors, you'd do "
"something like this:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:497
msgid ""
"Notice how we do not need to do any calculations to get world space "
"directional vectors. We can define a few :ref:`Vector3 <class_Vector3>` "
"variables and input the values pointing in each direction."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:500
msgid "Here is what world space looks like in 2D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:502
msgid ""
"The following images are just examples. Each arrow/rectangle represents a "
"directional vector"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:506
#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:561
msgid "And here is what it looks like for 3D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:510
msgid ""
"Notice how in both examples, the rotation of the node does not change the "
"directional arrows. This is because world space is a constant. No matter how "
"you translate, rotate, or scale an object, world space will *always point in "
"the same direction*."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:514
msgid ""
"Local space is different, because it takes the rotation of the object into "
"account."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:516
msgid ""
"Local space can be defined as follows: The space in which an object's "
"position is the origin of the universe. Because the position of the origin "
"can be at ``N`` many locations, the values derived from local space change "
"with the position of the origin."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:521
msgid ""
"This question from Game Development Stack Exchange has a much better "
"explanation of world space and local space."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:523
msgid ""
"https://gamedev.stackexchange.com/questions/65783/what-are-world-space-and-"
"eye-space-in-game-development (Local space and eye space are essentially the "
"same thing in this context)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:526
msgid ""
"To get a :ref:`Spatial <class_Spatial>` node's local space, we need to get "
"its :ref:`Transform <class_Transform>`, so then we can get the :ref:`Basis "
"<class_Basis>` from the :ref:`Transform <class_Transform>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:529
msgid ""
"Each :ref:`Basis <class_Basis>` has three vectors: ``X``, ``Y``, and ``Z``. "
"Each of those vectors point towards each of the local space vectors coming "
"from that object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:532
msgid ""
"To use the :ref:`Spatial <class_Spatial>` node's local directional vectors, "
"we use this code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:557
msgid "Here is what local space looks like in 2D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:565
msgid ""
"Here is what the :ref:`Spatial <class_Spatial>` gizmo shows when you are "
"using local space mode. Notice how the arrows follow the rotation of the "
"object on the left, which looks exactly the same as the 3D example for local "
"space."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:569
msgid ""
"You can change between local and world space modes by pressing :kbd:`T` or "
"the little cube button when you have a :ref:`Spatial <class_Spatial>` based "
"node selected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:574
msgid ""
"Local vectors are confusing even for more experienced game developers, so do "
"not worry if this all doesn't make a lot of sense. The key thing to remember "
"about local vectors is that we are using local coordinates to get direction "
"from the object's point of view, as opposed to using world vectors, which "
"give direction from the world's point of view."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:580
msgid "Okay, back to ``process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:582
msgid ""
"Next we make a new variable called ``input_movement_vector`` and assign it "
"to an empty :ref:`Vector2 <class_Vector2>`. We will use this to make a "
"virtual axis of sorts, to map the player's input to movement."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:585
msgid ""
"This may seem overkill for just the keyboard, but this will make sense later "
"when we add joypad input."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:587
msgid ""
"Based on which directional movement action is pressed, we add to or subtract "
"from ``input_movement_vector``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:589
msgid ""
"After we've checked each of the directional movement actions, we normalize "
"``input_movement_vector``. This makes it where ``input_movement_vector``'s "
"values are within a ``1`` radius unit circle."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:592
msgid ""
"Next we add the camera's local ``Z`` vector times ``input_movement_vector."
"y`` to ``dir``. This is so when the player presses forward or backwards, we "
"add the camera's local ``Z`` axis so the player moves forward or backwards "
"in relation to the camera."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:595
msgid ""
"Because the camera is rotated by ``-180`` degrees, we have to flip the ``Z`` "
"directional vector. Normally forward would be the positive Z axis, so using "
"``basis.z.normalized()`` would work, but we are using ``-basis.z."
"normalized()`` because our camera's Z axis faces backwards in relation to "
"the rest of the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:600
msgid ""
"We do the same thing for the camera's local ``X`` vector, and instead of "
"using ``input_movement_vector.y`` we instead use ``input_movement_vector."
"x``. This makes it where the player moves left/right in relation to the "
"camera when the player presses left/right."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:603
msgid ""
"Next we check if the player is on the floor using :ref:`KinematicBody "
"<class_KinematicBody>`'s ``is_on_floor`` function. If it is, then we check "
"to see if the \"movement_jump\" action has just been pressed. If it has, "
"then we set the player's ``Y`` velocity to ``JUMP_SPEED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:607
msgid ""
"Because we're setting the Y velocity, the player will jump into the air."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:609
msgid ""
"Then we check for the ``ui_cancel`` action. This is so we can free/capture "
"the mouse cursor when the ``escape`` button is pressed. We do this because "
"otherwise we'd have no way to free the cursor, meaning it would be stuck "
"until you terminate the runtime."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:613
msgid ""
"To free/capture the cursor, we check to see if the mouse is visible (freed) "
"or not. If it is, we capture it, and if it's not, we make it visible (free "
"it)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:615
msgid ""
"That's all we're doing right now for ``process_input``. We'll come back "
"several times to this function as we add more complexities to our player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:619
msgid "Now let's look at ``process_movement``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:621
msgid ""
"First we ensure that ``dir`` does not have any movement on the ``Y`` axis by "
"setting its ``Y`` value to zero."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:623
msgid ""
"Next we normalize ``dir`` to ensure we're within a ``1`` radius unit circle. "
"This makes it where we're moving at a constant speed regardless of whether "
"the player is moving straight or diagonally. If we did not normalize, the "
"player would move faster on the diagonal than when going straight."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:626
msgid ""
"Next we add gravity to the player by adding ``GRAVITY * delta`` to the "
"player's ``Y`` velocity."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:628
msgid ""
"After that we assign the player's velocity to a new variable (called "
"``hvel``) and remove any movement on the ``Y`` axis."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:630
msgid ""
"Next we set a new variable (``target``) to the player's direction vector. "
"Then we multiply that by the player's max speed so we know how far the "
"player will move in the direction provided by ``dir``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:633
msgid "After that we make a new variable for acceleration, named ``accel``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:635
msgid ""
"We then take the dot product of ``hvel`` to see if the player is moving "
"according to ``hvel``. Remember, ``hvel`` does not have any ``Y`` velocity, "
"meaning we are only checking if the player is moving forwards, backwards, "
"left, or right."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:639
msgid ""
"If the player is moving according to ``hvel``, then we set ``accel`` to the "
"``ACCEL`` constant so the player will accelerate, otherwise we set ``accel`` "
"to our ``DEACCEL`` constant so the player will decelerate."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:642
msgid ""
"Then we interpolate the horizontal velocity, set the player's ``X`` and "
"``Z`` velocity to the interpolated horizontal velocity, and call "
"``move_and_slide`` to let the :ref:`KinematicBody <class_KinematicBody>` "
"handle moving the player through the physics world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:645
msgid ""
"All the code in ``process_movement`` is exactly the same as the movement "
"code from the Kinematic Character demo!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:649
msgid ""
"The final function we have is the ``_input`` function, and thankfully it's "
"fairly short:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:651
msgid ""
"First we make sure that the event we are dealing with is an :ref:"
"`InputEventMouseMotion <class_InputEventMouseMotion>` event. We also want to "
"check if the cursor is captured, as we do not want to rotate if it is not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:654
msgid ""
"See :ref:`Mouse and input coordinates <doc_mouse_and_input_coordinates>` for "
"a list of possible input events."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:657
msgid ""
"If the event is indeed a mouse motion event and the cursor is captured, we "
"rotate based on the relative mouse motion provided by :ref:"
"`InputEventMouseMotion <class_InputEventMouseMotion>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:660
msgid ""
"First we rotate the ``rotation_helper`` node on the ``X`` axis, using the "
"relative mouse motion's ``Y`` value, provided by :ref:`InputEventMouseMotion "
"<class_InputEventMouseMotion>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:663
msgid ""
"Then we rotate the entire :ref:`KinematicBody <class_KinematicBody>` on the "
"``Y`` axis by the relative mouse motion's ``X`` value."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:665
msgid ""
"Godot converts relative mouse motion into a :ref:`Vector2 <class_Vector2>` "
"where mouse movement going up and down is ``1`` and ``-1`` respectively. "
"Right and Left movement is ``1`` and ``-1`` respectively."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:669
msgid ""
"Because of how we are rotating the player, we multiply the relative mouse "
"motion's ``X`` value by ``-1`` so mouse motion going left and right rotates "
"the player left and right in the same direction."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:673
msgid ""
"Finally, we clamp the ``rotation_helper``'s ``X`` rotation to be between "
"``-70`` and ``70`` degrees so the player cannot rotate themselves upside "
"down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:676
msgid ""
"See :ref:`using transforms <doc_using_transforms>` for more information on "
"rotating transforms."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:680
msgid ""
"To test the code, open up the scene named ``Testing_Area.tscn``, if it's not "
"already opened up. We will be using this scene as we go through the next few "
"tutorial parts, so be sure to keep it open in one of your scene tabs."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:683
msgid ""
"Go ahead and test your code either by pressing :kbd:`F6` with ``Testing_Area."
"tscn`` as the open tab, by pressing the play button in the top right corner, "
"or by pressing :kbd:`F5`. You should now be able to walk around, jump in the "
"air, and look around using the mouse."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:689
msgid "Giving the player a flash light and the option to sprint"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:691
msgid ""
"Before we get to making the weapons work, there are a couple more things we "
"should add."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:693
msgid ""
"Many FPS games have an option to sprint and a flashlight. We can easily add "
"these to our player, so let's do that!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:696
msgid "First we need a few more class variables in our player script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:717
msgid ""
"All the sprinting variables work exactly the same as the non sprinting "
"variables with similar names."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:720
msgid ""
"``is_sprinting`` is a boolean to track whether the player is currently "
"sprinting, and ``flashlight`` is a variable we will be using to hold the "
"player's flash light node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:723
msgid ""
"Now we need to add a few lines of code, starting in ``_ready``. Add the "
"following to ``_ready``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:734
msgid ""
"This gets the ``Flashlight`` node and assigns it to the ``flashlight`` "
"variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:738
msgid ""
"Now we need to change some of the code in ``process_input``. Add the "
"following somewhere in ``process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:780
msgid "Let's go over the additions:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:782
msgid ""
"We set ``is_sprinting`` to ``true`` when the player is holding down the "
"``movement_sprint`` action, and ``false`` when the ``movement_sprint`` "
"action is released. In ``process_movement`` we'll add the code that makes "
"the player faster when they sprint. Here in ``process_input`` we are just "
"going to change the ``is_sprinting`` variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:786
msgid ""
"We do something similar to freeing/capturing the cursor for handling the "
"flashlight. We first check to see if the ``flashlight`` action was just "
"pressed. If it was, we then check to see if ``flashlight`` is visible in the "
"scene tree. If it is, then we hide it, and if it's not, we show it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:791
msgid ""
"Now we need to change a couple things in ``process_movement``. First, "
"replace ``target *= MAX_SPEED`` with the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:808
msgid ""
"Now instead of always multiplying ``target`` by ``MAX_SPEED``, we first "
"check to see if the player is sprinting or not. If the player is sprinting, "
"we instead multiply ``target`` by ``MAX_SPRINT_SPEED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:811
msgid ""
"Now all that's left is to change the acceleration when sprinting. Change "
"``accel = ACCEL`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:828
msgid ""
"Now, when the player is sprinting, we'll use ``SPRINT_ACCEL`` instead of "
"``ACCEL``, which will accelerate the player faster."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:832
msgid ""
"You should now be able to sprint if you press :kbd:`Shift`, and can toggle "
"the flash light on and off by pressing :kbd:`F`!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:834
msgid ""
"Go try it out! You can change the sprint-related class variables to make the "
"player faster or slower when sprinting!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:837
#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1226
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:668
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:778
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:951
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:996
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1137
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1025
msgid "Final notes"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:841
msgid ""
"Whew! That was a lot of work. Now you have a fully working first person "
"character!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:843
msgid ""
"In :ref:`doc_fps_tutorial_part_two` we will add some guns to our player "
"character."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:845
msgid ""
"At this point we've recreated the Kinematic character demo from first person "
"perspective with sprinting and a flash light!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:847
msgid ""
"Currently the player script would be at an ideal state for making all sorts "
"of first person games. For example: Horror games, platformer games, "
"adventure games, and more!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:850
#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1237
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:683
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:787
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:960
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1004
msgid "If you ever get lost, be sure to read over the code again!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:852
msgid ""
"You can download the finished project for this part here: :download:"
"`Godot_FPS_Part_1.zip <files/Godot_FPS_Part_1.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:4
msgid "Part 2"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:9
msgid "In this part we will be giving our player weapons to play with."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:13
msgid ""
"By the end of this part, you will have a player that can fire a pistol, "
"rifle, and attack using a knife. The player will also now have animations "
"with transitions, and the weapons will interact with objects in the "
"environment."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:17
msgid ""
"You are assumed to have finished :ref:`doc_fps_tutorial_part_one` before "
"moving on to this part of the tutorial. The finished project from :ref:"
"`doc_fps_tutorial_part_one` will be the starting project for part 2"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:20
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:18
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:16
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:16
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:19
msgid "Let's get started!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:23
msgid "Making a system to handle animations"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:25
msgid ""
"First we need a way to handle changing animations. Open up ``Player.tscn`` "
"and select the :ref:`AnimationPlayer <class_AnimationPlayer>` Node "
"(``Player`` -> ``Rotation_Helper`` -> ``Model`` -> ``Animation_Player``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:28
msgid ""
"Create a new script called ``AnimationPlayer_Manager.gd`` and attach that to "
"the :ref:`AnimationPlayer <class_AnimationPlayer>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:30
msgid "Add the following code to ``AnimationPlayer_Manager.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:152
msgid "Lets go over what this script is doing:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:156
msgid "Lets start with this script's class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:158
msgid ""
"``states``: A dictionary for holding our animation states. (Further "
"explanation below)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:159
msgid ""
"``animation_speeds``: A dictionary for holding all the speeds at which we "
"want to play our animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:160
msgid ""
"``current_state``: A variable for holding the name of the animation state we "
"are currently in."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:161
msgid ""
"``callback_function``: A variable for holding the callback function. "
"(Further explanation below)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:163
msgid ""
"If you are familiar with state machines, then you may have noticed that "
"``states`` is structured like a basic state machine. Here is roughly how "
"``states`` is set up:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:166
msgid ""
"``states`` is a dictionary with the key being the name of the current state, "
"and the value being an array holding all the animations (states) we can "
"transition to. For example, if we are currently in the ``Idle_unarmed`` "
"state, we can only transition to ``Knife_equip``, ``Pistol_equip``, "
"``Rifle_equip``, and ``Idle_unarmed``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:171
msgid ""
"If we try to transition to a state that is not included in the possible "
"transitions states for the state we are in, then we get a warning message "
"and the animation does not change. We can also automatically transition from "
"some states into others, as will be explained further below in "
"``animation_ended``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:175
msgid ""
"For the sake of keeping this tutorial simple, we are not using a 'proper' "
"state machine. If you are interested to know more about state machines, see "
"the following articles:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:179
msgid ""
"(Python example) https://dev.to/karn/building-a-simple-state-machine-in-"
"python"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:180
msgid ""
"(C# example) https://www.codeproject.com/Articles/489136/"
"UnderstandingplusandplusImplementingplusStateplusP"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:181
msgid "(Wiki article) https://en.wikipedia.org/wiki/Finite-state_machine"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:183
msgid ""
"``animation_speeds`` is how fast each animation will play. Some of the "
"animations are a little slow and in an effort to make everything look "
"smooth, we need to play them at faster speeds."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:186
msgid ""
"Notice that all of the firing animations are faster than their normal speed. "
"Remember this for later!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:188
msgid ""
"``current_state`` will hold the name of the animation state we are currently "
"in."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:190
msgid ""
"Finally, ``callback_function`` will be a :ref:`FuncRef <class_FuncRef>` "
"passed in by the player for spawning bullets at the proper frame of "
"animation. A :ref:`FuncRef <class_FuncRef>` allows us to pass in a function "
"as an argument, effectively allowing us to call a function from another "
"script, which is how we will use it later."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:196
msgid "Now let's look at ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:198
msgid ""
"First we are setting our animation to ``Idle_unarmed`` using the "
"``set_animation`` function, so we for sure start in that animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:201
msgid ""
"Next we connect the ``animation_finished`` signal to this script and assign "
"it to call ``animation_ended``. This means whenever an animation is "
"finished, ``animation_ended`` will be called."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:206
msgid "Lets look at ``set_animation`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:208
msgid ""
"``set_animation`` changes the animation to the animation named "
"``animation_name`` *if* we can transition to it. In other words, if the "
"animation state we are currently in has the passed in animation state name "
"in ``states``, then we will change to that animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:212
msgid ""
"Firstly, we check if the passed in animation name is the same name as the "
"animation currently playing. If they are the same, then we write a warning "
"to the console and return ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:215
msgid ""
"Secondly, we see if :ref:`AnimationPlayer <class_AnimationPlayer>` has the "
"animation with the name ``animation_name`` using ``has_animation``. If it "
"does not, we return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:218
msgid ""
"Thirdly, we check whether ``current_state`` is set. If we have a state in "
"``current_state``, then we get all the possible states we can transition to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:220
msgid ""
"If the animation name is in the list of possible transitions, we set "
"``current_state`` to the passed in animation (``animation_name``), tell :ref:"
"`AnimationPlayer <class_AnimationPlayer>` to play the animation with a blend "
"time of ``-1`` at the speed set in ``animation_speeds`` and return ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:224
msgid "Blend time is how long to blend/mix the two animations together."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:226
msgid ""
"By putting in a value of ``-1``, the new animation instantly plays, "
"overriding whatever animation is already playing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:228
msgid ""
"If you put in a value of ``1``, for one second the new animation will play "
"with increasing strength, blending the two animations together for one "
"second before playing only the new animation. This leads to a smooth "
"transition between animations, which looks great when you are changing from "
"a walking animation to a running animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:232
msgid ""
"We set the blend time to ``-1`` because we want to instantly change "
"animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:236
msgid "Now lets look at ``animation_ended``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:238
msgid ""
"``animation_ended`` is the function that will be called by :ref:"
"`AnimationPlayer <class_AnimationPlayer>` when it's done playing an "
"animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:241
msgid ""
"For certain animation states, we may need to transition into another state "
"when it's finished. To handle this, we check for every possible animation "
"state. If we need to, we will transition into another state."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:244
msgid ""
"If you are using your own animated models, make sure that none of the "
"animations are set to loop. Looping animations do not send the "
"``animation_finished`` signal when they reach the end of the animation and "
"are about to loop again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:248
msgid ""
"The transitions in ``animation_ended`` would ideally be part of the data in "
"``states``, but in an effort to make the tutorial easier to understand, "
"we'll hard code each state transition in ``animation_ended``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:254
msgid ""
"Finally, there is ``animation_callback``. This function will be called by a "
"call method track in our animations. If we have a :ref:`FuncRef "
"<class_FuncRef>` assigned to ``callback_function``, then we call that passed "
"in function. If we do not have a :ref:`FuncRef <class_FuncRef>` assigned to "
"``callback_function``, we print out a warning to the console."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:258
msgid ""
"Try running ``Testing_Area.tscn`` to make sure there are no runtime issues. "
"If the game runs but nothing seems to have changed, then everything is "
"working correctly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:262
msgid "Getting the animations ready"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:264
msgid ""
"Now that we have a working animation manager, we need to call it from our "
"player script. Before that, though, we need to set some animation callback "
"tracks in our firing animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:267
msgid ""
"Open up ``Player.tscn`` if you don't have it open and navigate to the :ref:"
"`AnimationPlayer <class_AnimationPlayer>` node (``Player`` -> "
"``Rotation_Helper`` -> ``Model`` -> ``Animation_Player``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:270
msgid ""
"We need to attach a call method track to three of our animations: The firing "
"animation for the pistol, rifle, and knife. Let's start with the pistol. "
"Click the animation drop down list and select \"Pistol_fire\"."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:273
msgid ""
"Now scroll down to the bottom of the list of animation tracks. The final "
"item in the list should read ``Armature/Skeleton:Left_UpperPointer``. Now "
"above the list, click the \"Add track\" button, to the left of the time line"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:278
msgid ""
"This will bring up a window with a few choices. We want to add a call method "
"track, so click the option that reads \"Call Method Track\". This will open "
"a window showing the entire node tree. Navigate to the :ref:`AnimationPlayer "
"<class_AnimationPlayer>` node, select it, and press OK."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:284
msgid ""
"Now at the bottom of list of animation tracks you will have a green track "
"that reads \"AnimationPlayer\". Now we need to add the point where we want "
"to call our callback function. Scrub the timeline until you reach the point "
"where the muzzle starts to flash."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:288
msgid ""
"The timeline is the window where all the points in our animation are stored. "
"Each of the little points represents a point of animation data."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:291
msgid ""
"To actually preview the \"Pistol_fire\" animation, select the :ref:`Camera "
"<class_Camera>` node underneath Rotation Helper and check the \"Preview\" "
"box underneath Perspective in the top-left corner."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:295
msgid ""
"Scrubbing the timeline means moving ourselves through the animation. So when "
"we say \"scrub the timeline until you reach a point\", what we mean is move "
"through the animation window until you reach the point on the timeline."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:299
msgid ""
"Also, the muzzle of a gun is the end point where the bullet comes out. The "
"muzzle flash is the flash of light that escapes the muzzle when a bullet is "
"fired. The muzzle is also sometimes referred to as the barrel of the gun."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:303
msgid ""
"For finer control when scrubbing the timeline, press :kbd:`Ctrl` and scroll "
"forward with the mouse wheel to zoom in. Scrolling backwards will zoom out."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:306
msgid ""
"You can also change how the timeline scrubbing snaps by changing the value "
"in ``Step (s)`` to a lower/higher value."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:308
msgid ""
"Once you get to a point you like, right click on the row for \"Animation "
"Player\" and press ``Insert Key``. In the empty name field, enter "
"``animation_callback`` and press :kbd:`Enter`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:314
msgid ""
"Now when we are playing this animation the call method track will be "
"triggered at that specific point of the animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:318
msgid "Let's repeat the process for the rifle and knife firing animations!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:320
msgid ""
"Because the process is exactly the same as the pistol, the process is going "
"to explained in a little less depth. Follow the steps from above if you get "
"lost! It is exactly the same, just on a different animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:323
msgid ""
"Go to the \"Rifle_fire\" animation from the animation drop down. Add the "
"call method track once you reach the bottom of the animation track list by "
"clicking the \"Add Track\" button above the list. Find the point where the "
"muzzle starts to flash and right click and press ``Insert Key`` to add a "
"call method track point at that position on the track."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:327
msgid ""
"Type \"animation_callback\" into the name field of the pop up which opened "
"and press :kbd:`Enter`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:329
msgid ""
"Now we need to apply the callback method track to the knife animation. "
"Select the \"Knife_fire\" animation and scroll to the bottom of the "
"animation tracks. Click the \"Add Track\" button above the list and add a "
"method track. Next find a point around the first third of the animation to "
"place the animation callback method point at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:333
msgid ""
"We will not actually be firing the knife, and the animation is a stabbing "
"animation rather than a firing one. For this tutorial we are reusing the gun "
"firing logic for our knife, so the animation has been named in a style that "
"is consistent with the other animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:337
msgid ""
"From there right click on the timeline and click \"Insert Key\". Put "
"\"animation_callback\" into the name field and press :kbd:`Enter`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:339
msgid "Be sure to save your work!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:341
msgid ""
"With that done, we are almost ready to start adding the ability to fire to "
"our player script! We need to set up one last scene: The scene for our "
"bullet object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:345
msgid "Creating the bullet scene"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:347
msgid ""
"There are several ways to handle a gun's bullets in video games. In this "
"tutorial series, we will be exploring two of the more common ways: Objects, "
"and raycasts."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:352
msgid ""
"One of the two ways is using a bullet object. This will be an object that "
"travels through the world and handles its own collision code. In this method "
"we create/spawn a bullet object in the direction our gun is facing, and then "
"it travels forward."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:356
msgid ""
"There are several advantages to this method. The first being we do not have "
"to store the bullets in our player. We can simply create the bullet and then "
"move on, and the bullet itself will handle checking for collisions, sending "
"the proper signal(s) to the object it collides with, and destroying itself."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:359
msgid ""
"Another advantage is we can have more complex bullet movement. If we want to "
"make the bullet fall ever so slightly as time goes on, we can make the "
"bullet controlling script slowly push the bullet towards the ground. Using "
"an object also makes the bullet take time to reach its target, it doesn't "
"instantly hit whatever it's pointed at. This feels more realistic because "
"nothing in real life moves instantly from one point to another."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:363
msgid ""
"One of the huge disadvantages is performance. While having each bullet "
"calculate their own paths and handle their own collision allows for a lot of "
"flexibility, it comes at the cost of performance. With this method we are "
"calculating every bullet's movement every step, and while this may not be a "
"problem for a few dozen bullets, it can become a huge problem when you "
"potentially have several hundred bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:367
msgid ""
"Despite the performance hit, many first person shooters include some form of "
"object bullets. Rocket launchers are a prime example because in many first "
"person shooters, rockets do not just instantly explode at their target "
"position. You can also find bullets as objects many times with grenades "
"because they generally bounce around the world before exploding."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:371
msgid ""
"While I cannot say for sure this is the case, these games *probably* use "
"bullet objects in some form or another: (These are entirely from my "
"observations. **They may be entirely wrong**. I have never worked on **any** "
"of the following games)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:374
msgid ""
"Halo (Rocket launchers, fragmentation grenades, sniper rifles, brute shot, "
"and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:375
msgid ""
"Destiny (Rocket launchers, grenades, fusion rifles, sniper rifles, super "
"moves, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:376
msgid ""
"Call of Duty (Rocket launchers, grenades, ballistic knives, crossbows, and "
"more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:377
msgid "Battlefield (Rocket launchers, grenades, claymores, mortars, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:379
msgid ""
"Another disadvantage with bullet objects is networking. Bullet objects have "
"to sync the positions (at least) with all the clients that are connected to "
"the server."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:382
msgid ""
"While we are not implementing any form of networking (as that would be in "
"its own entire tutorial series), it is a consideration to keep in mind when "
"creating your first person shooter, especially if you plan on adding some "
"form of networking in the future."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:387
msgid ""
"The other way of handling bullet collisions we will be looking at is "
"raycasting."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:389
msgid ""
"This method is extremely common in guns that have fast moving bullets that "
"rarely change trajectory over time."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:391
msgid ""
"Instead of creating a bullet object and sending it through space, we instead "
"send a ray starting from the barrel/muzzle of the gun forwards. We set the "
"raycast's origin to the starting position of the bullet, and based on the "
"length we can adjust how far the bullet 'travels' through space."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:394
msgid ""
"While I cannot say for sure this is the case, these games *probably* use "
"raycasts in some form or another: (These are entirely from my observations. "
"**They may be entirely wrong**. I have never worked on **any** of the "
"following games)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:397
msgid ""
"Halo (Assault rifles, DMRs, battle rifles, covenant carbine, spartan laser, "
"and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:398
msgid ""
"Destiny (Auto rifles, pulse rifles, scout rifles, hand cannons, machine "
"guns, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:399
msgid ""
"Call of Duty (Assault rifles, light machine guns, sub machine guns, pistols, "
"and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:400
msgid "Battlefield (Assault rifles, SMGs, carbines, pistols, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:402
msgid ""
"One huge advantage of this method is that it's light on performance. Sending "
"a couple hundred rays through space is *much* easier for the computer to "
"calculate than sending a couple hundred bullet objects."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:406
msgid ""
"Another advantage is we can instantly know if we've hit something or not "
"exactly when we call for it. For networking this is important because we do "
"not need to sync the bullet movements over the Internet, we only need to "
"send whether or not the raycast hit."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:409
msgid ""
"Raycasting does have some disadvantages, though. One major disadvantage is "
"we cannot easily cast a ray in anything but a linear line. This means we can "
"only fire in a straight line for however long our ray length is. You can "
"create the illusion of bullet movement by casting multiple rays at different "
"positions, but not only is this hard to implement in code, it is also "
"heavier on performance."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:413
msgid ""
"Another disadvantage is we cannot see the bullet. With bullet objects we can "
"actually see the bullet travel through space if we attach a mesh to it, but "
"because raycasts happen instantly, we do not have a decent way of showing "
"the bullets. You could draw a line from the origin of the raycast to the "
"point where the raycast collided, and that is one popular way of showing "
"raycasts. Another way is simply not drawing the raycast at all, because "
"theoretically the bullets move so fast our eyes could not see it anyway."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:420
msgid ""
"Let's get the bullet object set up. This is what our pistol will create when "
"the \"Pistol_fire\" animation callback function is called."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:423
msgid ""
"Open up ``Bullet_Scene.tscn``. The scene contains :ref:`Spatial "
"<class_Spatial>` node called bullet, with a :ref:`MeshInstance "
"<class_MeshInstance>` and an :ref:`Area <class_Area>` with a :ref:"
"`CollisionShape <class_CollisionShape>` children to it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:427
msgid ""
"Create a new script called ``Bullet_script.gd`` and attach it to the "
"``Bullet`` :ref:`Spatial <class_Spatial>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:429
msgid ""
"We are going to move the entire bullet object at the root (``Bullet``). We "
"will be using the :ref:`Area <class_Area>` to check whether or not we've "
"collided with something"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:431
msgid ""
"Why are we using an :ref:`Area <class_Area>` and not a :ref:`RigidBody "
"<class_RigidBody>`? The main reason we're not using a :ref:`RigidBody "
"<class_RigidBody>` is because we do not want the bullet to interact with "
"other :ref:`RigidBody <class_RigidBody>` nodes. By using an :ref:`Area "
"<class_Area>` we are ensuring that none of the other :ref:`RigidBody "
"<class_RigidBody>` nodes, including other bullets, will be effected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:435
msgid ""
"Another reason is simply because it is easier to detect collisions with an :"
"ref:`Area <class_Area>`!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:437
msgid "Here's the script that will control our bullet:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:473
msgid "Let's go through the script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:477
msgid "First we define a few class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:479
msgid "``BULLET_SPEED``: The speed at which the bullet travels."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:480
msgid ""
"``BULLET_DAMAGE``: The damage the bullet will cause to anything with which "
"it collides."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:481
msgid "``KILL_TIMER``: How long the bullet can last without hitting anything."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:482
msgid "``timer``: A float for tracking how long the bullet has been alive."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:483
msgid ""
"``hit_something``: A boolean for tracking whether or not we've hit something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:485
msgid ""
"With the exception of ``timer`` and ``hit_something``, all of these "
"variables change how the bullet interacts with the world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:488
msgid ""
"The reason we are using a kill timer is so we do not have a case where we "
"get a bullet travelling forever. By using a kill timer, we can ensure that "
"no bullets will travel forever and consume resources."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:492
msgid ""
"As in :ref:`doc_fps_tutorial_part_one`, we have a couple all uppercase class "
"variables. The reason behind this is the same as the reason given in :ref:"
"`doc_fps_tutorial_part_one`: We want to treat these variables like "
"constants, but we want to be able to change them. In this case we will later "
"need to change the damage and speed of these bullets, so we need them to be "
"variables and not constants."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:499
msgid ""
"In ``_ready`` we set the area's ``body_entered`` signal to ourself so that "
"it calls the ``collided`` function when a body enters the area."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:504
msgid ""
"``_physics_process`` gets the bullet's local ``Z`` axis. If you look at the "
"scene in local mode, you will find that the bullet faces the positive local "
"``Z`` axis."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:507
msgid ""
"Next we translate the entire bullet by that forward direction, multiplying "
"in our speed and delta time."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:509
msgid ""
"After that we add delta time to our timer and check whether the timer has "
"reached a value as big or greater than our ``KILL_TIME`` constant. If it "
"has, we use ``queue_free`` to free the bullet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:514
msgid "In ``collided`` we check whether we've hit something yet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:516
msgid ""
"Remember that ``collided`` is only called when a body has entered the :ref:"
"`Area <class_Area>` node. If the bullet has not already collided with "
"something, we then proceed to check if the body the bullet has collided with "
"has a function/method called ``bullet_hit``. If it does, we call it and pass "
"in the bullet's damage and the bullet's global transform so we can get the "
"bullet's rotation and position."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:521
msgid ""
"in ``collided``, the passed in body can be a :ref:`StaticBody "
"<class_StaticBody>`, :ref:`RigidBody <class_RigidBody>`, or :ref:"
"`KinematicBody <class_KinematicBody>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:524
msgid ""
"We set the Bullet's ``hit_something`` variable to ``true`` because "
"regardless of whether or not the body that the bullet collided with has the "
"``bullet_hit`` function/method, it has hit something and so we need to make "
"sure the bullet does not hit anything else."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:527
msgid "Then we free the bullet using ``queue_free``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:529
msgid ""
"You may be wondering why we even have a ``hit_something`` variable if we "
"free the bullet using ``queue_free`` as soon as it hits something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:532
msgid ""
"The reason we need to track whether we've hit something or not is because "
"``queue_free`` does not immediately free the node, so the bullet could "
"collide with another body before Godot has a chance to free it. By tracking "
"whether the bullet has hit something, we can make sure that the bullet will "
"only hit one object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:540
msgid ""
"Before we start programming the player again, let's take a quick look at "
"``Player.tscn``. Open up ``Player.tscn`` again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:543
msgid ""
"Expand ``Rotation_Helper`` and notice how it has two nodes: "
"``Gun_Fire_Points`` and ``Gun_Aim_Point``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:546
msgid ""
"``Gun_aim_point`` is the point that the bullets will be aiming at. Notice "
"how it is lined up with the center of the screen and pulled a distance "
"forward on the Z axis. ``Gun_aim_point`` will serve as the point where the "
"bullets will for sure collide with as it goes along."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:551
msgid ""
"There is a invisible mesh instance for debugging purposes. The mesh is a "
"small sphere that visually shows at which target the bullets will be aiming."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:554
msgid ""
"Open up ``Gun_Fire_Points`` and you'll find three more :ref:`Spatial "
"<class_Spatial>` nodes, one for each weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:557
msgid ""
"Open up ``Rifle_Point`` and you'll find a :ref:`Raycast <class_Raycast>` "
"node. This is where we will be sending the raycasts for our rifle's bullets. "
"The length of the raycast will dictate how far our bullets will travel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:561
msgid ""
"We are using a :ref:`Raycast <class_Raycast>` node to handle the rifle's "
"bullet because we want to fire lots of bullets quickly. If we use bullet "
"objects, it is quite possible we could run into performance issues on older "
"machines."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:565
msgid ""
"If you are wondering from where the positions of the points came, they are "
"the rough positions of the ends of each weapon. You can see this by going to "
"``AnimationPlayer``, selecting one of the firing animations and scrubbing "
"through the timeline. The point for each weapon should mostly line up with "
"the end of each weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:571
msgid ""
"Open up ``Knife_Point`` and you'll find an :ref:`Area <class_Area>` node. We "
"are using an :ref:`Area <class_Area>` for the knife because we only care for "
"all the bodies close to us, and because our knife does not fire into space. "
"If we were making a throwing knife, we would likely spawn a bullet object "
"that looks like a knife."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:576
msgid ""
"Finally, we have ``Pistol_Point``. This is the point where we will be "
"creating/instancing our bullet objects. We do not need any additional nodes "
"here, as the bullet handles all of its own collision detection."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:580
msgid ""
"Now that we've seen how we will handle our other weapons, and where we will "
"spawn the bullets, let's start working on making them work."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:583
msgid ""
"You can also look at the HUD nodes if you want. There is nothing fancy there "
"and other than using a single :ref:`Label <class_Label>`, we will not be "
"touching any of those nodes. Check :ref:"
"`doc_design_interfaces_with_the_control_nodes` for a tutorial on using GUI "
"nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:589
msgid "Creating the first weapon"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:591
msgid "Lets write the code for each of our weapons, starting with the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:593
msgid ""
"Select ``Pistol_Point`` (``Player`` -> ``Rotation_Helper`` -> "
"``Gun_Fire_Points`` -> ``Pistol_Point``) and create a new script called "
"``Weapon_Pistol.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:595
msgid "Add the following code to ``Weapon_Pistol.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:646
msgid "Let's go over how the script works."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:650
msgid "First we define some class variables we'll need in the script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:652
msgid "``DAMAGE``: The amount of damage a single bullet does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:653
msgid "``IDLE_ANIM_NAME``: The name of the pistol's idle animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:654
msgid "``FIRE_ANIM_NAME``: The name of the pistol's fire animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:655
msgid ""
"``is_weapon_enabled``: A variable for checking whether this weapon is in use/"
"enabled."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:656
msgid "``bullet_scene``: The bullet scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:657
msgid "``player_node``: A variable to hold ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:659
msgid ""
"The reason we define most of these variables is so we can use them in "
"``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:661
msgid ""
"Each of the weapons we'll make will have all these variables (minus "
"``bullet_scene``) so we have a consistent interface to interact with in "
"``Player.gd``. By using the same variables/functions in each weapon, we can "
"interact with them without having to know which weapon we are using, which "
"makes our code much more modular because we can add weapons without having "
"to change much of the code in ``Player.gd`` and it will just work."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:666
msgid ""
"We could write all the code in ``Player.gd``, but then ``Player.gd`` will "
"get increasingly harder to manage as we add weapons. By using a modular "
"design with a consistent interface, we can keep ``Player.gd`` nice and neat, "
"while also making it easier to add/remove/modify weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:671
msgid "In ``_ready`` we simply pass over it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:673
msgid ""
"There is one thing of note though, an assumption that we'll fill in ``Player."
"gd`` at some point."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:675
msgid ""
"We are going to assume that ``Player.gd`` will pass themselves in before "
"calling any of the functions in ``Weapon_Pistol.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:677
msgid ""
"While this can lead to situations where the player does not pass themselves "
"in (because we forget), we would have to have a long string of "
"``get_parent`` calls to traverse up the scene tree to retrieve the player. "
"This does not look pretty (``get_parent().get_parent().get_parent()`` and so "
"on) and it is relatively safe to assume we will remember to pass ourselves "
"to each weapon in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:683
msgid "Next let's look at ``fire_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:685
msgid "The first thing we do is instance the bullet scene we made earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:687
msgid ""
"By instancing the scene, we are creating a new node holding all the node(s) "
"in the scene we instanced, effectively cloning that scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:689
msgid ""
"Then we add a ``clone`` to the first child node of the root of the scene we "
"are currently in. By doing this, we're making it a child of the root node of "
"the currently loaded scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:691
msgid ""
"In other words, we are adding a ``clone`` as a child of the first node "
"(whatever is at the top of the scene tree) in the currently loaded/opened "
"scene. If the currently loaded/open scene is ``Testing_Area.tscn``, we'd be "
"adding our ``clone`` as a child of ``Testing_Area``, the root node in that "
"scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:694
msgid ""
"As mentioned later below in the section on adding sounds, this method makes "
"an assumption. This will be explained later in the section on adding sounds "
"in :ref:`doc_fps_tutorial_part_three`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:697
msgid ""
"Next we set the global transform of the clone to the ``Pistol_Point``'s "
"global transform. The reason we do this is so the bullet is spawned at the "
"end of the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:699
msgid ""
"You can see that ``Pistol_Point`` is positioned right at the end of the "
"pistol by clicking the :ref:`AnimationPlayer <class_AnimationPlayer>` and "
"scrolling through ``Pistol_fire``. You'll find the position is more or less "
"at the end of the pistol when it fires."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:702
msgid ""
"Next we scale it up by a factor of ``4`` because the bullet scene is a "
"little too small by default."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:704
msgid ""
"Then we set the bullet's damage (``BULLET_DAMAGE``) to the amount of damage "
"a single pistol bullet does (``DAMAGE``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:708
msgid "Now let's look at ``equip_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:710
msgid ""
"The first thing we do is check to see whether the animation manager is in "
"the pistol's idle animation. If we are in the pistol's idle animation, we "
"set ``is_weapon_enabled`` to ``true`` and return ``true`` because the pistol "
"has successfully been equipped."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:714
msgid ""
"Because we know our pistol's ``equip`` animation automatically transitions "
"to the pistol's idle animation, if we are in the pistol's idle animation the "
"pistol must have finished playing the equip animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:717
msgid ""
"We know these animations will transition because we wrote the code to make "
"them transition in ``Animation_Manager.gd``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:719
msgid ""
"Next we check to see if the player is in the ``Idle_unarmed`` animation "
"state. Because all unequipping animations go to this state, and because any "
"weapon can be equipped from this state, we change animations to "
"``Pistol_equip`` if the player is in the ``Idle_unarmed`` state."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:722
msgid ""
"Since we know ``Pistol_equip`` will transition to ``Pistol_idle``, we do not "
"need to do any more additional processing for equipping weapons, but since "
"we were not able to equip the pistol yet, we return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:727
msgid "Finally, let's look at ``unequip_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:729
msgid ""
"``unequip_weapon`` is similar to ``equip_weapon``, but instead we're "
"checking things in reverse."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:731
msgid ""
"First we check to see whether the player is in the idle animation state. "
"Then we check to make sure the player is not in the ``Pistol_unequip`` "
"animation. If the player is not in the ``Pistol_unequip`` animation, we want "
"to play the ``pistol_unequip`` animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:734
msgid ""
"You may be wondering why we are checking to see whether the player is in the "
"pistol's idle animation, and then making sure the player is not unequipping "
"right after. The reason behind the additional check is because we could (in "
"rare cases) call ``unequip_weapon`` twice before we've had a chance to "
"process ``set_animation``, so we add this additional check to make sure the "
"unequip animation plays."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:738
msgid ""
"Next we check to see whether the player is in ``Idle_unarmed``, which is the "
"animation state we will transition into from ``Pistol_unequip``. If the "
"player is in ``Idle_unarmed``, then we set ``is_weapon_enabled`` to "
"``false`` since we are no longer using this weapon, and return ``true`` "
"because we have successfully unequipped the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:741
msgid ""
"If the player is not in ``Idle_unarmed``, we return ``false`` because we "
"have not yet successfully unequipped the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:744
msgid "Creating the other two weapons"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:746
msgid ""
"Now that we have all the code we'll need for the pistol, let's add the code "
"for the rifle and knife next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:748
msgid ""
"Select ``Rifle_Point`` (``Player`` -> ``Rotation_Helper`` -> "
"``Gun_Fire_Points`` -> ``Rifle_Point``) and create a new script called "
"``Weapon_Rifle.gd``, then add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:801
msgid ""
"Most of this is exactly the same as ``Weapon_Pistol.gd``, so we're only "
"going to look at what's changed: ``fire_weapon``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:803
msgid ""
"The first thing we do is get the :ref:`Raycast <class_Raycast>` node, which "
"is a child of ``Rifle_Point``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:805
msgid ""
"Next we force the :ref:`Raycast <class_Raycast>` to update using "
"``force_raycast_update``. This will force the :ref:`Raycast <class_Raycast>` "
"to detect collisions when we call it, meaning we get a frame perfect "
"collision check with the 3D physics world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:808
msgid ""
"Then we check to see if the :ref:`Raycast <class_Raycast>` collided with "
"something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:810
msgid ""
"If the :ref:`Raycast <class_Raycast>` has collided with something, we first "
"get the collision body it collided with. This can be a :ref:`StaticBody "
"<class_StaticBody>`, :ref:`RigidBody <class_RigidBody>`, or a :ref:"
"`KinematicBody <class_KinematicBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:813
msgid ""
"Next we want to make sure the body we've collided with is not the player, "
"since we (probably) do not want to give the player the ability to shoot "
"themselves in the foot."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:815
msgid ""
"If the body is not the player, we then check to see if it has a function/"
"method called ``bullet_hit``. If it does, we call it and pass in the amount "
"of damage this bullet does (``DAMAGE``), and the global transform of the :"
"ref:`Raycast <class_Raycast>` so we can tell from which direction the bullet "
"came."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:820
msgid "Now all we need to do is write the code for the knife."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:822
msgid ""
"Select ``Knife_Point`` (``Player`` -> ``Rotation_Helper`` -> "
"``Gun_Fire_Points`` -> ``Knife_Point``) and create a new script called "
"``Weapon_Knife.gd``, then add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:873
msgid ""
"As with ``Weapon_Rifle.gd``, the only differences are in ``fire_weapon``, so "
"let's look at that:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:875
msgid ""
"The first thing we do is get the :ref:`Area <class_Area>` child node of "
"``Knife_Point``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:877
msgid ""
"Next we want to get all the collision bodies inside the :ref:`Area "
"<class_Area>` using ``get_overlapping_bodies``. This will return a list of "
"every body that touches the :ref:`Area <class_Area>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:880
msgid "We next want to go through each of those bodies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:882
msgid ""
"First we check to make sure the body is not the player, because we do not "
"want to let the player be able to stab themselves. If the body is the "
"player, we use ``continue`` so we jump and look at the next body in "
"``bodies``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:885
msgid ""
"If we have not jumped to the next body, we then check to see if the body has "
"the ``bullet_hit`` function/method. If it does, we call it, passing in the "
"amount of damage a single knife swipe does (``DAMAGE``) and the global "
"transform of the :ref:`Area <class_Area>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:888
msgid ""
"While we could attempt to calculate a rough location for where the knife hit "
"exactly, we are not going to because using the :ref:`Area <class_Area>`'s "
"position works well enough and the extra time needed to calculate a rough "
"position for each body is not worth the effort."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:893
msgid "Making the weapons work"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:895
msgid "Let's start making the weapons work in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:897
msgid ""
"First let's start by adding some class variables we'll need for the weapons:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:915
msgid "Let's go over what these new variables will do:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:917
msgid ""
"``animation_manager``: This will hold the :ref:`AnimationPlayer "
"<class_AnimationPlayer>` node and its script, which we wrote previously."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:918
msgid ""
"``current_weapon_name``: The name of the weapon we are currently using. It "
"has four possible values: ``UNARMED``, ``KNIFE``, ``PISTOL``, and ``RIFLE``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:919
msgid "``weapons``: A dictionary that will hold all the weapon nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:920
msgid ""
"``WEAPON_NUMBER_TO_NAME``: A dictionary allowing us to convert from a "
"weapon's number to its name. We'll use this for changing weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:921
msgid ""
"``WEAPON_NAME_TO_NUMBER``: A dictionary allowing us to convert from a "
"weapon's name to its number. We'll use this for changing weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:922
msgid ""
"``changing_weapon``: A boolean to track whether or not we are changing guns/"
"weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:923
msgid "``changing_weapon_name``: The name of the weapon we want to change to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:924
msgid ""
"``health``: How much health our player has. In this part of the tutorial we "
"will not be using it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:925
msgid ""
"``UI_status_label``: A label to show how much health we have, and how much "
"ammo we have both in our gun and in reserve."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:929
msgid ""
"Next we need to add a few things in ``_ready``. Here's the new ``_ready`` "
"function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:961
msgid "Let's go over what's changed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:963
msgid ""
"First we get the :ref:`AnimationPlayer <class_AnimationPlayer>` node and "
"assign it to the ``animation_manager`` variable. Then we set the callback "
"function to a :ref:`FuncRef <class_FuncRef>` that will call the player's "
"``fire_bullet`` function. Right now we haven't written the ``fire_bullet`` "
"function, but we'll get there soon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:967
msgid ""
"Next we get all the weapon nodes and assign them to ``weapons``. This will "
"allow us to access the weapon nodes only with their name (``KNIFE``, "
"``PISTOL``, or ``RIFLE``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:970
msgid ""
"We then get ``Gun_Aim_Point``'s global position so we can rotate the "
"player's weapons to aim at it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:972
msgid "Then we go through each weapon in ``weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:974
msgid ""
"We first get the weapon node. If the weapon node is not ``null``, we then "
"set its ``player_node`` variable to this script (``Player.gd``). Then we "
"have it look at ``gun_aim_point_pos`` using the ``look_at`` function, and "
"then rotate it by ``180`` degrees on the ``Y`` axis."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:977
msgid ""
"We rotate all of those weapon points by ``180`` degrees on their ``Y`` axis "
"because our camera is pointing backwards. If we did not rotate all of these "
"weapon points by ``180`` degrees, all of the weapons would fire backwards."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:980
msgid ""
"Then we set ``current_weapon_name`` and ``changing_weapon_name`` to "
"``UNARMED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:982
msgid "Finally, we get the UI :ref:`Label <class_Label>` from our HUD."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:986
msgid ""
"Let's add a new function call to ``_physics_process`` so we can change "
"weapons. Here's the new code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:996
msgid "Now we will call ``process_changing_weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1000
msgid ""
"Now let's add all the player input code for the weapons in "
"``process_input``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1040
msgid "Let's go over the additions, starting with how we're changing weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1042
msgid ""
"First we get the current weapon's number and assign it to "
"``weapon_change_number``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1044
msgid ""
"Then we check to see if any of the number keys (keys 1-4) are pressed. If "
"they are, we set ``weapon_change_number`` to the value mapped at that key."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1047
msgid ""
"The reason key 1 is mapped to ``0`` is because the first element in a list "
"is mapped to zero, not one. Most list/array accessors in most programming "
"languages start at ``0`` instead of ``1``. See https://en.wikipedia.org/wiki/"
"Zero-based_numbering for more information."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1050
msgid ""
"Next we check to see if ``shift_weapon_positive`` or "
"``shift_weapon_negative`` is pressed. If one of them is, we add/subtract "
"``1`` from ``weapon_change_number``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1053
msgid ""
"Because the player may have shifted ``weapon_change_number`` outside of the "
"number of weapons the player has, we clamp it so it cannot exceed the "
"maximum number of weapons the player has and it ensures "
"``weapon_change_number`` is ``0`` or more."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1056
msgid ""
"Then we check to make sure the player is not already changing weapons. If "
"the player is not, we then check to see if the weapon the player wants to "
"change to is a new weapon and not the weapon the player is currently using. "
"If the weapon the player is wanting to change to is a new weapon, we then "
"set ``changing_weapon_name`` to the weapon at ``weapon_change_number`` and "
"set ``changing_weapon`` to ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1060
msgid ""
"For firing the weapon we first check to see if the ``fire`` action is "
"pressed. Then we check to make sure the player is not changing weapons. Next "
"we get the weapon node for the current weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1064
msgid ""
"If the current weapon node does not equal ``null``, and the player is in its "
"``IDLE_ANIM_NAME`` state, we set the player's animation to the current "
"weapon's ``FIRE_ANIM_NAME``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1069
msgid "Let's add ``process_changing_weapons`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1071
msgid "Add the following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1107
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:535
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:290
msgid "Let's go over what's happening here:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1109
msgid ""
"The first thing we do is make sure we've received input to change weapons. "
"We do this by making sure ``changing_weapons`` is ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1111
msgid ""
"Next we define a variable (``weapon_unequipped``) so we can check whether "
"the current weapon has been successfully unequipped or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1113
msgid "Then we get the current weapon from ``weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1115
msgid ""
"If the current weapon is not ``null``, then we need to check whether the "
"weapon is enabled. If the weapon is enabled, we call its ``unequip_weapon`` "
"function so it will start the unequip animation. If the weapon is not "
"enabled, we set ``weapon_unequipped`` to ``true`` because the weapon has "
"successfully been unequipped."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1118
msgid ""
"If the current weapon is ``null``, then we can simply set "
"``weapon_unequipped`` to ``true``. The reason we do this check is because "
"there is no weapon script/node for ``UNARMED``, but there is also no "
"animations for ``UNARMED``, so we can just start equipping the weapon the "
"player wants to change to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1121
msgid ""
"If the player has successfully unequipped the current weapon "
"(``weapon_unequipped == true``), we need to equip the new weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1123
msgid ""
"First we define a new variable (``weapon_equipped``) for tracking whether "
"the player has successfully equipped the new weapon or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1125
msgid ""
"Then we get the weapon the player wants to change to. If the weapon the "
"player wants to change to is not ``null``, we then check to see whether it's "
"enabled or not. If it is not enabled, we call its ``equip_weapon`` function "
"so it starts to equip the weapon. If the weapon is enabled, we set "
"``weapon_equipped`` to ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1128
msgid ""
"If the weapon the player wants to change to is ``null``, we simply set "
"``weapon_equipped`` to ``true`` because we do not have any node/script for "
"``UNARMED``, nor do we have any animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1131
msgid ""
"Finally, we check to see whether the player has successfully equipped the "
"new weapon. If (s)he has done so, we set ``changing_weapon`` to ``false`` "
"because the player is no longer changing weapons. We also set "
"``current_weapon_name`` to ``changing_weapon_name`` since the current weapon "
"has changed, and then we set ``changing_weapon_name`` to an empty string."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1137
msgid ""
"Now, we need to add one more function to the player, and then the player is "
"ready to start firing the weapons!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1139
msgid ""
"We need to add ``fire_bullet``, which will be called by the :ref:"
"`AnimationPlayer <class_AnimationPlayer>` at those points we set earlier in "
"the :ref:`AnimationPlayer <class_AnimationPlayer>` function track:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1151
msgid "Let's go over what this function does:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1153
msgid ""
"First we check to see whether the player is changing weapons. If the player "
"is changing weapons, we do not want shoot, so we ``return``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1155
msgid ""
"Calling ``return`` stops the rest of the function from being called. In this "
"case, we are not returning a variable because we are only interested in not "
"running the rest of the code, and because we are not looking for a returned "
"variable either when we call this function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1159
msgid ""
"Then we tell the current weapon the player is using to fire by calling its "
"``fire_weapon`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1161
msgid ""
"Remember how we mentioned the speed of the animations for firing was faster "
"than the other animations? By changing the firing animation speeds, you can "
"change how fast the weapon fires bullets!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1167
msgid ""
"Before we are ready to test our new weapons, we still have a bit of work to "
"do."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1170
msgid "Creating some test subjects"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1172
msgid ""
"Create a new script by going to the scripting window, clicking \"file\", and "
"selecting new. Name this script ``RigidBody_hit_test`` and make sure it "
"extends :ref:`RigidBody <class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1175
msgid "Now we need to add this code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1192
msgid "Let's go over how ``bullet_hit`` works:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1195
msgid ""
"First we get the bullet's forward directional vector. This is so we can tell "
"from which direction the bullet will hit the :ref:`RigidBody "
"<class_RigidBody>`. We will use this to push the :ref:`RigidBody "
"<class_RigidBody>` in the same direction as the bullet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1198
msgid ""
"We need to boost the directional vector by ``BASE_BULLET_BOOST`` so the "
"bullets pack a bit more of a punch and move the :ref:`RigidBody "
"<class_RigidBody>` nodes in a visible way. You can just set "
"``BASE_BULLET_BOOST`` to lower or higher values if you want less or more of "
"a reaction when the bullets collide with the :ref:`RigidBody "
"<class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1202
msgid "Then we apply an impulse using ``apply_impulse``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1204
msgid ""
"First, we need to calculate the position for the impulse. Because "
"``apply_impulse`` takes a vector relative to the :ref:`RigidBody "
"<class_RigidBody>`, we need to calculate the distance from the :ref:"
"`RigidBody <class_RigidBody>` to the bullet. We do this by subtracting the :"
"ref:`RigidBody <class_RigidBody>`'s global origin/position from the bullet's "
"global origin/position. This gets us the distance from the :ref:`RigidBody "
"<class_RigidBody>` to the bullet. We normalize this vector so the size of "
"the collider does not effect how much the bullets move the :ref:`RigidBody "
"<class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1210
msgid ""
"Finally, we need to calculate the force for the impulse. For this, we use "
"the direction the bullet is facing and multiply it by the bullet's damage. "
"This gives a nice result and for stronger bullets, we get a stronger result."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1215
msgid ""
"Now we need to attach this script to all of the :ref:`RigidBody "
"<class_RigidBody>` nodes we want to affect."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1217
msgid ""
"Open up ``Testing_Area.tscn`` and select all the cubes parented to the "
"``Cubes`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1219
msgid ""
"If you select the top cube, and then hold down :kbd:`Shift` and select the "
"last cube, Godot will select all the cubes in-between!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1222
msgid ""
"Once you have all the cubes selected, scroll down in the inspector until you "
"get to the \"scripts\" section. Click the drop down and select \"Load\". "
"Open your newly created ``RigidBody_hit_test.gd`` script."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1230
msgid ""
"That was a lot of code! But now, with all that done, you can go and give "
"your weapons a test!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1232
msgid ""
"You should now be able to fire as many bullets as you want at the cubes and "
"they will move in response to the bullets colliding with them."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1235
msgid ""
"In :ref:`doc_fps_tutorial_part_three`, we will add ammo to the weapons, as "
"well as some sounds!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1239
msgid ""
"You can download the finished project for this part here: :download:"
"`Godot_FPS_Part_2.zip <files/Godot_FPS_Part_2.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:4
msgid "Part 3"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:9
msgid ""
"In this part, we will be limiting the player's weapons by giving them ammo. "
"We will also be giving the player the ability to reload, and we will be "
"adding sounds when the weapons fire."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:15
msgid ""
"You are assumed to have finished :ref:`doc_fps_tutorial_part_two` before "
"moving on to this part of the tutorial. The finished project from :ref:"
"`doc_fps_tutorial_part_two` will be the starting project for part 3"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:22
msgid "Changing levels"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:24
msgid ""
"Now that we have a fully working FPS, let's move to a more FPS-like level."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:26
msgid ""
"Open up ``Space_Level.tscn`` (``assets/Space_Level_Objects/Space_Level."
"tscn``) and/or ``Ruins_Level.tscn`` (``assets/Ruin_Level_Objects/Ruins_Level."
"tscn``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:29
msgid ""
"``Space_Level.tscn`` and ``Ruins_Level.tscn`` are complete custom FPS levels "
"created for the purpose of this tutorial. Press ``Play Current Scene`` "
"button, or :kbd:`F6` on keyboard, and give each a try."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:33
msgid ""
"``Space_Level.tscn`` is more graphically demanding of the GPU than "
"``Ruins_Level.tscn``. If your computer is struggling to render ``Space_Level."
"tscn``, try using ``Ruins_Level.tscn`` instead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:36
msgid ""
"You might have noticed there are several :ref:`RigidBody <class_RigidBody>` "
"nodes placed throughout the level. We can place ``RigidBody_hit_test.gd`` on "
"them and then they will react to being hit with bullets, so let's do that!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:39
msgid ""
"Follow the instructions below for either (or both) of the scenes you want to "
"use"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:75
msgid ""
"Now you can fire at all the rigid bodies in either level and they will react "
"to bullets hitting them!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:78
msgid "Adding ammo"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:80
msgid ""
"Now that the player has working guns, let's give them a limited amount of "
"ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:82
msgid ""
"Firstly, we need to define a few variables in each of our weapon scripts."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:84
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:193
msgid "Open up ``Weapon_Pistol.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:92
msgid "``ammo_in_weapon``: The amount of ammo currently in the pistol"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:93
msgid ""
"``spare_ammo``: The amount of ammo we have left in reserve for the pistol"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:94
msgid "``AMMO_IN_MAG``: The amount of ammo in a fully reloaded weapon/magazine"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:96
msgid "Now all we need to do is add a single line of code to ``fire_weapon``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:98
msgid ""
"Add the following right under ``Clone.BULLET_DAMAGE = DAMAGE``: "
"``ammo_in_weapon -= 1``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:100
msgid ""
"This will remove one from ``ammo_in_weapon`` every time the player fires. "
"Notice we're not checking to see if the player has enough ammo or not in "
"``fire_weapon``. Instead, we're going to check to see if the player has "
"enough ammo in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:105
msgid "Now we need to add ammo for both the rifle and the knife."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:107
msgid ""
"You may be wondering why we are adding ammo for the knife given it does not "
"consume any ammunition. The reason we want to add ammo to the knife is so we "
"have a consistent interface for all our weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:110
msgid ""
"If we did not add ammo variables for the knife, we would have to add checks "
"for the knife. By adding the ammo variables to the knife, we don't need to "
"worry about whether or not all our weapons have the same variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:113
msgid "Add the following class variables to ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:121
msgid ""
"And then add the following to ``fire_weapon``: ``ammo_in_weapon -= 1``. Make "
"sure that ``ammo_in_weapon -= 1`` is outside of the ``if ray."
"is_colliding()`` check so the player loses ammo regardless of whether the "
"player hit something or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:124
msgid ""
"Now all that's left is the knife. Add the following to ``Weapon_Knife.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:132
msgid "Because the knife does not consume ammo, that is all we need to add."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:136
msgid "Now we need to change one thing in ``Player.gd``, that is to say,"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:138
msgid ""
"how we're firing the weapons in ``process_input``. Change the code for "
"firing weapons to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:153
msgid ""
"Now the weapons have a limited amount of ammo, and will stop firing when the "
"player runs out."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:157
msgid ""
"Ideally, we'd like to let the player be able to see how much ammo is left. "
"Let's make a new function called ``process_UI``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:159
msgid "First, add ``process_UI(delta)`` to ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:161
msgid "Now add the following to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:173
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:235
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:216
msgid "Let's go over what's happening:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:175
msgid ""
"Firstly, we check to see if the current weapon is either ``UNARMED`` or "
"``KNIFE``. If it is, we change the ``UI_status_label``'s text to only show "
"the player's health since ``UNARMED`` and ``KNIFE`` do not consume ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:178
msgid ""
"If the player is using a weapon that consumes ammo, we first get the weapon "
"node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:180
msgid ""
"Then we change ``UI_status_label``'s text to show the player's health, along "
"with how much ammo the player has in the weapon and how much spare ammo the "
"player has for that weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:184
msgid "Now we can see how much ammo the player has through the HUD."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:187
msgid "Adding reloading to the weapons"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:189
msgid ""
"Now that the player can run out of ammo, we need a way to let the player "
"fill them back up. Let's add reloading next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:191
msgid ""
"For reloading, we need to add a few more variables and a function to every "
"weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:202
msgid ""
"``CAN_RELOAD``: A boolean to track whether this weapon has the ability to "
"reload"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:203
msgid ""
"``CAN_REFILL``: A boolean to track whether we can refill this weapon's spare "
"ammo. We will not be using ``CAN_REFILL`` in this part, but we will in the "
"next part!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:204
msgid ""
"``RELOADING_ANIM_NAME``: The name of the reloading animation for this weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:206
msgid ""
"Now we need to add a function for handling reloading. Add the following "
"function to ``Weapon_Pistol.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:237
msgid ""
"First we define a variable to see whether or not this weapon can reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:239
msgid ""
"Then we check to see if the player is in this weapon's idle animation state "
"because we only want to be able to reload when the player is not firing, "
"equipping, or unequipping."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:242
msgid ""
"Next we check to see if the player has spare ammo, and if the ammo already "
"in the weapon is equal to a fully reloaded weapon. This way we can ensure "
"the player cannot reload when the player has no ammo or when the weapon is "
"already full of ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:245
msgid ""
"If we can still reload, then we calculate the amount of ammo needed to "
"reload the weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:247
msgid ""
"If the player has enough ammo to fill the weapon, we remove the ammo needed "
"from ``spare_ammo`` and then set ``ammo_in_weapon`` to a full weapon/"
"magazine."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:249
msgid ""
"If the player does not have enough ammo, we add all the ammo left in "
"``spare_ammo``, and then set ``spare_ammo`` to ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:251
msgid ""
"Next we play the reloading animation for this weapon, and then return "
"``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:253
msgid "If the player could not reload, we return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:257
msgid ""
"Now we need to add reloading to the rifle. Open up ``Weapon_Rifle.gd`` and "
"add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:266
msgid ""
"These variables are exactly the same as the pistol, just with "
"``RELOADING_ANIM_NAME`` changed to the rifle's reloading animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:268
msgid "Now we need to add ``reload_weapon`` to ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:297
msgid "This code is exactly the same as the one for the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:301
msgid ""
"The last bit we need to do for the weapons is add 'reloading' to the knife. "
"Add the following class variables to ``Weapon_Knife.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:310
msgid ""
"Since we both cannot reload or refill a knife, we set both constants to "
"``false``. We also define ``RELOADING_ANIM_NAME`` as an empty string, since "
"the knife has no reloading animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:313
msgid "Now we need to add ``reloading_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:320
msgid "Since we cannot reload a knife, we always return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:323
msgid "Adding reloading to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:325
msgid ""
"Now we need to add a few things to ``Player.gd``. First we need to define a "
"new class variable:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:331
msgid ""
"``reloading_weapon``: A variable to track whether or not the player is "
"currently trying to reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:334
msgid "Next we need to add another function call to ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:336
msgid ""
"Add ``process_reloading(delta)`` to ``_physics_process``. Now "
"``_physics_process`` should look something like this:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:347
msgid ""
"Now we need to add ``process_reloading``. Add the following function to "
"``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:358
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:409
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:362
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:424
msgid "Let's go over what's happening here."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:360
msgid "Firstly, we check to make sure the player is trying to reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:362
msgid ""
"If the player is trying to reload, we then get the current weapon. If the "
"current weapon does not equal ``null``, we call its ``reload_weapon`` "
"function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:364
msgid ""
"If the current weapon is equal to ``null``, then the current weapon is "
"``UNARMED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:366
msgid ""
"Finally, we set ``reloading_weapon`` to ``false`` because, regardless of "
"whether the player successfully reloaded, we've tried reloading and no "
"longer need to keep trying."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:371
msgid ""
"Before we can let the player reload, we need to change a few things in "
"``process_input``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:373
msgid ""
"The first thing we need to change is in the code for changing weapons. We "
"need to add an additional check (``if reloading_weapon == false:``) to see "
"if the player is reloading:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:384
msgid ""
"This makes it so the player cannot change weapons if the player is reloading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:386
msgid ""
"Now we need to add the code to trigger a reload when the player pushes the "
"``reload`` action. Add the following code to ``process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:411
msgid ""
"First we make sure the player is not reloading already, nor is the player "
"trying to change weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:413
msgid "Then we check to see if the ``reload`` action has been pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:415
msgid ""
"If the player has pressed ``reload``, we then get the current weapon and "
"check to make sure it is not ``null``. Then we check to see whether the "
"weapon can reload or not using its ``CAN_RELOAD`` constant."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:418
msgid ""
"If the weapon can reload, we then get the current animation state, and make "
"a variable for tracking whether the player is already reloading or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:420
msgid ""
"We then go through every weapon to make sure the player is not already "
"playing that weapon's reloading animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:422
msgid ""
"If the player is not reloading any weapon, we set ``reloading_weapon`` to "
"``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:426
msgid ""
"One thing I like to add is where the weapon will reload itself if you try to "
"fire it and it's out of ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:428
msgid ""
"We also need to add an additional if check (``is_reloading_weapon == false:"
"``) so the player cannot fire the current weapon while reloading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:431
msgid ""
"Let's change our firing code in ``process_input`` so it reloads when trying "
"to fire an empty weapon:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:449
msgid ""
"Now we check to make sure the player is not reloading before we fire the "
"weapon, and when we have ``0`` or less ammo in the current weapon, we set "
"``reloading_weapon`` to ``true`` if the player tries to fire."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:452
msgid ""
"This will make it so the player will try to reload when attempting to fire "
"an empty weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:456
msgid ""
"With that done, the player can now reload! Give it a try! Now you can fire "
"all the spare ammo for each weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:459
msgid "Adding sounds"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:461
msgid ""
"Finally, let's add some sounds that accompany the player firing, reloading "
"and changing weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:463
msgid ""
"There are no game sounds provided in this tutorial (for legal reasons). "
"https://gamesounds.xyz/ is a collection of **\"royalty free or public domain "
"music and sounds suitable for games\"**. I used Gamemaster's Gun Sound Pack, "
"which can be found in the Sonniss.com GDC 2017 Game Audio Bundle."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:467
msgid ""
"Open up ``Simple_Audio_Player.tscn``. It is simply a :ref:`Spatial "
"<class_Spatial>` with an :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` "
"as its child."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:469
msgid ""
"The reason this is called a 'simple' audio player is because we are not "
"taking performance into account and because the code is designed to provide "
"sound in the simplest way possible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:472
msgid ""
"If you want to use 3D audio, so it sounds like it's coming from a location "
"in 3D space, right click the :ref:`AudioStreamPlayer "
"<class_AudioStreamPlayer>` and select \"Change type\"."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:475
msgid ""
"This will open the node browser. Navigate to :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` and select \"change\". In the source for this "
"tutorial, we will be using :ref:`AudioStreamPlayer "
"<class_AudioStreamPlayer>`, but you can optionally use :ref:"
"`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` if you desire, and the "
"code provided below will work regardless of which one you chose."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:480
msgid ""
"Create a new script and call it ``Simple_Audio_Player.gd``. Attach it to "
"the :ref:`Spatial <class_Spatial>` in ``Simple_Audio_Player.tscn`` and "
"insert the following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:532
msgid ""
"By setting ``position`` to ``null`` by default in ``play_sound``, we are "
"making it an optional argument, meaning ``position`` doesn't necessarily "
"have to be passed in to call ``play_sound``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:539
msgid ""
"In ``_ready``, we get the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` "
"and connect its ``finished`` signal to the ``destroy_self`` function. It "
"doesn't matter if it's an :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` "
"or :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node, as they both "
"have the finished signal. To make sure it is not playing any sounds, we call "
"``stop`` on the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:543
msgid ""
"Make sure your sound files are **not** set to loop! If it is set to loop, "
"the sounds will continue to play infinitely and the script will not work!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:546
msgid ""
"The ``play_sound`` function is what we will be calling from ``Player.gd``. "
"We check if the sound is one of the three possible sounds, and if it is one "
"of the three sounds we set the audio stream in :ref:`AudioStreamPlayer "
"<class_AudioStreamPlayer>` to the correct sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:550
msgid ""
"If it is an unknown sound, we print an error message to the console and free "
"the audio player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:552
msgid ""
"If you are using an :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>`, "
"remove the ``#`` to set the position of the audio player node so it plays at "
"the correct position."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:555
msgid ""
"Finally, we tell the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` to "
"play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:557
msgid ""
"When the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` is finished "
"playing the sound, it will call ``destroy_self`` because we connected the "
"``finished`` signal in ``_ready``. We stop the :ref:`AudioStreamPlayer "
"<class_AudioStreamPlayer>` and free the audio player to save on resources."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:561
msgid "This system is extremely simple and has some major flaws:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:563
msgid ""
"One flaw is we have to pass in a string value to play a sound. While it is "
"relatively simple to remember the names of the three sounds, it can be "
"increasingly complex when you have more sounds. Ideally, we'd place these "
"sounds in some sort of container with exposed variables so we do not have to "
"remember the name(s) of each sound effect we want to play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:568
msgid ""
"Another flaw is we cannot play looping sounds effects, nor background music, "
"easily with this system. Because we cannot play looping sounds, certain "
"effects, like footstep sounds, are harder to accomplish because we then have "
"to keep track of whether or not there is a sound effect and whether or not "
"we need to continue playing it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:573
msgid ""
"One of the biggest flaws with this system is we can only play sounds from "
"``Player.gd``. Ideally we'd like to be able to play sounds from any script "
"at any time."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:578
msgid ""
"With that done, let's open up ``Player.gd`` again. First we need to load the "
"``Simple_Audio_Player.tscn``. Place the following code in the class "
"variables section of the script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:585
msgid ""
"Now we need to instance the simple audio player when we need it, and then "
"call its ``play_sound`` function and pass the name of the sound we want to "
"play. To make the process simpler, let's create a ``create_sound`` function "
"in ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:597
msgid "Let's walk through what this function does:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:601
msgid ""
"The first line instances the ``Simple_Audio_Player.tscn`` scene and assigns "
"it to a variable named ``audio_clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:604
msgid ""
"The second line gets the scene root, and this has a large (though safe) "
"assumption."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:606
msgid ""
"We first get this node's :ref:`SceneTree <class_SceneTree>`, and then access "
"the root node, which in this case is the :ref:`Viewport <class_Viewport>` "
"this entire game is running under. Then we get the first child of the :ref:"
"`Viewport <class_Viewport>`, which in our case happens to be the root node "
"in ``Test_Area.tscn`` or any of the other provided levels. **We are making a "
"huge assumption that the first child of the root node is the root scene that "
"the player is under, which may not always be the case**."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:612
msgid ""
"If this doesn't make sense to you, don't worry too much about it. The second "
"line of code only does not work reliably if you have multiple scenes loaded "
"as children of the root node at a time, which will rarely happen for most "
"projects and will not be happening in this tutorial series. This is only "
"potentially a issue depending on how you handle scene loading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:616
msgid ""
"The third line adds our newly created ``Simple_Audio_Player`` scene to be a "
"child of the scene root. This works exactly the same as when we are spawning "
"bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:619
msgid ""
"Finally, we call the ``play_sound`` function and pass in the arguments "
"passed in to ``create_sound``. This will call ``Simple_Audio_Player.gd``'s "
"``play_sound`` function with the passed in arguments."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:624
msgid ""
"Now all that is left is playing the sounds when we want to. Let's add sound "
"to the pistol first!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:626
msgid "Open up ``Weapon_Pistol.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:628
msgid ""
"Now, we want to make a noise when the player fires the pistol, so add the "
"following to the end of the ``fire_weapon`` function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:634
msgid ""
"Now when the player fires the pistol, we'll play the ``Pistol_shot`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:636
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:658
msgid ""
"To make a sound when the player reloads, we need to add the following right "
"under ``player_node.animation_manager.set_animation(RELOADING_ANIM_NAME)`` "
"in the ``reload_weapon`` function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:643
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:665
msgid "Now when the player reloads, we'll play the ``Gun_cock`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:647
msgid "Now let's add sounds to the rifle. Open up ``Weapon_Rifle.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:650
msgid ""
"To play sounds when the rifle is fired, add the following to the end of the "
"``fire_weapon`` function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:656
msgid ""
"Now when the player fires the rifle, we'll play the ``Rifle_shot`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:672
msgid ""
"Now you have weapons with limited ammo that play sounds when you fire them!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:674
msgid ""
"At this point, we have all the basics of an FPS game working. There are "
"still a few things that would be nice to add, and we're going to add them in "
"the next three parts!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:677
msgid ""
"For example, right now we have no way to add ammo to our spares, so we'll "
"eventually run out. Also, we don't have anything to shoot at outside of the :"
"ref:`RigidBody <class_RigidBody>` nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:680
msgid ""
"In :ref:`doc_fps_tutorial_part_four` we'll add some targets to shoot at, "
"along with some health and ammo pick ups! We're also going to add joypad "
"support, so we can play with wired Xbox 360 controllers!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:685
msgid ""
"You can download the finished project for this part here: :download:"
"`Godot_FPS_Part_3.zip <files/Godot_FPS_Part_3.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:4
msgid "Part 4"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:9
msgid ""
"In this part, we will be adding health pickups, ammo pickups, targets the "
"player can destroy, support for joypads, and add the ability to change "
"weapons with the scroll wheel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:13
msgid ""
"You are assumed to have finished :ref:`doc_fps_tutorial_part_three` before "
"moving on to this part of the tutorial. The finished project from :ref:"
"`doc_fps_tutorial_part_three` will be the starting project for part 4"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:19
msgid "Adding joypad input"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:21
msgid ""
"In Godot, any game controller is referred to as a joypad. This includes: "
"Console controllers, Joysticks (like for flight simulators), Wheels (like "
"for driving simulators), VR Controllers, and more!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:24
msgid ""
"Firstly, we need to change a few things in our project's input map. Open up "
"the project settings and select the ``Input Map`` tab."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:26
msgid ""
"Now we need to add some joypad buttons to our various actions. Click the "
"plus icon and select ``Joy Button``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:30
msgid ""
"Feel free to use whatever button layout you want. Make sure that the device "
"selected is set to ``0``. In the finished project, we will be using the "
"following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:32
msgid "movement_sprint: ``Device 0, Button 4 (L, L1)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:33
msgid "fire: ``Device 0, Button 0 (PS Cross, XBox A, Nintendo B)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:34
msgid "reload: ``Device 0, Button 0 (PS Square, XBox X, Nintendo Y)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:35
msgid "flashlight: ``Device 0, Button 12 (D-Pad Up)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:36
msgid "shift_weapon_positive: ``Device 0, Button 15 (D-Pad Right)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:37
msgid "shift_weapon_negative: ``Device 0, Button 14 (D-Pad Left)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:38
msgid "fire_grenade: ``Device 0, Button 1 (PS Circle, XBox B, Nintendo A).``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:40
msgid "These are already set up for you if you downloaded the starter assets"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:42
msgid "Once you are happy with the input, close the project settings and save."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:46
msgid "Now let's open up ``Player.gd`` and add joypad input."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:48
msgid ""
"First, we need to define a few new class variables. Add the following class "
"variables to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:56
msgid "Let's go over what each of these does:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:58
msgid ""
"``JOYPAD_SENSITIVITY``: This is how fast the joypad's joysticks will move "
"the camera."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:59
msgid ""
"``JOYPAD_DEADZONE``: The dead zone for the joypad. You may need to adjust "
"depending on your joypad."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:61
msgid ""
"Many joypads jitter around a certain point. To counter this, we ignore any "
"movement within a radius of JOYPAD_DEADZONE. If we did not ignore said "
"movement, the camera would jitter."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:64
msgid ""
"Also, we are defining ``JOYPAD_SENSITIVITY`` as a variable instead of a "
"constant because we'll later be changing it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:66
msgid "Now we are ready to start handling joypad input!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:70
msgid ""
"In ``process_input``, add the following code just before "
"``input_movement_vector = input_movement_vector.normalized()``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:113
msgid "Let's go over what we're doing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:115
msgid "Firstly, we check to see if there is a connected joypad."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:117
msgid ""
"If there is a joypad connected, we then get its left stick axes for right/"
"left and up/down. Because a wired Xbox 360 controller has different joystick "
"axis mapping based on OS, we will use different axes based on the OS."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:121
msgid ""
"This tutorial assumes you are using a XBox 360 or a PlayStation wired "
"controller. Also, I do not (currently) have access to a Mac computer, so the "
"joystick axes may need changing. If they do, please open a GitHub issue on "
"the Godot documentation repository! Thanks!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:125
msgid ""
"Next, we check to see if the joypad vector length is within the "
"``JOYPAD_DEADZONE`` radius. If it is, we set ``joypad_vec`` to an empty "
"Vector2. If it is not, we use a scaled Radial Dead zone for precise dead "
"zone calculation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:128
msgid ""
"You can find a great article explaining all about how to handle joypad/"
"controller dead zones `here <https://web.archive.org/web/20191208161810/"
"http://www.third-helix.com/2013/04/12/doing-thumbstick-dead-zones-right."
"html>`__."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:131
msgid ""
"We're using a translated version of the scaled radial dead zone code "
"provided in that article. The article is a great read, and I highly suggest "
"giving it a look!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:134
msgid "Finally, we add ``joypad_vec`` to ``input_movement_vector``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:136
msgid ""
"Remember how we normalize ``input_movement_vector``? This is why! If we did "
"not normalize ``input_movement_vector``, the player could move faster if "
"they pushed in the same direction with both the keyboard and the joypad!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:141
msgid ""
"Make a new function called ``process_view_input`` and add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:218
msgid ""
"Firstly, we check the mouse mode. If the mouse mode is not "
"``MOUSE_MODE_CAPTURED``, we want to return, which will skip the code below."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:220
msgid ""
"Next, we define a new :ref:`Vector2 <class_Vector2>` called ``joypad_vec``. "
"This will hold the right joystick position. Based on the OS, we set its "
"values so it is mapped to the proper axes for the right joystick."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:223
msgid ""
"As stated above, I do not (currently) have access to a Mac computer, so the "
"joystick axes may need changing. If they do, please open a GitHub issue on "
"the Godot documentation repository! Thanks!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:226
msgid ""
"We then account for the joypad's dead zone, exactly like in "
"``process_input``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:228
msgid ""
"Then, we rotate ``rotation_helper`` and the player's :ref:`KinematicBody "
"<class_KinematicBody>` using ``joypad_vec``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:230
msgid ""
"Notice how the code that handles rotating the player and ``rotation_helper`` "
"is exactly the same as the code in ``_input``. All we've done is change the "
"values to use ``joypad_vec`` and ``JOYPAD_SENSITIVITY``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:233
msgid ""
"Due to a few mouse-related bugs on Windows, we cannot put mouse rotation in "
"``process_view`` as well. Once these bugs are fixed, this will likely be "
"updated to place the mouse rotation here in ``process_view_input`` as well."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:236
msgid ""
"Finally, we clamp the camera's rotation so the player cannot look upside "
"down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:240
msgid ""
"The last thing we need to do is add ``process_view_input`` to "
"``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:242
msgid ""
"Once ``process_view_input`` is added to ``_physics_process``, you should be "
"able to play using a joypad!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:244
msgid ""
"I decided not to use the joypad triggers for firing because we'd then have "
"to do some more axis managing, and because I prefer to use a shoulder "
"buttons to fire."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:246
msgid ""
"If you want to use the triggers for firing, you will need to change how "
"firing works in ``process_input``. You need to get the axis values for the "
"triggers, and check if it's over a certain value, say ``0.8`` for example. "
"If it is, you add the same code as when the ``fire`` action was pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:250
msgid "Adding mouse scroll wheel input"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:252
msgid ""
"Let's add one more input related feature before we start working on the "
"pickups and the target. Let's add the ability to change weapons using the "
"scroll wheel on the mouse."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:254
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:457
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:526
msgid "Open up ``Player.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:261
msgid "Let's go over what each of these new variables will be doing:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:263
msgid "``mouse_scroll_value``: The value of the mouse scroll wheel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:264
msgid ""
"``MOUSE_SENSITIVITY_SCROLL_WHEEL``: How much a single scroll action "
"increases mouse_scroll_value"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:268
msgid "Now let's add the following to ``_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:292
msgid ""
"Firstly, we check if the event is an ``InputEventMouseButton`` event and "
"that the mouse mode is ``MOUSE_MODE_CAPTURED``. Then, we check to see if the "
"button index is either a ``BUTTON_WHEEL_UP`` or ``BUTTON_WHEEL_DOWN`` index."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:295
msgid ""
"If the event's index is indeed a button wheel index, we then check to see if "
"it is a ``BUTTON_WHEEL_UP`` or ``BUTTON_WHEEL_DOWN`` index. Based on whether "
"it is up or down, we add or subtract ``MOUSE_SENSITIVITY_SCROLL_WHEEL`` to/"
"from ``mouse_scroll_value``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:298
msgid ""
"Next, we clamp mouse scroll value to ensure it is inside the range of "
"selectable weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:300
msgid ""
"We then check to see if the player is changing weapons or reloading. If the "
"player is doing neither, we round ``mouse_scroll_value`` and cast it to an "
"``int``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:302
msgid ""
"We are casting ``mouse_scroll_value`` to an ``int`` so we can use it as a "
"key in our dictionary. If we left it as a float, we would get an error when "
"we tried to run the project."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:305
msgid ""
"Next, we check to see if the weapon name at ``round_mouse_scroll_value`` is "
"not equal to the current weapon name using ``WEAPON_NUMBER_TO_NAME``. If the "
"weapon is different from the player's current weapon, we assign "
"``changing_weapon_name``, set ``changing_weapon`` to ``true`` so the player "
"will change weapons in ``process_changing_weapon``, and set "
"``mouse_scroll_value`` to ``round_mouse_scroll_value``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:309
msgid ""
"The reason we are setting ``mouse_scroll_value`` to the rounded scroll value "
"is because we do not want the player to keep their mouse scroll wheel just "
"in between values, giving them the ability to switch almost extremely fast. "
"By assigning ``mouse_scroll_value`` to ``round_mouse_scroll_value``, we "
"ensure that each weapon takes exactly the same amount of scrolling to change."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:315
msgid ""
"One more thing we need to change is in ``process_input``. In the code for "
"changing weapons, add the following right after the line ``changing_weapon = "
"true``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:321
msgid ""
"Now the scroll value will be changed with the keyboard input. If we did not "
"change this, the scroll value would be out of sync. If the scroll wheel were "
"out of sync, scrolling forwards or backwards would not transition to the "
"next/last weapon, but rather the next/last weapon the scroll wheel changed "
"to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:326
msgid "Now you can change weapons using the scroll wheel! Go give it a whirl!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:329
msgid "Adding the health pickups"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:331
msgid ""
"Now that the player has health and ammo, we ideally need a way to replenish "
"those resources."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:333
msgid "Open up ``Health_Pickup.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:335
msgid ""
"Expand ``Holder`` if it's not already expanded. Notice how we have two "
"Spatial nodes, one called ``Health_Kit`` and another called "
"``Health_Kit_Small``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:337
msgid ""
"This is because we're actually going to be making two sizes of health "
"pickups, one small and one large/normal. ``Health_Kit`` and "
"``Health_Kit_Small`` only have a single :ref:`MeshInstance "
"<class_MeshInstance>` as their children."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:340
msgid ""
"Next expand ``Health_Pickup_Trigger``. This is an :ref:`Area <class_Area>` "
"node we're going to use to check if the player has walked close enough to "
"pick up the health kit. If you expand it, you'll find two collision shapes, "
"one for each size. We will be using a different collision shape size based "
"on the size of the health pickup, so the smaller health pickup has a trigger "
"collision shape closer to its size."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:344
msgid ""
"The last thing to note is how we have an :ref:`AnimationPlayer "
"<class_AnimationPlayer>` node so the health kit bobs and spins around slowly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:346
msgid ""
"Select ``Health_Pickup`` and add a new script called ``Health_Pickup.gd``. "
"Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:405
msgid ""
"Let's go over what this script is doing, starting with its class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:407
msgid ""
"``kit_size``: The size of the health pickup. Notice how we're using a "
"``setget`` function to tell if it's changed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:408
msgid ""
"``HEALTH_AMMOUNTS``: The amount of health each pickup in each size contains."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:409
msgid ""
"``RESPAWN_TIME``: The amount of time, in seconds, it takes for the health "
"pickup to respawn"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:410
msgid ""
"``respawn_timer``: A variable used to track how long the health pickup has "
"been waiting to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:411
msgid ""
"``is_ready``: A variable to track whether the ``_ready`` function has been "
"called or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:413
msgid ""
"We're using ``is_ready`` because ``setget`` functions are called before "
"``_ready``; we need to ignore the first kit_size_change call, because we "
"cannot access child nodes until ``_ready`` is called. If we did not ignore "
"the first ``setget`` call, we would get several errors in the debugger."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:417
msgid ""
"Also, notice how we are using an exported variable. This is so we can change "
"the size of the health pickups in the editor. This makes it so we do not "
"have to make two scenes for the two sizes, since we can easily change sizes "
"in the editor using the exported variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:420
msgid ""
"See :ref:`doc_GDScript` and scroll down to the Exports section for a list of "
"export hints you can use."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:424
msgid "Let's look at ``_ready``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:426
msgid ""
"Firstly, we connect the ``body_entered`` signal from the "
"``Health_Pickup_Trigger`` to the ``trigger_body_entered`` function. This "
"makes it so any body that enters the :ref:`Area <class_Area>` triggers the "
"``trigger_body_entered`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:429
msgid ""
"Next, we set ``is_ready`` to ``true`` so we can use the ``setget`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:431
msgid ""
"Then we hide all the possible kits and their collision shapes using "
"``kit_size_change_values``. The first argument is the size of the kit, while "
"the second argument is whether to enable or disable the collision shape and "
"mesh at that size."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:434
msgid ""
"Then we make only the kit size we selected visible, calling "
"``kit_size_change_values`` and passing in ``kit_size`` and ``true``, so the "
"size at ``kit_size`` is enabled."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:438
msgid "Next let's look at ``kit_size_change``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:440
msgid "The first thing we do is check to see if ``is_ready`` is ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:442
msgid ""
"If ``is_ready`` is ``true``, we then make whatever kit already assigned to "
"``kit_size`` disabled using ``kit_size_change_values``, passing in "
"``kit_size`` and ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:444
msgid ""
"Then we assign ``kit_size`` to the new value passed in, ``value``. Then we "
"call ``kit_size_change_values`` passing in ``kit_size`` again, but this time "
"with the second argument as ``true`` so we enable it. Because we changed "
"``kit_size`` to the passed in value, this will make whatever kit size was "
"passed in visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:447
msgid ""
"If ``is_ready`` is not ``true``, we simply assign ``kit_size`` to the passed "
"in ``value``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:451
msgid "Now let's look at ``kit_size_change_values``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:453
msgid ""
"The first thing we do is check to see which size was passed in. Based on "
"which size we want to enable/disable, we want to get different nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:455
msgid ""
"We get the collision shape for the node corresponding to ``size`` and "
"disable it based on the ``enabled`` passed in argument/variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:457
msgid ""
"Why are we using ``!enable`` instead of ``enable``? This is so when we say "
"we want to enable the node, we can pass in ``true``, but since :ref:"
"`CollisionShape <class_CollisionShape>` uses disabled instead of enabled, we "
"need to flip it. By flipping it, we can enable the collision shape and make "
"the mesh visible when ``true`` is passed in."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:461
msgid ""
"We then get the correct :ref:`Spatial <class_Spatial>` node holding the mesh "
"and set its visibility to ``enable``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:463
msgid ""
"This function may be a little confusing; try to think of it like this: We're "
"enabling/disabling the proper nodes for ``size`` using ``enabled``. This is "
"so we cannot pick up health for a size that is not visible, and so only the "
"mesh for the proper size will be visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:468
msgid "Finally, let's look at ``trigger_body_entered``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:470
msgid ""
"The first thing we do is check whether or not the body that has just entered "
"has a method/function called ``add_health``. If it does, we then call "
"``add_health`` and pass in the health provided by the current kit size."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:473
msgid ""
"Then we set ``respawn_timer`` to ``RESPAWN_TIME`` so the player has to wait "
"before the player can get health again. Finally, call "
"``kit_size_change_values``, passing in ``kit_size`` and ``false`` so the kit "
"at ``kit_size`` is invisible until it has waited long enough to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:478
msgid ""
"The last thing we need to do before the player can use this health pickup is "
"add a few things to ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:480
msgid "Open up ``Player.gd`` and add the following class variable:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:486
msgid "``MAX_HEALTH``: The maximum amount of health a player can have."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:488
msgid ""
"Now we need to add the ``add_health`` function to the player. Add the "
"following to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:496
msgid "Let's quickly go over what this does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:498
msgid ""
"We first add ``additional_health`` to the player's current health. We then "
"clamp the health so that it cannot take on a value higher than "
"``MAX_HEALTH``, nor a value lower than ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:503
msgid ""
"With that done, the player can now collect health! Go place a few "
"``Health_Pickup`` scenes around and give it a try. You can change the size "
"of the health pickup in the editor when a ``Health_Pickup`` instanced scene "
"is selected, from a convenient drop down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:507
msgid "Adding the ammo pickups"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:509
msgid ""
"While adding health is good and all, we can't reap the rewards from adding "
"it since nothing can (currently) damage us. Let's add some ammo pickups next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:512
msgid ""
"Open up ``Ammo_Pickup.tscn``. Notice how it's structured exactly the same as "
"``Health_Pickup.tscn``, but with the meshes and trigger collision shapes "
"changed slightly to account for the difference in mesh sizes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:515
msgid ""
"Select ``Ammo_Pickup`` and add a new script called ``Ammo_Pickup.gd``. Add "
"the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:576
msgid ""
"You may have noticed this code looks almost exactly the same as the health "
"pickup. That's because it largely is the same! Only a few things have been "
"changed, and that's what we're going to go over."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:579
msgid ""
"Firstly, notice the change to ``AMMO_AMOUNTS`` from ``HEALTH_AMMOUNTS``. "
"``AMMO_AMOUNTS`` will be how many ammo clips/magazines the pickup adds to "
"the current weapon. (Unlike in the case of ``HEALTH_AMMOUNTS``, which has "
"stood for how many health points would be awarded, we add an entire clip to "
"the current weapon instead of the raw ammo amount)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:582
msgid ""
"The only other thing to notice is in ``trigger_body_entered``. We're "
"checking for the existence of and calling a function called ``add_ammo`` "
"instead of ``add_health``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:584
msgid ""
"Other than those two small changes, everything else is the same as the "
"health pickup!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:588
msgid ""
"All we need to do to make the ammo pickups work is add a new function to the "
"player. Open ``Player.gd`` and add the following function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:597
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:759
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:941
msgid "Let's go over what this function does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:599
msgid ""
"The first thing we check is whether the player is ``UNARMED``. Because "
"``UNARMED`` does not have a node/script, we want to make sure the player is "
"not ``UNARMED`` before trying to get the node/script attached to "
"``current_weapon_name``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:602
msgid ""
"Next, we check to see if the current weapon can be refilled. If the current "
"weapon can, we add a full clip/magazine worth of ammo to the weapon by "
"multiplying the current weapon's ``AMMO_IN_MAG`` value by however many ammo "
"clips we're adding (``additional_ammo``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:607
msgid ""
"With that done, you should now be able to get additional ammo! Go place some "
"ammo pickups in one/both/all of the scenes and give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:609
msgid ""
"Notice how we're not limiting the amount of ammo you can carry. To limit the "
"amount of ammo each weapon can carry, you need to add an additional variable "
"to each weapon's script, and then clamp the weapon's ``spare_ammo`` variable "
"after adding ammo in ``add_ammo``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:613
msgid "Adding breakable targets"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:615
msgid "Before we end this part, let's add some targets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:617
msgid ""
"Open up ``Target.tscn`` and take a look at the scenes in the scene tree."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:619
msgid ""
"Firstly, notice how we're not using a :ref:`RigidBody <class_RigidBody>` "
"node, but a :ref:`StaticBody <class_StaticBody>` one. The reason behind this "
"is our non-broken targets will not be moving anywhere; using a :ref:"
"`RigidBody <class_RigidBody>` would be more hassle than it's worth since all "
"it has to do is stay still."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:623
msgid ""
"We also save a tiny bit of performance using a :ref:`StaticBody "
"<class_StaticBody>` over a :ref:`RigidBody <class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:625
msgid ""
"The other thing to note is we have a node called ``Broken_Target_Holder``. "
"This node is going to hold a spawned/instanced scene called ``Broken_Target."
"tscn``. Open up ``Broken_Target.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:628
msgid ""
"Notice how the target is broken up into five pieces, each a :ref:`RigidBody "
"<class_RigidBody>` node. We're going to spawn/instance this scene when the "
"target takes too much damage and needs to be destroyed. Then, we're going to "
"hide the non-broken target, so it looks like the target shattered rather "
"than a shattered target was spawned/instanced."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:632
msgid ""
"While you still have ``Broken_Target.tscn`` open, attach "
"``RigidBody_hit_test.gd`` to all of the :ref:`RigidBody <class_RigidBody>` "
"nodes. This will make it so the player can shoot at the broken pieces and "
"they will react to the bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:635
msgid ""
"Alright, now switch back to ``Target.tscn``, select the ``Target`` :ref:"
"`StaticBody <class_StaticBody>` node and create a new script called ``Target."
"gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:637
msgid "Add the following code to ``Target.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:695
msgid "Let's go over what this script does, starting with the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:697
msgid ""
"``TARGET_HEALTH``: The amount of damage needed to break a fully healed "
"target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:698
msgid "``current_health``: The amount of health this target currently has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:699
msgid ""
"``broken_target_holder``: A variable to hold the ``Broken_Target_Holder`` "
"node so we can use it easily."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:700
msgid ""
"``target_collision_shape``: A variable to hold the :ref:`CollisionShape "
"<class_CollisionShape>` for the non-broken target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:701
msgid ""
"``TARGET_RESPAWN_TIME``: The length of time, in seconds, it takes for a "
"target to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:702
msgid ""
"``target_respawn_timer``: A variable to track how long a target has been "
"broken."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:703
msgid ""
"``destroyed_target``: A :ref:`PackedScene <class_PackedScene>` to hold the "
"broken target scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:705
msgid ""
"Notice how we're using an exported variable (a :ref:`PackedScene "
"<class_PackedScene>`) to get the broken target scene instead of using "
"``preload``. By using an exported variable, we can choose the scene from the "
"editor, and if we need to use a different scene, it's as easy as selecting a "
"different scene in the editor; we don't need to go to the code to change the "
"scene we're using."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:711
msgid "Let's look at ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:713
msgid ""
"The first thing we do is get the broken target holder and assign it to "
"``broken_target_holder``. Notice how we're using ``get_parent().get_node()`` "
"here, instead of ``$``. If you wanted to use ``$``, then you'd need to "
"change ``get_parent().get_node()`` to ``$\"../Broken_Target_Holder\"``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:716
msgid ""
"At the time of when this was written, I did not realize you can use ``$\"../"
"NodeName\"`` to get the parent nodes using ``$``, which is why "
"``get_parent().get_node()`` is used instead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:719
msgid ""
"Next, we get the collision shape and assign it to "
"``target_collision_shape``. The reason we need the collision shape is "
"because even when the mesh is invisible, the collision shape will still "
"exist in the physics world. This makes it so the player could interact with "
"a non-broken target even though it's invisible, which is not what we want. "
"To get around this, we will disable/enable the collision shape as we make "
"the mesh visible/invisible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:725
msgid "Next let's look at ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:727
msgid ""
"We're only going to be using ``_physics_process`` for respawning, and so the "
"first thing we do is check to see if ``target_respawn_timer`` is greater "
"than ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:729
msgid "If it is, we then subtract ``delta`` from it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:731
msgid ""
"Then we check to see if ``target_respawn_timer`` is ``0`` or less. The "
"reason behind this is since we just removed ``delta`` from "
"``target_respawn_timer``, if it's ``0`` or less, then the target just got "
"here, effectively allowing us to do whatever we need to do when the timer is "
"finished."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:734
msgid "In this case, we want to respawn the target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:736
msgid ""
"The first thing we do is remove all children in the broken target holder. We "
"do this by iterating over all of the children in ``broken_target_holder`` "
"and free them using ``queue_free``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:738
msgid ""
"Next, we enable the collision shape by setting its ``disabled`` boolean to "
"``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:740
msgid "Then we make the target, and all of its children nodes, visible again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:742
msgid ""
"Finally, we reset the target's health (``current_health``) to "
"``TARGET_HEALTH``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:746
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:903
msgid "Finally, let's look at ``bullet_hit``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:748
msgid ""
"The first thing we do is subtract however much damage the bullet does from "
"the target's health."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:750
msgid ""
"Next we check to see if the target is at ``0`` health or lower. If it is, "
"the target has just died and we need to spawn a broken target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:752
msgid ""
"We first instance a new destroyed target scene, and assign it to a new "
"variable, a ``clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:754
msgid "Next we add the ``clone`` as a child of the broken target holder."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:756
msgid ""
"For bonus effect, we want to make all the target pieces explode outwards. To "
"do this, we iterate over all the children in ``clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:758
msgid ""
"For each child, we first check to see if it's a :ref:`RigidBody "
"<class_RigidBody>` node. If it is, we then calculate the center position of "
"the target relative to the child node. Then we figure out which direction "
"the child node is relative to the center. Using those calculated variables, "
"we push the child from the calculated center, in the direction away from the "
"center, using the damage of the bullet as the force."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:762
msgid ""
"We multiply the damage by ``12`` so it has a more dramatic effect. You can "
"change this to a higher or lower value depending on how explosively you want "
"your targets to shatter."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:765
msgid ""
"Next, we set the target's respawn timer. We set the timer to "
"``TARGET_RESPAWN_TIME``, so it takes ``TARGET_RESPAWN_TIME`` in seconds "
"until it is respawned."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:767
msgid ""
"Then we disable the non-broken target's collision shape, and set the "
"target's visibility to ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:771
msgid ""
"Make sure to set the exported ``destroyed_target`` value for ``Target.tscn`` "
"in the editor! Otherwise the targets will not be destroyed and you will get "
"an error!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:774
msgid ""
"With that done, go place some ``Target.tscn`` instances around in one/both/"
"all of the levels. You should find they explode into five pieces after "
"they've taken enough damage. After a little while, they'll respawn into a "
"whole target again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:782
msgid ""
"Now you can use a joypad, change weapons with the mouse's scroll wheel, "
"replenish your health and ammo, and break targets with your weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:784
msgid ""
"In the next part, :ref:`doc_fps_tutorial_part_five`, we're going to add "
"grenades to our player, give our player the ability to grab and throw "
"objects, and add turrets!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:789
msgid ""
"You can download the finished project for this part here: :download:"
"`Godot_FPS_Part_4.zip <files/Godot_FPS_Part_4.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:4
msgid "Part 5"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:9
msgid ""
"In this part, we're going to add grenades to the player, give the player the "
"ability to grab and throw objects, and add turrets!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:13
msgid ""
"You are assumed to have finished :ref:`doc_fps_tutorial_part_four` before "
"moving on to this part of the tutorial. The finished project from :ref:"
"`doc_fps_tutorial_part_four` will be the starting project for part 5"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:19
msgid "Adding grenades"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:21
msgid ""
"Firstly, let's give the player some grenades to play with. Open up ``Grenade."
"tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:23
msgid ""
"There are a few things to note here, the first and foremost being that the "
"grenades are going to use :ref:`RigidBody <class_RigidBody>` nodes. We're "
"going to use :ref:`RigidBody <class_RigidBody>` nodes for our grenades so "
"they bounce around the world in a (somewhat) realistic manner."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:26
msgid ""
"The second thing to note is ``Blast_Area``. This is an :ref:`Area "
"<class_Area>` node that will represent the blast radius of the grenade."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:28
msgid ""
"Finally, the last thing to note is ``Explosion``. This is the :ref:"
"`Particles <class_Particles>` node that will emit an explosion effect when "
"the grenade explodes. One thing to note here is that we have ``One shot`` "
"enabled. This is so we emit all the particles at once. The particles are "
"also emitted using world coordinates instead of local coordinates, so we "
"have ``Local Coords`` unchecked as well."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:32
msgid ""
"If you want, you can see how the particles are set up by looking through the "
"particle's ``Process Material`` and ``Draw Passes``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:34
msgid ""
"Let's write the code needed for the grenade. Select ``Grenade`` and make a "
"new script called ``Grenade.gd``. Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:90
msgid "Let's go over what's happening, starting with the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:92
msgid ""
"``GRENADE_DAMAGE``: The amount of damage the grenade causes when it explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:93
msgid ""
"``GRENADE_TIME``: The amount of time the grenade takes (in seconds) to "
"explode once it's created/thrown."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:94
msgid ""
"``grenade_timer``: A variable for tracking how long the grenade has been "
"created/thrown."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:95
msgid ""
"``EXPLOSION_WAIT_TIME``: The amount of time needed (in seconds) to wait "
"before we destroy the grenade scene after the explosion"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:96
msgid ""
"``explosion_wait_timer``: A variable for tracking how much time has passed "
"since the grenade exploded."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:97
msgid ""
"``rigid_shape``: The :ref:`CollisionShape <class_CollisionShape>` for the "
"grenade's :ref:`RigidBody <class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:98
msgid ""
"``grenade_mesh``: The :ref:`MeshInstance <class_MeshInstance>` for the "
"grenade."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:99
msgid ""
"``blast_area``: The blast :ref:`Area <class_Area>` used to damage things "
"when the grenade explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:100
msgid ""
"``explosion_particles``: The :ref:`Particles <class_Particles>` that come "
"out when the grenade explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:102
msgid ""
"Notice how ``EXPLOSION_WAIT_TIME`` is a rather strange number (``0.48``). "
"This is because we want ``EXPLOSION_WAIT_TIME`` to be equal to the length of "
"time the explosion particles are emitting, so when the particles are done we "
"destroy/free the grenade. We calculate ``EXPLOSION_WAIT_TIME`` by taking the "
"particle's life time and dividing it by the particle's speed scale. This "
"gets us the exact time the explosion particles will last."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:108
msgid "Now let's turn our attention to ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:110
msgid ""
"First we get all the nodes we'll need and assign them to the proper class "
"variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:112
msgid ""
"We need to get the :ref:`CollisionShape <class_CollisionShape>` and :ref:"
"`MeshInstance <class_MeshInstance>` because similarly to the target in :ref:"
"`doc_fps_tutorial_part_four`, we will be hiding the grenade's mesh and "
"disabling the collision shape when the grenade explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:115
msgid ""
"The reason we need to get the blast :ref:`Area <class_Area>` is so we can "
"damage everything inside it when the grenade explodes. We'll be using code "
"similar to the knife code in the player. We need the :ref:`Particles "
"<class_Particles>` so we can emit particles when the grenade explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:118
msgid ""
"After we get all the nodes and assign them to their class variables, we then "
"make sure the explosion particles are not emitting, and that they are set to "
"emit in one shot. This is to be extra sure the particles will behave the way "
"we expect them to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:123
msgid "Now let's look at ``_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:125
msgid ""
"Firstly, we check to see if the ``grenade_timer`` is less than "
"``GRENADE_TIME``. If it is, we add ``delta`` and return. This is so the "
"grenade has to wait ``GRENADE_TIME`` seconds before exploding, allowing the :"
"ref:`RigidBody <class_RigidBody>` to move around."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:128
msgid ""
"If ``grenade_timer`` is at ``GRENADE_TIMER`` or higher, we then need to "
"check if the grenade has waited long enough and needs to explode. We do this "
"by checking to see if ``explosion_wait_timer`` is equal to ``0`` or less. "
"Since we will be adding ``delta`` to ``explosion_wait_timer`` right after, "
"whatever code under the check will only be called once, right when the "
"grenade has waited long enough and needs to explode."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:132
msgid ""
"If the grenade has waited long enough to explode, we first tell the "
"``explosion_particles`` to emit. Then we make ``grenade_mesh`` invisible, "
"and disable ``rigid_shape``, effectively hiding the grenade."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:135
msgid ""
"We then set the :ref:`RigidBody <class_RigidBody>`'s mode to ``MODE_STATIC`` "
"so the grenade does not move."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:137
msgid ""
"Then we get all the bodies in ``blast_area``, check to see if they have the "
"``bullet_hit`` method/function, and if they do, we call it and pass in "
"``GRENADE_DAMAGE`` and the transform from the body looking at the grenade. "
"This makes it where the bodies exploded by the grenade will explode outwards "
"from the grenade's position."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:140
msgid ""
"We then check to see if ``explosion_wait_timer`` is less than "
"``EXPLOSION_WAIT_TIME``. If it is, we add ``delta`` to "
"``explosion_wait_timer``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:142
msgid ""
"Next, we check to see if ``explosion_wait_timer`` is greater than or equal "
"to ``EXPLOSION_WAIT_TIME``. Because we added ``delta``, this will only be "
"called once. If ``explosion_wait_timer`` is greater or equal to "
"``EXPLOSION_WAIT_TIME``, the grenade has waited long enough to let the :ref:"
"`Particles <class_Particles>` play and we can free/destroy the grenade, as "
"we no longer need it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:148
msgid ""
"Let's quickly get the sticky grenade set up too. Open up ``Sticky_Grenade."
"tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:150
msgid ""
"``Sticky_Grenade.tscn`` is almost identical to ``Grenade.tscn``, with one "
"small addition. We now have a second :ref:`Area <class_Area>`, called "
"``Sticky_Area``. We will be using ``Stick_Area`` to detect when the sticky "
"grenade has collided with the environment and needs to stick to something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:154
msgid ""
"Select ``Sticky_Grenade`` and make a new script called ``Sticky_Grenade."
"gd``. Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:244
msgid ""
"The code above is almost identical to the code for ``Grenade.gd``, so let's "
"just go over what's changed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:246
msgid "Firstly, we have a few more class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:248
msgid ""
"``attached``: A variable for tracking whether or not the sticky grenade has "
"attached to a :ref:`PhysicsBody <class_PhysicsBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:249
msgid ""
"``attach_point``: A variable to hold a :ref:`Spatial <class_Spatial>` that "
"will be at the position where the sticky grenade collided."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:250
msgid ""
"``player_body``: The player's :ref:`KinematicBody <class_KinematicBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:252
msgid ""
"They have been added to enable the sticky grenade to stick to any :ref:"
"`PhysicsBody <class_PhysicsBody>` it might hit. We also now need the "
"player's :ref:`KinematicBody <class_KinematicBody>` so the sticky grenade "
"does not stick to the player when the player throws it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:257
msgid ""
"Now let's look at the small change in ``_ready``. In ``_ready`` we've added "
"a line of code so when any body enters ``Stick_Area``, the "
"``collided_with_body`` function is called."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:262
msgid "Next let's take a look at ``collided_with_body``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:264
msgid ""
"Firstly, we make sure the sticky grenade is not colliding with itself. "
"Because the sticky :ref:`Area <class_Area>` does not know it's attached to "
"the grenade's :ref:`RigidBody <class_RigidBody>`, we need to make sure it's "
"not going to stick to itself by checking to make sure the body it has "
"collided with is not itself. If we have collided with ourself, we ignore it "
"by returning."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:269
msgid ""
"We then check to see if we have something assigned to ``player_body``, and "
"if the body the sticky grenade has collided with is the player that threw "
"it. If the body the sticky grenade has collided with is indeed "
"``player_body``, we ignore it by returning."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:272
msgid ""
"Next, we check if the sticky grenade has attached to something already or "
"not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:274
msgid ""
"If the sticky grenade is not attached, we then set ``attached`` to ``true`` "
"so we know the sticky grenade has attached to something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:276
msgid ""
"We then make a new :ref:`Spatial <class_Spatial>` node, and make it a child "
"of the body the sticky grenade collided with. We then set the :ref:`Spatial "
"<class_Spatial>`'s position to the sticky grenade's current global position."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:279
msgid ""
"Because we've added the :ref:`Spatial <class_Spatial>` as a child of the "
"body the sticky grenade has collided with, it will follow along with said "
"body. We can then use this :ref:`Spatial <class_Spatial>` to set the sticky "
"grenade's position, so it is always at the same position relative to the "
"body it collided with."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:282
msgid ""
"We then disable ``rigid_shape`` so the sticky grenade is not constantly "
"moving whatever body it has collided with. Finally, we set our mode to "
"``MODE_STATIC`` so the grenade does not move."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:287
msgid "Finally, lets go over the few changes in ``_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:289
msgid ""
"Now we're checking to see if the sticky grenade is attached right at the top "
"of ``_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:291
msgid ""
"If the sticky grenade is attached, we then make sure the attached point is "
"not equal to ``null``. If the attached point is not equal to ``null``, we "
"set the sticky grenade's global position (using its global :ref:`Transform "
"<class_Transform>`'s origin) to the global position of the :ref:`Spatial "
"<class_Spatial>` assigned to ``attach_point`` (using its global :ref:"
"`Transform <class_Transform>`'s origin)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:295
msgid ""
"The only other change is now before we free/destroy the sticky grenade is to "
"check to see if the sticky grenade has an attached point. If it does, we "
"also call ``queue_free`` on the attach point, so it's also freed/destroyed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:299
msgid "Adding grenades to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:301
msgid ""
"Now we need to add some code to ``Player.gd`` so we can use the grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:303
msgid ""
"Firstly, open up ``Player.tscn`` and expand the node tree until you get to "
"``Rotation_Helper``. Notice how in ``Rotation_Helper`` we have a node called "
"``Grenade_Toss_Pos``. This is where we will be spawning the grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:306
msgid ""
"Also notice how it's slightly rotated on the ``X`` axis, so it's not "
"pointing straight, but rather slightly up. By changing the rotation of "
"``Grenade_Toss_Pos``, you can change the angle at which the grenades are "
"tossed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:309
msgid ""
"Okay, now let's start making the grenades work with the player. Add the "
"following class variables to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:319
msgid ""
"``grenade_amounts``: The amount of grenades the player is currently carrying "
"(for each type of grenade)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:320
msgid ""
"``current_grenade``: The name of the grenade the player is currently using."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:321
msgid "``grenade_scene``: The grenade scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:322
msgid ""
"``sticky_grenade_scene``: The sticky grenade scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:323
msgid ""
"``GRENADE_THROW_FORCE``: The force at which the player will throw the "
"grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:325
msgid "Most of these variables are similar to how we have our weapons set up."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:327
msgid ""
"While it's possible to make a more modular grenade system, I found it was "
"not worth the additional complexity for just two grenades. If you were going "
"to make a more complex FPS with more grenades, you'd likely want to make a "
"system for grenades similar to how we have the weapons set up."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:332
msgid ""
"Now we need to add some code in ``_process_input`` Add the following to "
"``_process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:364
msgid ""
"Firstly, we check to see if the ``change_grenade`` action has just been "
"pressed. If it has, we then check to see which grenade the player is "
"currently using. Based on the name of the grenade the player is currently "
"using, we change ``current_grenade`` to the opposite grenade name."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:367
msgid ""
"Next we check to see if the ``fire_grenade`` action has just been pressed. "
"If it has, we then check to see if the player has more than ``0`` grenades "
"for the current grenade type selected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:370
msgid ""
"If the player has more than ``0`` grenades, we then remove one from the "
"grenade amounts for the current grenade. Then, based on the grenade the "
"player is currently using, we instance the proper grenade scene and assign "
"it to ``grenade_clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:373
msgid ""
"Next we add ``grenade_clone`` as a child of the node at the root and set its "
"global :ref:`Transform <class_Transform>` to ``Grenade_Toss_Pos``'s global :"
"ref:`Transform <class_Transform>`. Finally, we apply an impulse to the "
"grenade so that it is launched forward, relative to the ``Z`` directional "
"vector of ``grenade_clone``'s."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:379
msgid ""
"Now the player can use both types of grenades, but there are still a few "
"things we should probably add before we move on to adding the other things."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:381
msgid ""
"We still need a way to show the player how many grenades are left, and we "
"should probably add a way to get more grenades when the player picks up ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:383
msgid ""
"Firstly, let's change some of the code in ``Player.gd`` to show how many "
"grenades are left. Change ``process_UI`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:399
msgid "Now we'll show how many grenades the player has left in the UI."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:401
msgid ""
"While we're still in ``Player.gd``, let's add a function to add grenades to "
"the player. Add the following function to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:409
msgid ""
"Now we can add a grenade using ``add_grenade``, and it will automatically be "
"clamped to a maximum of ``4`` grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:411
msgid ""
"You can change the ``4`` to a constant if you want. You'd need to make a new "
"global constant, something like ``MAX_GRENADES``, and then change the clamp "
"from ``clamp(grenade_amounts[current_grenade], 0, 4)`` to "
"``clamp(grenade_amounts[current_grenade], 0, MAX_GRENADES)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:414
msgid ""
"If you do not want to limit how many grenades the player can carry, remove "
"the line that clamps the grenades altogether!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:416
msgid ""
"Now we have a function to add grenades, let's open up ``AmmoPickup.gd`` and "
"use it!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:418
msgid ""
"Open up ``AmmoPickup.gd`` and go to the ``trigger_body_entered`` function. "
"Change it to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:433
msgid ""
"Now we are also checking to see if the body has the ``add_grenade`` "
"function. If it does, we call it like we call ``add_ammo``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:435
msgid ""
"You may have noticed we are using a new constant we have not defined yet, "
"``GRENADE_AMOUNTS``. Let's add it! Add the following class variable to "
"``AmmoPickup.gd`` with the other class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:442
msgid "``GRENADE_AMOUNTS``: The amount of grenades each pickup contains."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:444
msgid ""
"Notice how the second element in ``GRENADE_AMOUNTS`` is ``0``. This is so "
"the small ammo pickup does not give the player any additional grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:449
msgid "Now you should be able to throw grenades! Go give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:453
msgid "Adding the ability to grab and throw RigidBody nodes to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:455
msgid ""
"Next, let's give the player the ability to pick up and throw :ref:`RigidBody "
"<class_RigidBody>` nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:466
msgid ""
"``grabbed_object``: A variable to hold the grabbed :ref:`RigidBody "
"<class_RigidBody>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:467
msgid ""
"``OBJECT_THROW_FORCE``: The force with which the player throws the grabbed "
"object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:468
msgid ""
"``OBJECT_GRAB_DISTANCE``: The distance away from the camera at which the "
"player holds the grabbed object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:469
msgid ""
"``OBJECT_GRAB_RAY_DISTANCE``: The distance the :ref:`Raycast "
"<class_Raycast>` goes. This is the player's grab distance."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:471
msgid ""
"With that done, all we need to do is add some code to ``process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:509
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:354
msgid "Let's go over what's happening."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:511
msgid ""
"Firstly, we check to see if the action pressed is the ``fire`` action, and "
"that the player is using the ``UNARMED`` 'weapon'. This is because we only "
"want the player to be able to pick up and throw objects when the player is "
"not using any weapons. This is a design choice, but I feel it gives "
"``UNARMED`` a use."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:515
msgid "Next we check to see whether or not ``grabbed_object`` is ``null``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:519
msgid ""
"If ``grabbed_object`` is ``null``, we want to see if we can pick up a :ref:"
"`RigidBody <class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:521
msgid ""
"We first get the direct space state from the current :ref:`World "
"<class_World>`. This is so we can cast a ray entirely from code, instead of "
"having to use a :ref:`Raycast <class_Raycast>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:524
msgid ""
"see :ref:`Ray-casting <doc_ray-casting>` for more information on raycasting "
"in Godot."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:526
msgid ""
"Then we get the center of the screen by dividing the current :ref:`Viewport "
"<class_Viewport>` size in half. We then get the ray's origin point and end "
"point using ``project_ray_origin`` and ``project_ray_normal`` from the "
"camera. If you want to know more about how these functions work, see :ref:"
"`Ray-casting <doc_ray-casting>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:529
msgid ""
"Next we send the ray into the space state and see if it gets a result. We "
"add the player and the knife's :ref:`Area <class_Area>` as two exceptions so "
"the player cannot carry themselves or the knife's collision :ref:`Area "
"<class_Area>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:532
msgid ""
"Then we check to see if we got a result back from the ray. If no object has "
"collided with the ray, an empty Dictionary will be returned. If the "
"Dictionary is not empty (i.e. at least one object has collided), we then see "
"if the collider the ray collided with is a :ref:`RigidBody "
"<class_RigidBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:534
msgid ""
"If the ray collided with a :ref:`RigidBody <class_RigidBody>`, we set "
"``grabbed_object`` to the collider the ray collided with. We then set the "
"mode on the :ref:`RigidBody <class_RigidBody>` we collided with to "
"``MODE_STATIC`` so it doesn't move in our hands."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:537
msgid ""
"Finally, we set the grabbed :ref:`RigidBody <class_RigidBody>`'s collision "
"layer and collision mask to ``0``. This will make the grabbed :ref:"
"`RigidBody <class_RigidBody>` have no collision layer or mask, which means "
"it will not be able to collide with anything as long as we are holding it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:542
msgid ""
"If ``grabbed_object`` is not ``null``, then we need to throw the :ref:"
"`RigidBody <class_RigidBody>` the player is holding."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:544
msgid ""
"We first set the mode of the :ref:`RigidBody <class_RigidBody>` we are "
"holding to ``MODE_RIGID``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:546
msgid ""
"This is making a rather large assumption that all the rigid bodies will be "
"using ``MODE_RIGID``. While that is the case for this tutorial series, that "
"may not be the case in other projects."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:549
msgid ""
"If you have rigid bodies with different modes, you may need to store the "
"mode of the :ref:`RigidBody <class_RigidBody>` you have picked up into a "
"class variable so you can change it back to the mode it was in before you "
"picked it up."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:552
msgid ""
"Then we apply an impulse to send it flying forward. We send it flying in the "
"direction the camera is facing, using the force we set in the "
"``OBJECT_THROW_FORCE`` variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:554
msgid ""
"We then set the grabbed :ref:`RigidBody <class_RigidBody>`'s collision layer "
"and mask to ``1``, so it can collide with anything on layer ``1`` again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:556
msgid ""
"This is, once again, making a rather large assumption that all the rigid "
"bodies will be only on collision layer ``1``, and all collision masks will "
"be on layer ``1``. If you are using this script in other projects, you may "
"need to store the collision layer/mask of the :ref:`RigidBody "
"<class_RigidBody>` in a variable before you change them to ``0``, so you "
"would have the original collision layer/mask to set for them when you are "
"reversing the process."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:559
msgid ""
"Finally, we set ``grabbed_object`` to ``null`` since the player has "
"successfully thrown the held object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:563
msgid ""
"The last thing we do is check to see whether or not ``grabbed_object`` is "
"equal to ``null``, outside all of the grabbing/throwing related code."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:565
msgid ""
"While technically not input related, it's easy enough to place the code "
"moving the grabbed object here because it's only two lines, and then all of "
"the grabbing/throwing code is in one place"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:568
msgid ""
"If the player is holding an object, we set its global position to the "
"camera's position plus ``OBJECT_GRAB_DISTANCE`` in the direction the camera "
"is facing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:572
msgid ""
"Before we test this, we need to change something in ``_physics_process``. "
"While the player is holding an object, we do not want the player to be able "
"to change weapons or reload, so change ``_physics_process`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:589
msgid "Now the player cannot change weapons or reload while holding an object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:591
msgid ""
"Now you can grab and throw RigidBody nodes while you're in the ``UNARMED`` "
"state! Go give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:594
msgid "Adding a turret"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:596
msgid "Next, let's make a turret to shoot the player!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:598
msgid ""
"Open up ``Turret.tscn``. Expand ``Turret`` if it's not already expanded."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:600
msgid ""
"Notice how the turret is broken up into several parts: ``Base``, ``Head``, "
"``Vision_Area``, and a ``Smoke`` :ref:`Particles <class_Particles>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:602
msgid ""
"Open up ``Base`` and you'll find it's a :ref:`StaticBody <class_StaticBody>` "
"and a mesh. Open up ``Head`` and you'll find there are several meshes, a :"
"ref:`StaticBody <class_StaticBody>` and a :ref:`Raycast <class_Raycast>` "
"node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:605
msgid ""
"One thing to note with the ``Head`` is that the raycast will be where the "
"turret's bullets will fire from if we are using raycasting. We also have two "
"meshes called ``Flash`` and ``Flash_2``. These will be the muzzle flash that "
"briefly shows when the turret fires."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:608
msgid ""
"``Vision_Area`` is an :ref:`Area <class_Area>` we'll use as the turret's "
"ability to see. When something enters ``Vision_Area``, we'll assume the "
"turret can see it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:610
msgid ""
"``Smoke`` is a :ref:`Particles <class_Particles>` node that will play when "
"the turret is destroyed and repairing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:614
msgid ""
"Now that we've looked at how the scene is set up, lets start writing the "
"code for the turret. Select ``Turret`` and create a new script called "
"``Turret.gd``. Add the following to ``Turret.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:780
msgid ""
"This is quite a bit of code, so let's break it down function by function. "
"Let's first look at the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:782
msgid ""
"``use_raycast``: An exported boolean so we can change whether the turret "
"uses objects or raycasting for bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:783
msgid ""
"``TURRET_DAMAGE_BULLET``: The amount of damage a single bullet scene does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:784
msgid ""
"``TURRET_DAMAGE_RAYCAST``: The amount of damage a single :ref:`Raycast "
"<class_Raycast>` bullet does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:785
msgid ""
"``FLASH_TIME``: The amount of time (in seconds) the muzzle flash meshes are "
"visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:786
msgid ""
"``flash_timer``: A variable for tracking how long the muzzle flash meshes "
"have been visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:787
msgid "``FIRE_TIME``: The amount of time (in seconds) needed to fire a bullet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:788
msgid ""
"``fire_timer``: A variable for tracking how much time has passed since the "
"turret last fired."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:789
msgid "``node_turret_head``: A variable to hold the ``Head`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:790
msgid ""
"``node_raycast``: A variable to hold the :ref:`Raycast <class_Raycast>` node "
"attached to the turret's head."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:791
msgid ""
"``node_flash_one``: A variable to hold the first muzzle flash :ref:"
"`MeshInstance <class_MeshInstance>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:792
msgid ""
"``node_flash_two``: A variable to hold the second muzzle flash :ref:"
"`MeshInstance <class_MeshInstance>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:793
msgid "``ammo_in_turret``: The amount of ammo currently in the turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:794
msgid "``AMMO_IN_FULL_TURRET``: The amount of ammo in a full turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:795
msgid "``AMMO_RELOAD_TIME``: The amount of time it takes the turret to reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:796
msgid ""
"``ammo_reload_timer``: A variable for tracking how long the turret has been "
"reloading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:797
msgid "``current_target``: The turret's current target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:798
msgid ""
"``is_active``: A variable for tracking whether the turret is able to fire at "
"the target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:799
msgid ""
"``PLAYER_HEIGHT``: The amount of height we're adding to the target so we're "
"not shooting at its feet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:800
msgid "``smoke_particles``: A variable to hold the smoke particles node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:801
msgid "``turret_health``: The amount of health the turret currently has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:802
msgid "``MAX_TURRET_HEALTH``: The amount of health a fully healed turret has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:803
msgid ""
"``DESTROYED_TIME``: The amount of time (in seconds) it takes for a destroyed "
"turret to repair itself."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:804
msgid ""
"``destroyed_timer``: A variable for tracking the amount of time a turret has "
"been destroyed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:805
msgid ""
"``bullet_scene``: The bullet scene the turret fires (same scene as the "
"player's pistol)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:807
msgid "Whew, that's quite a few class variables!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:811
msgid "Let's go through ``_ready`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:813
msgid ""
"Firstly, we get the vision area and connect the ``body_entered`` and "
"``body_exited`` signals to ``body_entered_vision`` and "
"``body_exited_vision``, respectively."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:815
msgid ""
"We then get all the nodes and assign them to their respective variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:817
msgid ""
"Next, we add some exceptions to the :ref:`Raycast <class_Raycast>` so the "
"turret cannot hurt itself."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:819
msgid ""
"Then we make both flash meshes invisible at start, since we are not going to "
"be firing during ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:821
msgid ""
"We then get the smoke particles node and assign it to the "
"``smoke_particles`` variable. We also set ``emitting`` to ``false`` to "
"ensure the particles are not emitting until the turret is broken."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:824
msgid ""
"Finally, we set the turret's health to ``MAX_TURRET_HEALTH`` so it starts at "
"full health."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:828
msgid "Now let's go through ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:830
msgid ""
"Firstly, we check whether the turret is active. If the turret is active, we "
"want to process the firing code."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:832
msgid ""
"Next, if ``flash_timer`` is greater than zero, meaning the flash meshes are "
"visible, we want to remove delta from ``flash_timer``. If ``flash_timer`` "
"gets to zero or less after we've subtracted ``delta``, we want to hide both "
"of the flash meshes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:836
msgid ""
"Next, we check whether the turret has a target. If the turret has a target, "
"we make the turret head look at it, adding ``PLAYER_HEIGHT`` so it is not "
"aiming at the player's feet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:839
msgid ""
"We then check whether the turret's health is greater than zero. If it is, we "
"then check whether there is ammo in the turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:841
msgid ""
"If there is, we then check whether ``fire_timer`` is greater than zero. If "
"it is, the turret cannot fire and we need to remove ``delta`` from "
"``fire_timer``. If ``fire_timer`` is less than or equal to zero, the turret "
"can fire a bullet, so we call the ``fire_bullet`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:844
msgid ""
"If there isn't any ammo in the turret, we check whether "
"``ammo_reload_timer`` is greater than zero. If it is, we subtract ``delta`` "
"from ``ammo_reload_timer``. If ``ammo_reload_timer`` is less than or equal "
"to zero, we set ``ammo_in_turret`` to ``AMMO_IN_FULL_TURRET`` because the "
"turret has waited long enough to refill its ammo."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:848
msgid ""
"Next, we check whether the turret's health is less than or equal to ``0`` "
"outside of whether it is active or not. If the turret's health is zero or "
"less, we then check whether ``destroyed_timer`` is greater than zero. If it "
"is, we subtract ``delta`` from ``destroyed_timer``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:851
msgid ""
"If ``destroyed_timer`` is less than or equal to zero, we set "
"``turret_health`` to ``MAX_TURRET_HEALTH`` and stop emitting smoke particles "
"by setting ``smoke_particles.emitting`` to ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:856
msgid "Next let's go through ``fire_bullet``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:858
msgid "Firstly, we check whether the turret is using a raycast."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:860
msgid ""
"The code for using a raycast is almost entirely the same as the code in the "
"rifle from :ref:`doc_fps_tutorial_part_two`, so I'm only going to go over it "
"briefly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:863
msgid ""
"We first make the raycast look at the target, ensuring the raycast will hit "
"the target if nothing is in the way. We then force the raycast to update so "
"we get a frame perfect collision check. We then check whether the raycast "
"has collided with anything. If it has, we then check whether the collided "
"body has the ``bullet_hit`` method. If it does, we call it and pass in the "
"damage a single raycast bullet does along with the raycast's transform. We "
"then subtract ``1`` from ``ammo_in_turret``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:868
msgid ""
"If the turret is not using a raycast, we spawn a bullet object instead. This "
"code is almost entirely the same as the code in the pistol from :ref:"
"`doc_fps_tutorial_part_two`, so like with the raycast code, I'm only going "
"to go over it briefly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:871
msgid ""
"We first make a bullet clone and assign it to ``clone``. We then add that as "
"a child of the root node. We set the bullet's global transform to the barrel "
"end, scale it up since it's too small, and set its damage and speed using "
"the turret's constant class variables. We then subtract ``1`` from "
"``ammo_in_turret``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:875
msgid ""
"Then, regardless of which bullet method we used, we make both of the muzzle "
"flash meshes visible. We set ``flash_timer`` and ``fire_timer`` to "
"``FLASH_TIME`` and ``FIRE_TIME``, respectively. We then check whether the "
"turret has used the last bullet in its ammo. If it has, we set "
"``ammo_reload_timer`` to ``AMMO_RELOAD_TIME`` so the turret reloads."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:881
msgid ""
"Let's look at ``body_entered_vision`` next, and thankfully it is rather "
"short."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:883
msgid ""
"We first check whether the turret currently has a target by checking if "
"``current_target`` is equal to ``null``. If the turret does not have a "
"target, we then check whether the body that has just entered the vision :ref:"
"`Area <class_Area>` is a :ref:`KinematicBody <class_KinematicBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:886
msgid ""
"We're assuming the turret should only fire at :ref:`KinematicBody "
"<class_KinematicBody>` nodes since that is what the player is using."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:888
msgid ""
"If the body that just entered the vision :ref:`Area <class_Area>` is a :ref:"
"`KinematicBody <class_KinematicBody>`, we set ``current_target`` to the "
"body, and set ``is_active`` to ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:893
msgid "Now let's look at ``body_exited_vision``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:895
msgid ""
"Firstly, we check whether the turret has a target. If it does, we then check "
"whether the body that has just left the turret's vision :ref:`Area "
"<class_Area>` is the turret's target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:898
msgid ""
"If the body that has just left the vision :ref:`Area <class_Area>` is the "
"turret's current target, we set ``current_target`` to ``null``, set "
"``is_active`` to ``false``, and reset all the variables related to firing "
"the turret since the turret no longer has a target to fire at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:905
msgid ""
"We first subtract however much damage the bullet causes from the turret's "
"health."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:907
msgid ""
"Then, we check whether the turret has been destroyed (health being zero or "
"less). If the turret is destroyed, we start emitting the smoke particles and "
"set ``destroyed_timer`` to ``DESTROYED_TIME`` so the turret has to wait "
"before being repaired."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:912
msgid ""
"Whew, with all of that done and coded, we only have one last thing to do "
"before the turret is ready for use. Open up ``Turret.tscn`` if it's not "
"already open and select one of the :ref:`StaticBody <class_StaticBody>` "
"nodes from either ``Base`` or ``Head``. Create a new script called "
"``TurretBodies.gd`` and attach it to whichever :ref:`StaticBody "
"<class_StaticBody>` you have selected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:916
msgid "Add the following code to ``TurretBodies.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:931
msgid ""
"All this code does is call ``bullet_hit`` on whatever node to which "
"``path_to_turret_root`` leads. Go back to the editor and assign the :ref:"
"`NodePath <class_NodePath>` to the ``Turret`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:934
msgid ""
"Now select the other :ref:`StaticBody <class_StaticBody>` node (either in "
"``Body`` or ``Head``) and assign ``TurretBodies.gd`` script to it. Once the "
"script is attached, assign again the :ref:`NodePath <class_NodePath>` to the "
"``Turret`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:939
msgid ""
"The last thing we need to do is add a way for the player to be hurt. Since "
"all the bullets use the ``bullet_hit`` function, we need to add that "
"function to the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:941
msgid "Open ``Player.gd`` and add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:948
msgid ""
"With all that done, you should have fully operational turrets! Go place a "
"few in one/both/all of the scenes and give them a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:955
msgid ""
"Now you can pick up :ref:`RigidBody <class_RigidBody>` nodes and throw "
"grenades. We now also have turrets to fire at the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:957
msgid ""
"In :ref:`doc_fps_tutorial_part_six`, we're going to add a main menu and a "
"pause menu, add a respawn system for the player, and change/move the sound "
"system so we can use it from any script."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:962
msgid ""
"You can download the finished project for this part here: :download:"
"`Godot_FPS_Part_5.zip <files/Godot_FPS_Part_5.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:4
msgid "Part 6"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:9
msgid ""
"In this part, we're going to add a main menu and pause menu, add a respawn "
"system for the player, and change/move the sound system so we can use it "
"from any script."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:12
msgid ""
"This is the last part of the FPS tutorial; by the end of this, you will have "
"a solid base to build amazing FPS games with Godot!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:16
msgid ""
"You are assumed to have finished :ref:`doc_fps_tutorial_part_five` before "
"moving on to this part of the tutorial. The finished project from :ref:"
"`doc_fps_tutorial_part_five` will be the starting project for part 6"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:22
msgid "Adding the main menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:24
msgid ""
"Firstly, open up ``Main_Menu.tscn`` and take a look at how the scene is set "
"up."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:26
msgid ""
"The main menu is broken up into three different panels, each representing a "
"different 'screen' of our main menu."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:29
msgid ""
"The ``Background_Animation`` node is just so the background of the menu is a "
"bit more interesting than a solid color. It's a camera looking around the "
"skybox, nothing fancy."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:32
msgid ""
"Feel free to expand all the nodes and see how they're set up. Remember to "
"keep only ``Start_Menu`` visible when you're done, as that's the screen we "
"want to show first when we enter the main menu."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:35
msgid ""
"Select ``Main_Menu`` (the root node) and create a new script called "
"``Main_Menu.gd``. Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:122
msgid ""
"Most of the code here relates to making UIs, which is outside of the purpose "
"of this tutorial series. **We're only going to look at the UI related code "
"briefly.**"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:125
msgid ""
"See :ref:`doc_ui_main_menu` and the tutorials following for better ways to "
"make GUIs and UIs!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:127
msgid "Let's look at the class variables first."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:129
msgid ""
"``start_menu``: A variable to hold the ``Start_Menu`` :ref:`Panel "
"<class_Panel>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:130
msgid ""
"``level_select_menu``: A variable to hold the ``Level_Select_Menu`` :ref:"
"`Panel <class_Panel>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:131
msgid ""
"``options_menu``: A variable to hold the ``Options_Menu`` :ref:`Panel "
"<class_Panel>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:132
msgid ""
"``testing_area_scene``: The path to the ``Testing_Area.tscn`` file, so we "
"can change to it from this scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:133
msgid ""
"``space_level_scene``: The path to the ``Space_Level.tscn`` file, so we can "
"change to it from this scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:134
msgid ""
"``ruins_level_scene``: The path to the ``Ruins_Level.tscn`` file, so we can "
"change to it from this scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:136
msgid ""
"You'll have to set the paths to the correct files in the editor before "
"testing this script! Otherwise it will not work!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:140
msgid "Now let's go over ``_ready``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:142
msgid ""
"Firstly, we get all the :ref:`Panel <class_Panel>` nodes and assign them to "
"the proper variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:144
msgid ""
"Next, we connect all the buttons ``pressed`` signals to their respective "
"``[panel_name_here]_button_pressed`` functions."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:146
msgid ""
"We then set the mouse mode to ``MOUSE_MODE_VISIBLE`` to ensure whenever the "
"player returns to this scene, the mouse will be visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:148
msgid ""
"Then we get a singleton, called ``Globals``. We then set the values for the :"
"ref:`HSlider <class_HSlider>` nodes so their values line up with the mouse "
"and joypad sensitivity in the singleton."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:151
msgid ""
"We have not made the ``Globals`` singleton yet, so don't worry! We're going "
"to make it soon!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:155
msgid ""
"In ``start_menu_button_pressed``, we check to see which button is pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:157
msgid ""
"Based on the button pressed, we either change the currently visible panel, "
"quit the application, or open the Godot website."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:161
msgid ""
"In ``level_select_menu_button_pressed``, we check to see which button is "
"pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:163
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:175
msgid ""
"If the ``back`` button has been pressed, we change the currently visible "
"panels to return to the main menu."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:165
msgid ""
"If one of the scene changing buttons is pressed, we fist call "
"``set_mouse_and_joypad_sensitivity`` so the singleton (``Globals.gd``) has "
"the values from the :ref:`HSlider <class_HSlider>` nodes. Then, we tell the "
"singleton to change nodes using its ``load_new_scene`` function, passing in "
"the file path of the scene the player has selected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:169
msgid "Don't worry about the singleton, we'll get there soon!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:173
msgid ""
"In ``options_menu_button_pressed``, we check to see which button is pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:177
msgid ""
"If the ``fullscreen`` button is pressed, we toggle the :ref:`OS "
"<class_OS>`'s full screen mode by setting it to the flipped version of its "
"current value."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:179
msgid ""
"If the ``vsync`` button is pressed, we set the :ref:`OS <class_OS>`'s Vsync "
"based on the state of the Vsync check button."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:183
msgid "Finally, lets take a look at ``set_mouse_and_joypad_sensitivity``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:185
msgid ""
"Firstly, we get the ``Globals`` singleton and assign it to a local variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:187
msgid ""
"We then set the ``mouse_sensitivity`` and ``joypad_sensitivity`` variables "
"to the values in their respective :ref:`HSlider <class_HSlider>` node "
"counterparts."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:190
msgid "Making the ``Globals`` singleton"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:192
msgid ""
"Now, for all this to work, we need to create the ``Globals`` singleton. Make "
"a new script in the ``Script`` tab and call it ``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:194
msgid ""
"To make the ``Globals`` singleton, go to the ``Script`` tab in the editor, "
"then click ``New`` and a ``Create Script`` box will appear, leave everything "
"unchanged except for the ``Path`` where you need to insert the script's name "
"``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:196
msgid "Add the following to ``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:211
msgid ""
"As you can see, it's quite small and simple. As this part progresses, we "
"will keep adding more complex logic to ``Globals.gd``, but for now, all it "
"is doing is holding two class variables, and abstract defining how we change "
"scenes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:214
msgid ""
"``mouse_sensitivity``: The current sensitivity for our mouse, so we can load "
"it in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:215
msgid ""
"``joypad_sensitivity``: The current sensitivity for our joypad, so we can "
"load it in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:217
msgid ""
"Right now, all we will be using ``Globals.gd`` for is a way to carry "
"variables across scenes. Because the sensitivities of our mouse and joypad "
"are stored in ``Globals.gd``, any changes we make in one scene (like in "
"``Options_Menu``) will affect the sensitivity for the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:220
msgid ""
"All we're doing in ``load_new_scene`` is calling :ref:`SceneTree "
"<class_SceneTree>`'s ``change_scene`` function, passing in the scene path "
"given in ``load_new_scene``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:222
msgid ""
"That's all the code needed for ``Globals.gd`` right now! Before we can test "
"the main menu, we first need to set ``Globals.gd`` as an autoload script."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:224
msgid "Open up the ``Project Settings`` and click the ``AutoLoad`` tab."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:228
msgid ""
"Then select the path to ``Globals.gd`` in the ``Path`` field by clicking the "
"button (``..``) beside it. Make sure the name in the ``Node Name`` field is "
"``Globals``. If you have everything like in the picture above, then press "
"``Add``!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:231
msgid ""
"This will make ``Globals.gd`` a singleton/autoload script, which will allow "
"us to access it from any script, in any scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:233
msgid ""
"For more information on singleton/autoload scripts, see :ref:"
"`doc_singletons_autoload`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:235
msgid ""
"Now that ``Globals.gd`` is a singleton/autoload script, you can test the "
"main menu!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:237
msgid ""
"You may want to change the main scene from ``Testing_Area.tscn`` to "
"``Main_Menu.tscn`` so when we export the game the player will start at the "
"main menu. You can do this through the ``Project Settings``, under the "
"``General`` tab. Then in the ``Application`` category, click the ``Run`` "
"subcategory and you can change the main scene by changing the value in "
"``Main Scene``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:241
msgid ""
"You'll have to set the paths to the correct files in ``Main_Menu`` in the "
"editor before testing the main menu! Otherwise you will not be able to "
"change scenes from the level select menu/screen."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:245
msgid "Adding the debug menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:247
msgid ""
"Now, let's add a simple debugging scene so we can track things like FPS "
"(Frames Per Second) in-game. Open up ``Debug_Display.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:249
msgid ""
"You can see it's a :ref:`Panel <class_Panel>` positioned in the top right "
"corner of the screen. It has three :ref:`Labels <class_Label>`, one for "
"displaying the FPS at which the game is running, one for showing on what OS "
"the game is running, and a label for showing with which Godot version the "
"game is running."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:252
msgid ""
"Let's add the code needed to fill these :ref:`Labels <class_Label>`. Select "
"``Debug_Display`` and create a new script called ``Debug_Display.gd``. Add "
"the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:265
msgid "Let's go over what this script does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:269
msgid ""
"In ``_ready``, we set the ``OS_Label``'s text to the name provided by :ref:"
"`OS <class_OS>` using the ``get_name`` function. This will return the name "
"of the OS (or Operating System) for which Godot was compiled. For example, "
"when you are running Windows, it will return ``Windows``, while when you are "
"running Linux, it will return ``X11``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:273
msgid ""
"Then, we set the ``Engine_Label``'s text to the version info provided by "
"``Engine.get_version_info``. ``Engine.get_version_info`` returns a "
"dictionary full of useful information about the version of Godot which is "
"currently running. We only care about the string version, for this label at "
"least, so we get the string and assign that as the ``text`` in "
"``Engine_Label``. See :ref:`Engine <class_Engine>` for more information on "
"the values ``get_version_info`` returns."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:277
msgid ""
"In ``_process``, we set the text of the ``FPS_Label`` to ``Engine."
"get_frames_per_second``, but because ``get_frames_per_second`` returns an "
"integer, we have to cast it to a string using ``str`` before we can add it "
"to the :ref:`Label <class_Label>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:282
msgid ""
"Now let's jump back to ``Main_Menu.gd`` and change the following in "
"``options_menu_button_pressed``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:289
msgid "to this instead:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:296
msgid ""
"This will call a new function called ``set_debug_display`` in our singleton, "
"so let's add that next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:300
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:391
msgid "Open up ``Globals.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:314
msgid ""
"``canvas_layer``: A canvas layer so the GUI/UI created in ``Globals.gd`` is "
"always drawn on top."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:315
msgid "``DEBUG_DISPLAY``: The debug display scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:316
msgid ""
"``debug_display``: A variable to hold the debug display when/if there is one."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:318
msgid ""
"Now that we have the class variables defined, we need to add a few lines to "
"``_ready`` so ``Globals.gd`` will have a canvas layer to use (which we will "
"store in ``canvas_layer``). Change ``_ready`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:327
msgid ""
"Now in ``_ready``, we create a new canvas layer, assign it to "
"``canvas_layer`` and add it as a child. Because ``Globals.gd`` is an "
"autoload/singleton, Godot will make a :ref:`Node <class_Node>` when the game "
"is launched, and it will have ``Globals.gd`` attached to it. Since Godot "
"makes a :ref:`Node <class_Node>`, we can treat ``Globals.gd`` like any other "
"node with regard to adding/removing children nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:331
msgid ""
"The reason we're adding a :ref:`CanvasLayer <class_CanvasLayer>` is so all "
"our GUI and UI nodes we instance/spawn in ``Globals.gd`` are always drawn on "
"top of everything else."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:334
msgid ""
"When adding nodes to a singleton/autoload, you have to be careful not to "
"lose reference to any of the child nodes. This is because nodes will not be "
"freed/destroyed when you change the active scene, meaning you can run into "
"memory problems if you are instancing/spawning lots of nodes and you are not "
"freeing them."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:340
msgid "Now we need to add ``set_debug_display`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:356
msgid ""
"First we check to see if ``Globals.gd`` is trying to turn on the debug "
"display, or turn it off."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:358
msgid ""
"If ``Globals.gd`` is turning off the display, we then check to see if "
"``debug_display`` is not equal to ``null``. If ``debug_display`` is not "
"equal to ``null``, then ``Globals.gd`` must have a debug display currently "
"active. If ``Globals.gd`` has a debug display active, we free it using "
"``queue_free`` and then assign ``debug_display`` to ``null``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:361
msgid ""
"If ``Globals.gd`` is turning on the display, we then check to make sure "
"``Globals.gd`` do not already have a debug display active. We do this by "
"making sure ``debug_display`` is equal to ``null``. If ``debug_display`` is "
"``null``, we instance a new ``DEBUG_DISPLAY_SCENE``, and add it as a child "
"of ``canvas_layer``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:367
msgid ""
"With that done, we can now toggle the debug display on and off by switching "
"the :ref:`CheckButton <class_CheckButton>` in the ``Options_Menu`` panel. Go "
"give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:369
msgid ""
"Notice how the debug display stays even when you change scenes from the "
"``Main_Menu.tscn`` to another scene (like ``Testing_Area.tscn``). This is "
"the beauty of instancing/spawning nodes in a singleton/autoload and adding "
"them as children to the singleton/autoload. Any of the nodes added as "
"children of the singleton/autoload will stay for as long as the game is "
"running, without any additional work on our part!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:374
msgid "Adding a pause menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:376
msgid ""
"Let's add a pause menu so we can return to the main menu when we press the "
"``ui_cancel`` action."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:378
msgid "Open up ``Pause_Popup.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:380
msgid ""
"Notice how the root node in ``Pause_Popup`` is a :ref:`WindowDialog "
"<class_WindowDialog>`; :ref:`WindowDialog <class_WindowDialog>` inherits "
"from :ref:`Popup <class_Popup>`, which means :ref:`WindowDialog "
"<class_WindowDialog>` can act like a popup."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:383
msgid ""
"Select ``Pause_Popup`` and scroll down all the way till you get to the "
"``Pause`` menu in the inspector. Notice how the pause mode is set to "
"``process`` instead of ``inherit`` like it is normally set by default. This "
"makes it so it will continue to process even when the game is paused, which "
"we need in order to interact with the UI elements."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:387
msgid ""
"Now that we've looked at how ``Pause_Popup.tscn`` is set up, let's write the "
"code to make it work. Normally, we'd attach a script to the root node of the "
"scene, ``Pause_Popup`` in this case, but since we'll need to receive a "
"couple of signals in ``Globals.gd``, we'll write all the code for the popup "
"there."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:399
msgid "``MAIN_MENU_PATH``: The path to the main menu scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:400
msgid "``POPUP_SCENE``: The pop up scene we looked at earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:401
msgid "``popup``: A variable to hold the pop up scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:403
msgid ""
"Now we need to add ``_process`` to ``Globals.gd`` so it can respond when the "
"``ui_cancel`` action is pressed. Add the following to ``_process``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:428
msgid ""
"Firstly, we check to see if the ``ui_cancel`` action is pressed. Then, we "
"check to make sure ``Globals.gd`` does not already have a ``popup`` open by "
"checking to see if ``popup`` is equal to ``null``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:431
msgid ""
"If ``Globals.gd`` do not have a pop-up open, we instance ``POPUP_SCENE`` and "
"assign it to ``popup``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:433
msgid ""
"We then get the quit button and assign its ``pressed`` signal to "
"``popup_quit``, which we will be adding shortly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:435
msgid ""
"Next, we assign both the ``popup_hide`` signal from the :ref:`WindowDialog "
"<class_WindowDialog>` and the ``pressed`` signal from the resume button to "
"``popup_closed``, which we will be adding shortly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:438
msgid ""
"Then, we add ``popup`` as a child of ``canvas_layer`` so it's drawn on top. "
"We then tell ``popup`` to pop up at the center of the screen using "
"``popup_centered``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:440
msgid ""
"Next, we make sure the mouse mode is ``MOUSE_MODE_VISIBLE`` so the player "
"can interact with the pop-up. If we did not do this, the player would not be "
"able to interact with the pop up in any scene where the mouse mode is "
"``MOUSE_MODE_CAPTURED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:443
msgid "Finally, we pause the entire :ref:`SceneTree <class_SceneTree>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:445
msgid "For more information on pausing in Godot, see :ref:`doc_pausing_games`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:449
msgid ""
"Now, we need to add the functions to which we've connected the signals. "
"Let's add ``popup_closed`` first."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:451
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:466
msgid "Add the following to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:462
msgid ""
"``popup_closed`` will resume the game and destroy the pop-up if there is one."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:464
msgid ""
"``popup_quit`` is similar, but we're also making sure the mouse is visible "
"and changing scenes to the title screen."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:481
msgid ""
"``popup_quit`` will resume the game, set the mouse mode to "
"``MOUSE_MODE_VISIBLE`` to ensure the mouse is visible in the main menu, "
"destroy the pop-up if there is one, and change scenes to the main menu."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:486
msgid ""
"Before we're ready to test the pop-up, we should change one thing in "
"``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:488
msgid ""
"Open up ``Player.gd`` and in ``process_input``, change the code for "
"capturing/freeing the cursor to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:490
msgid "Instead of:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:501
msgid "You will leave only:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:509
msgid ""
"Now, instead of capturing/freeing the mouse, we check whether the current "
"mouse mode is ``MOUSE_MODE_VISIBLE``. If it is, we set it back to "
"``MOUSE_MODE_CAPTURED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:512
msgid ""
"Because the pop-up makes the mouse mode ``MOUSE_MODE_VISIBLE`` whenever you "
"pause, we no longer have to worry about freeing and capturing the cursor in "
"``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:516
msgid ""
"Now the pause menu pop-up is finished. You can now pause at any point in the "
"game and return to the main menu!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:519
msgid "Starting the respawn system"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:521
msgid ""
"Since the player can lose all their health, it would be ideal if the player "
"died and respawned too, so let's add that next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:523
msgid ""
"Firstly, open up ``Player.tscn`` and expand ``HUD``. Notice how there is a :"
"ref:`ColorRect <class_ColorRect>` called ``Death_Screen``. When the player "
"dies, we're going to make ``Death_Screen`` visible, and show them how long "
"they have to wait before the player is able to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:536
msgid "``RESPAWN_TIME``: The amount of time (in seconds) it takes to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:537
msgid "``dead_time``: A variable to track how long the player has been dead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:538
msgid ""
"``is_dead``: A variable to track whether or not the player is currently dead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:539
msgid "``globals``: A variable to hold the ``Globals.gd`` singleton."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:543
msgid ""
"We now need to add a couple lines to ``_ready``, so we can use ``Globals."
"gd`` in ``Player.gd``. Add the following to ``_ready``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:551
msgid ""
"Now we're getting the ``Globals.gd`` singleton and assigning it to "
"``globals``. We also set the player's global position by setting the origin "
"in the player's global :ref:`Transform <class_Transform>` to the position "
"returned by ``globals.get_respawn_position``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:554
msgid "Don't worry, we will be adding ``get_respawn_position`` further below!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:558
msgid ""
"Next, we need to make a few changes to ``_physics_process``. Change "
"``_physics_process`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:576
msgid ""
"Now the player will not be processing input or movement input when the "
"player is dead. We are also now calling ``process_respawn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:578
msgid ""
"The ``if !is_dead:`` expression is equivalent and works in the same way as "
"the expression ``if is_dead == false:``. And by removing the ``!`` sign from "
"the expression we obtain the opposite expression ``if is_dead == true:``. It "
"is just a shorter way of writing the same code functionality."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:580
msgid "We have not made ``process_respawn`` yet, so let's change that."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:584
msgid "Let's add ``process_respawn``. Add the following to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:643
msgid "Let's go through what this function is doing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:647
msgid ""
"Firstly, we check whether the player has just died by checking if ``health`` "
"is less than or equal to ``0`` and ``is_dead`` is ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:649
msgid ""
"If the player has just died, we disable the collision shapes for the player. "
"We do this to make sure the player is not blocking anything with their dead "
"body."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:651
msgid ""
"Next, we set ``changing_weapon`` to ``true`` and set "
"``changing_weapon_name`` to ``UNARMED``. This is so, if the player is using "
"a weapon, it is put away when they dies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:654
msgid ""
"We then make the ``Death_Screen`` :ref:`ColorRect <class_ColorRect>` visible "
"so the player gets a nice grey overlay over everything when they have died. "
"We then make the rest of the UI, the ``Panel`` and ``Crosshair`` nodes, "
"invisible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:657
msgid ""
"Next, we set ``dead_time`` to ``RESPAWN_TIME`` so we can start counting down "
"how long the player has been dead. We also set ``is_dead`` to ``true`` so we "
"know the player has died."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:659
msgid ""
"If the player is holding an object when they died, we need to throw it. We "
"first check whether the player is holding an object or not. If the player is "
"holding a object, we throw it using the same code as the throwing code we "
"added in :ref:`doc_fps_tutorial_part_five`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:662
msgid ""
"The ``\\n`` combination from the expression ``You have died\\n`` is a "
"command used to display the text following after it on a new line below. "
"This is always useful when you want to nicely group displayed text in "
"multiple lines so it looks better and is more readable by the players of "
"your games."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:666
msgid ""
"Then we check whether the player is dead. If so, we then remove ``delta`` "
"from ``dead_time``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:668
msgid ""
"We then make a new variable called ``dead_time_pretty``, where we convert "
"``dead_time`` to a string, using only the first three characters starting "
"from the left. This gives the player a nice looking string showing how much "
"time the player has left to wait before the player can respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:671
msgid ""
"We then change the :ref:`Label <class_Label>` in ``Death_Screen`` to show "
"how much time the player has left."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:673
msgid ""
"Next we check to see if the player has waited long enough and can respawn. "
"We do this by checking to see if ``dead_time`` is ``0`` or less."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:675
msgid ""
"If the player has waited long enough to respawn, we set the player's "
"position to a new respawn position provided by ``get_respawn_position``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:677
msgid ""
"We then enable both of the player's collision shapes so the player can "
"collide again with the environment."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:679
msgid ""
"Next, we make the ``Death_Screen`` invisible and make the rest of the UI, "
"the ``Panel`` and ``Crosshair`` nodes, visible again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:681
msgid ""
"We then go through each weapon and call its ``reset_weapon`` function, which "
"we will add soon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:683
msgid ""
"Then, we reset ``health`` to ``100``, ``grenade_amounts`` to its default "
"values, and change ``current_grenade`` to ``Grenade``. This effectively "
"resets these variables to their default values."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:686
msgid "Finally, we set ``is_dead`` to ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:690
msgid ""
"Before we leave ``Player.gd``, we need to add one quick thing to ``_input``. "
"Add the following at the beginning of ``_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:697
msgid "Now, when the player is dead, they cannot look around with the mouse."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:700
msgid "Finishing the respawn system"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:702
msgid ""
"Firstly, let's open ``Weapon_Pistol.gd`` and add the ``reset_weapon`` "
"function. Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:710
msgid ""
"Now, when we call ``reset_weapon``, the ammo in the pistol and the ammo in "
"the spares will be reset to their default values."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:712
msgid "Now let's add ``reset_weapon`` in ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:720
msgid "And add the following to ``Weapon_Knife.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:728
msgid "Now all the weapons will reset when the player dies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:732
msgid ""
"Now we need to add a few things to ``Globals.gd``. Firstly, add the "
"following class variable:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:738
msgid ""
"``respawn_points``: A variable to hold all the respawn points in a level"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:740
msgid ""
"Because we're getting a random spawn point each time, we need to randomize "
"the number generator. Add the following to ``_ready``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:746
msgid ""
"``randomize`` will get us a new random seed so we get a (relatively) random "
"string of numbers when we use any of the random functions."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:748
msgid "Now let's add ``get_respawn_position`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:763
msgid ""
"Firstly, we check if ``Globals.gd`` has any ``respawn_points`` by checking "
"whether ``respawn_points`` is ``null`` or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:765
msgid ""
"If ``respawn_points`` is ``null``, we return a position of empty :ref:"
"`Vector 3 <class_Vector3>` with the position ``(0, 0, 0)``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:767
msgid ""
"If ``respawn_points`` is not ``null``, we then get a random number between "
"``0`` and the number of elements we have in ``respawn_points``, minus ``1`` "
"since most programming languages, including ``GDScript``, start counting "
"from ``0`` when you are accessing elements in a list."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:770
msgid ""
"We then return the position of the :ref:`Spatial <class_Spatial>` node at "
"``respawn_point`` position in ``respawn_points``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:774
msgid ""
"Before we are done with ``Globals.gd``, we need to add the following to "
"``load_new_scene``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:780
msgid ""
"We set ``respawn_points`` to ``null`` so when/if the player gets to a level "
"with no respawn points, we do not respawn the player at the respawn points "
"that were in the level prior."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:785
msgid ""
"Now all we need is a way to set the respawn points. Open up ``Ruins_Level."
"tscn`` and select ``Spawn_Points``. Add a new script called "
"``Respawn_Point_Setter.gd`` and attach it to ``Spawn_Points``. Add the "
"following to ``Respawn_Point_Setter.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:796
msgid ""
"Now, when a node with ``Respawn_Point_Setter.gd`` has its ``_ready`` "
"function called, all the children nodes of the node with "
"``Respawn_Point_Setter.gd``, ``Spawn_Points`` in the case of ``Ruins_Level."
"tscn``, will be added to ``respawn_points`` in ``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:800
msgid ""
"Any node with ``Respawn_Point_Setter.gd`` has to be above the player in the :"
"ref:`SceneTree <class_SceneTree>` so the respawn points are set before the "
"player needs them in the player's ``_ready`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:805
msgid ""
"Now, when the player dies, they will respawn after waiting ``4`` seconds!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:807
msgid ""
"No spawn points are already set up for any of the levels besides "
"``Ruins_Level.tscn``! Adding spawn points to ``Space_Level.tscn`` is left as "
"an exercise for the reader."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:811
msgid "Writing a sound system we can use anywhere"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:813
msgid ""
"Finally, let's make a sound system so we can play sounds from anywhere, "
"without having to use the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:815
msgid ""
"Firstly, open up ``SimpleAudioPlayer.gd`` and change it to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:859
msgid ""
"There are several changes from the old version, first and foremost being we "
"are no longer storing the sound files in ``SimpleAudioPlayer.gd`` anymore. "
"This is much better for performance since we're no longer loading each audio "
"clip when we create a sound, but instead we are forcing an audio stream to "
"be passed in to ``play_sound``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:863
msgid ""
"Another change is we have a new class variable called ``should_loop``. "
"Instead of just destroying the audio player every time it's finished, we "
"instead want to check and see if the audio player is set to loop or not. "
"This allows us to have audio like looping background music without having to "
"spawn a new audio player with the music when the old one is finished."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:865
msgid ""
"Finally, instead of being instanced/spawned in ``Player.gd``, the audio "
"player is instead going to be spawned in ``Globals.gd`` so we can create "
"sounds from any scene. Now the audio player stores ``Globals.gd`` singleton "
"so when the audio player is destroyed, we can also remove it from a list in "
"``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:868
msgid "Let's go over the changes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:872
msgid ""
"For the class variables, we removed all the ``audio_[insert name here]`` "
"variables since we will instead have these passed in from ``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:874
msgid ""
"We also added two new class variables, ``should_loop`` and ``globals``. "
"We'll use ``should_loop`` to tell whether the audio player should loop when "
"the sound has finished, and ``globals`` will hold the ``Globals.gd`` "
"singleton."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:877
msgid ""
"The only change in ``_ready`` is now audio player is getting the ``Globals."
"gd`` singleton and assigning it to ``globals``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:879
msgid ""
"``play_sound`` now expects an audio stream, named ``audio_stream``, to be "
"passed in, instead of ``sound_name``. Instead of checking the sound name and "
"setting the stream for the audio player, we instead check to make sure an "
"audio stream was passed in. If an audio stream was not passed in, we print "
"an error message, remove the audio player from a list in the ``Globals.gd`` "
"singleton called ``created_audio``, and then free the audio player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:883
msgid ""
"Finally, in ``sound_finished`` we first check to see if the audio player is "
"supposed to loop or not using ``should_loop``. If the audio player is "
"supposed to loop, we play the sound again from the start, at position "
"``0.0``. If the audio player is not supposed to loop, we remove the audio "
"player from a list in the ``Globals.gd`` singleton called ``created_audio``, "
"and then free the audio player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:889
msgid ""
"Now that we've finished our changes to ``SimpleAudioPlayer.gd``, we now need "
"to turn our attention to ``Globals.gd``. First, add the following class "
"variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:905
msgid "Let's go over these global variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:907
msgid ""
"``audio_clips``: A dictionary holding all the audio clips ``Globals.gd`` can "
"play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:908
msgid "``SIMPLE_AUDIO_PLAYER_SCENE``: The simple audio player scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:909
msgid ""
"``created_audio``: A list to hold all the simple audio players ``Globals."
"gd`` has created."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:911
msgid ""
"If you want to add additional audio, you need to add it to ``audio_clips``. "
"No audio files are provided in this tutorial, so you will have to provide "
"your own."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:914
msgid ""
"One site I'd recommend is **GameSounds.xyz**. I'm using the Gamemaster audio "
"gun sound pack included in the Sonniss' GDC Game Audio bundle for 2017. The "
"tracks I've used (with some minor editing) are as follows:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:918
msgid "gun_revolver_pistol_shot_04,"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:919
msgid "gun_semi_auto_rifle_cock_02,"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:920
msgid "gun_submachine_auto_shot_00_automatic_preview_01"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:924
msgid ""
"Now we need to add a new function called ``play_sound`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:943
msgid ""
"Firstly, we check whether ``Globals.gd`` has an audio clip with the name "
"``sound_name`` in ``audio_clips``. If it does not, we print an error message."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:945
msgid ""
"If ``Globals.gd`` has an audio clip with the name ``sound_name``, we then "
"instance/spawn a new ``SIMPLE_AUDIO_PLAYER_SCENE`` and assign it to "
"``new_audio``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:947
msgid ""
"We then set ``should_loop``, and add ``new_audio`` as a child of ``Globals."
"gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:949
msgid ""
"Remember, we have to be careful adding nodes to a singleton, since these "
"nodes will not be destroyed when changing scenes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:951
msgid ""
"We add the ``new_audio`` into the ``created_audio`` list to hold all created "
"audios."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:953
msgid ""
"We then call ``play_sound``, passing in the audio clip associated with "
"``sound_name`` and the sound position."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:957
msgid ""
"Before we leave ``Globals.gd``, we need to add a few lines of code to "
"``load_new_scene`` so when the player changes scenes, all the audio is "
"destroyed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:959
msgid "Add the following to ``load_new_scene``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:968
msgid ""
"Now, before ``Globals.gd`` changes scenes, it goes through each simple audio "
"player in ``created_sounds`` and frees/destroys them. Once ``Globals.gd`` "
"has gone through all the sounds in ``created_audio``, we clear "
"``created_audio`` so it no longer holds any references to any (now freed/"
"destroyed) simple audio players."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:973
msgid ""
"Let's change ``create_sound`` in ``Player.gd`` to use this new system. "
"First, remove ``simple_audio_player`` from ``Player.gd``'s class variables "
"since we will no longer be directly instancing/spawning sounds in ``Player."
"gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:976
msgid "Now, change ``create_sound`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:983
msgid ""
"Now, whenever ``create_sound`` is called, we simply call ``play_sound`` in "
"``Globals.gd``, passing in all the arguments received."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:987
msgid ""
"Now all the sounds in our FPS can be played from anywhere. All we have to do "
"is get the ``Globals.gd`` singleton, and call ``play_sound``, pass in the "
"name of the sound we want to play, whether we want it to loop or not, and "
"the position from which to play the sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:990
msgid ""
"For example, if you want to play an explosion sound when the grenade "
"explodes you'd need to add a new sound to ``audio_clips`` in ``Globals.gd``, "
"get the ``Globals.gd`` singleton, and then you just need to add something "
"like ``globals.play_sound(\"explosion\", false, global_transform.origin)`` "
"in the grenades ``_process`` function, right after the grenade damages all "
"the bodies within its blast radius."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1000
msgid "Now you have a fully working single player FPS!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1002
msgid ""
"At this point, you have a good base to build more complicated FPS games."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1006
msgid ""
"You can download the finished project for the entire tutorial here: :"
"download:`Godot_FPS_Part_6.zip <files/Godot_FPS_Finished.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1008
msgid ""
"The finished project source files contain the same code, just written in a "
"different order. This is because the finished project source files are what "
"the tutorial is based on."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1011
msgid ""
"The finished project code was written in the order that features were "
"created, not necessarily in a order that is ideal for learning."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1014
msgid ""
"Other than that, the source is exactly the same, just with helpful comments "
"explaining what each part does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1017
msgid ""
"The finished project source is hosted on GitHub as well: https://github.com/"
"TwistedTwigleg/Godot_FPS_Tutorial"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1019
msgid ""
"**Please note that the code in GitHub may or may not be in sync with the "
"tutorial in the documentation**."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1021
msgid ""
"The code in the documentation is likely better managed and/or more up to "
"date. If you are unsure of which to use, use the project(s) provided in the "
"documentation, as they are maintained by the Godot community."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1024
msgid ""
"You can download all the ``.blend`` files used in this tutorial here: :"
"download:`Godot_FPS_BlenderFiles.zip <files/Godot_FPS_BlenderFiles.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1026
msgid ""
"All assets provided in the started assets (unless otherwise noted) were "
"**originally created by TwistedTwigleg, with changes/additions by the Godot "
"community.** All original assets provided for this tutorial are released "
"under the ``MIT`` license."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1031
msgid ""
"The skybox is created by **StumpyStrust** and can be found at OpenGameArt."
"org. https://opengameart.org/content/space-skyboxes-0 . The skybox is "
"licensed under the ``CC0`` license."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1036
msgid ""
"The skybox was converted to a 360 equirectangular image using this tool: "
"https://www.360toolkit.co/convert-cubemap-to-spherical-equirectangular.html"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1038
msgid ""
"While no sounds are provided, you can find many game ready sounds at https://"
"gamesounds.xyz/"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1040
msgid ""
"**OpenGameArt.org, 360toolkit.co, the creator(s) of Titillium-Regular, "
"StumpyStrust, and GameSounds.xyz are in no way involved in this tutorial.**"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/index.rst:2
msgid "Animating thousands of objects"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:4
msgid "Animating thousands of fish with MultiMeshInstance"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:6
msgid ""
"This tutorial explores a technique used in the game `ABZU <https://www."
"gdcvault.com/play/1024409/Creating-the-Art-of-ABZ>`_ for rendering and "
"animating thousands of fish using vertex animation and static mesh "
"instancing."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:10
msgid ""
"In Godot, this can be accomplished with a custom :ref:`Shader "
"<class_Shader>` and a :ref:`MultiMeshInstance <class_MultiMeshInstance>`. "
"Using the following technique you can render thousands of animated objects, "
"even on low end hardware."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:14
msgid ""
"We will start by animating one fish. Then, we will see how to extend that "
"animation to thousands of fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:18
#, fuzzy
msgid "Animating one Fish"
msgstr "אנימציות"

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:20
msgid ""
"We will start with a single fish. Load your fish model into a :ref:"
"`MeshInstance <class_MeshInstance>` and add a new :ref:`ShaderMaterial "
"<class_ShaderMaterial>`."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:23
msgid ""
"Here is the fish we will be using for the example images, you can use any "
"fish model you like."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:27
msgid ""
"The fish model in this tutorial is made by `QuaterniusDev <http://quaternius."
"com>`_ and is shared with a creative commons license. CC0 1.0 Universal (CC0 "
"1.0) Public Domain Dedication https://creativecommons.org/publicdomain/"
"zero/1.0/"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:31
msgid ""
"Typically, you would use bones and a :ref:`Skeleton <class_Skeleton>` to "
"animate objects. However, bones are animated on the CPU and so you end "
"having to calculate thousands of operations every frame and it becomes "
"impossible to have thousands of objects. Using vertex animation in a vertex "
"shader, you avoid using bones and can instead calculate the full animation "
"in a few lines of code and completely on the GPU."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:37
msgid "The animation will be made of four key motions:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:39
msgid "A side to side motion"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:40
msgid "A pivot motion around the center of the fish"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:41
msgid "A panning wave motion"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:42
msgid "A panning twist motion"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:44
msgid ""
"All the code for the animation will be in the vertex shader with uniforms "
"controlling the amount of motion. We use uniforms to control the strength of "
"the motion so that you can tweak the animation in editor and see the results "
"in real time, without the shader having to recompile."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:48
msgid ""
"All the motions will be made using cosine waves applied to ``VERTEX`` in "
"model space. We want the vertices to be in model space so that the motion is "
"always relative to the orientation of the fish. For example, side-to-side "
"will always move the fish back and forth in its left to right direction, "
"instead of on the ``x`` axis in the world orientation."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:53
msgid ""
"In order to control the speed of the animation, we will start by defining "
"our own time variable using ``TIME``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:60
msgid ""
"The first motion we will implement is the side to side motion. It can be "
"made by offsetting ``VERTEX.x`` by ``cos`` of ``TIME``. Each time the mesh "
"is rendered, all the vertices will move to the side by the amount of "
"``cos(time)``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:69
msgid "The resulting animation should look something like this:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:73
msgid ""
"Next, we add the pivot. Because the fish is centered at (0, 0), all we have "
"to do is multiply ``VERTEX`` by a rotation matrix for it to rotate around "
"the center of the fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:76
msgid "We construct a rotation matrix like so:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:85
msgid ""
"And then we apply it in the ``x`` and ``z`` axes by multiplying it by "
"``VERTEX.xz``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:91
msgid "With only the pivot applied you should see something like this:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:95
msgid ""
"The next two motions need to pan down the spine of the fish. For that, we "
"need a new variable, ``body``. ``body`` is a float that is ``0`` at the tail "
"of the fish and ``1`` at its head."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:102
msgid ""
"The next motion is a cosine wave that moves down the length of the fish. To "
"make it move along the spine of the fish, we offset the input to ``cos`` by "
"the position along the spine, which is the variable we defined above, "
"``body``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:111
msgid ""
"This looks very similar to the side to side motion we defined above, but in "
"this one, by using ``body`` to offset ``cos`` each vertex along the spine "
"has a different position in the wave making it look like a wave is moving "
"along the fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:117
msgid ""
"The last motion is the twist, which is a panning roll along the spine. "
"Similarly to the pivot, we first  construct a rotation matrix."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:126
msgid ""
"We apply the rotation in the ``xy`` axes so that the fish appears to roll "
"around its spine. For this to work, the fish's spine needs to be centered on "
"the ``z`` axis."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:133
msgid "Here is the fish with twist applied:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:137
msgid ""
"If we apply all these motions one after another, we get a fluid jelly-like "
"motion."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:141
msgid ""
"Normal fish swim mostly with the back half of their body. Accordingly, we "
"need to limit the panning motions to the back half of the fish. To do this, "
"we create a new variable, ``mask``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:144
msgid ""
"``mask`` is a float that goes from ``0`` at the front of the fish to ``1`` "
"at the end  using ``smoothstep`` to control the point at which the "
"transition from ``0`` to ``1`` happens."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:152
msgid "Below is an image of the fish with ``mask`` used as ``COLOR``:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:156
msgid ""
"For the wave, we multiply the motion by ``mask`` which will limit it to the "
"back half."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:163
msgid ""
"In order to apply the mask to the twist, we use ``mix``. ``mix`` allows us "
"to mix the vertex position between a fully rotated vertex and one that is "
"not rotated. We need to use ``mix`` instead of multiplying ``mask`` by the "
"rotated ``VERTEX`` because we are not adding the motion to the ``VERTEX`` we "
"are replacing the ``VERTEX`` with the rotated version. If we multiplied that "
"by ``mask``, we would shrink the fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:174
msgid "Putting the four motions together gives us the final animation."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:178
msgid ""
"Go ahead and play with the uniforms in order to alter the swim cycle of the "
"fish. You will find that you can create a wide variety of swim styles using "
"these four motions."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:182
msgid "Making a school of fish"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:184
msgid ""
"Godot makes it easy to render thousands of the same object using a "
"MultiMeshInstance node."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:186
msgid ""
"A MultiMeshInstance node is created and used the same way you would make a "
"MeshInstance node. For this tutorial, we will name the MultiMeshInstance "
"node ``School``, because it will contain a school of fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:190
msgid ""
"Once you have a MultiMeshInstance add a :ref:`MultiMesh <class_MultiMesh>`, "
"and to that MultiMesh add your :ref:`Mesh <class_Mesh>` with the shader from "
"above."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:193
msgid ""
"MultiMeshes draw your Mesh with three additional per-instance properties: "
"Transform (rotation, translation, scale), Color, and Custom. Custom is used "
"to pass in 4 multi-use variables using a :ref:`Color <class_Color>`."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:197
msgid ""
"``instance_count`` specifies how many instances of the mesh you want to "
"draw. For now, leave ``instance_count`` at ``0`` because you cannot change "
"any of the other parameters while ``instance_count`` is larger than ``0``. "
"We will set ``instance count`` in GDScript later."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:201
msgid ""
"``transform_format`` specifies whether the transforms used are 3D or 2D. For "
"this tutorial, select 3D."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:203
msgid ""
"For both ``color_format`` and ``custom_data_format`` you can choose between "
"``None``, ``Byte``, and ``Float``. ``None`` means you won't be passing in "
"that data (either a per-instance ``COLOR`` variable, or ``INSTANCE_CUSTOM``) "
"to the shader. ``Byte`` means each number making up the color you pass in "
"will be stored with 8 bits while ``Float`` means each number will be stored "
"in a floating-point number (32 bits). ``Float`` is slower but more precise, "
"``Byte`` will take less memory and be faster, but you may see some visual "
"artifacts."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:210
msgid "Now, set ``instance_count`` to the number of fish you want to have."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:212
msgid "Next we need to set the per-instance transforms."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:214
msgid ""
"There are two ways to set per-instance transforms for MultiMeshes. The first "
"is entirely in editor and is described in the :ref:`MultiMeshInstance "
"tutorial <doc_using_multi_mesh_instance>`."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:217
msgid ""
"The second is to loop over all the instances and set their transforms in "
"code. Below, we use GDScript to loop over all the instances and set their "
"transform to a random position."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:227
msgid ""
"Running this script will place the fish in random positions in a box around "
"the position of the MultiMeshInstance."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:230
msgid ""
"If performance is an issue for you, try running the scene with GLES2 or with "
"fewer fish."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:232
msgid ""
"Notice how all the fish  are all in the same position in their swim cycle? "
"It makes them look very robotic. The next step is to give each fish a "
"different position in the swim cycle so the entire school looks more organic."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:237
msgid "Animating a school of fish"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:239
msgid ""
"One of the benefits of animating the fish using ``cos`` functions is that "
"they are animated with one parameter, ``time``. In order to give each fish a "
"unique position in the swim cycle, we only need to offset ``time``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:243
msgid ""
"We do that by adding the per-instance custom value ``INSTANCE_CUSTOM`` to "
"``time``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:249
msgid ""
"Next, we need to pass a value into ``INSTANCE_CUSTOM``. We do that by adding "
"one line into the ``for`` loop from above. In the ``for`` loop we assign "
"each instance a set of four random floats to use."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:257
msgid ""
"Now the fish all have unique positions in the swim cycle. You can give them "
"a little more individuality by using ``INSTANCE_CUSTOM`` to make them swim "
"faster or slower by multiplying by ``TIME``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:266
msgid ""
"You can even experiment with changing the per-instance color the same way "
"you changed the per-instance custom value."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:269
msgid ""
"One problem that you will run into at this point is that the fish are "
"animated, but they are not moving. You can move them by updating the per-"
"instance transform for each fish every frame. Although doing so will be "
"faster than moving thousands of MeshInstances per frame, it'll still likely "
"be slow."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/animating_thousands_of_fish.rst:274
msgid ""
"In the next tutorial we will cover how to use :ref:`Particles "
"<class_Particles>` to take advantage of the GPU and move each fish around "
"individually while still receiving the benefits of instancing."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:4
msgid "Controlling thousands of fish with Particles"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:6
msgid ""
"The problem with :ref:`MeshInstances <class_MeshInstance>` is that it is "
"expensive to update their transform array. It is great for placing many "
"static objects around the scene. But it is still difficult to move the "
"objects around the scene."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:10
msgid ""
"To make each instance move in an interesting way, we will use a :ref:"
"`Particles <class_Particles>` node. Particles take advantage of GPU "
"acceleration by computing and setting the per-instance information in a :ref:"
"`Shader <class_Shader>`."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:14
msgid ""
"Particles are not available in GLES2, instead use :ref:`CPUParticles "
"<class_CPUParticles>`, which do the same thing as Particles, but do not "
"benefit from GPU acceleration."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:17
msgid ""
"First create a Particles node. Then, under \"Draw Passes\" set the "
"Particle's \"Draw Pass 1\" to your :ref:`Mesh <class_Mesh>`. Then under "
"\"Process Material\" create a new :ref:`ShaderMaterial "
"<class_ShaderMaterial>`."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:21
msgid "Set the ``shader_type`` to ``particles``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:27
msgid "Then add the following two functions:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:51
msgid ""
"These functions come from the default :ref:`ParticlesMaterial "
"<class_ParticlesMaterial>`. They are used to generate a random number from  "
"each particle's ``RANDOM_SEED``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:54
msgid ""
"A unique thing about particle shaders is that some built-in variables are "
"saved across frames. ``TRANSFORM``, ``COLOR``, and ``CUSTOM`` can all be "
"accessed in the Spatial shader of the mesh, and also in the particle shader "
"the next time it is run."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:58
msgid ""
"Next, setup your ``vertex`` function. Particles shaders only contain a "
"vertex function and no others."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:61
msgid ""
"First we will distinguish between code that needs to be run only when the "
"particle system starts and code that should always run. We want to give each "
"fish a random position and a random animation offset when the system is "
"first run. To do so, we wrap that code in an ``if`` statement that checks "
"the built-in variable ``RESTART`` which becomes ``true`` for one frame when "
"the particle system is restarted."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:66
msgid "From a high level, this looks like:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:78
msgid ""
"Next, we need to generate 4 random numbers: 3 to create a random position "
"and one for the random offset of the swim cycle."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:81
msgid ""
"First, generate 4 seeds inside the ``RESTART`` block using the ``hash`` "
"function provided above:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:90
msgid ""
"Then, use those seeds to generate random numbers using ``rand_from_seed``:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:99
msgid ""
"Finally, assign ``position`` to ``TRANSFORM[3].xyz``, which is the part of "
"the transform that holds the position information."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:106
msgid "Remember, all this code so far goes inside the ``RESTART`` block."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:108
msgid ""
"The vertex shader for your mesh can stay the exact same as it was in the "
"previous tutorial."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:110
msgid ""
"Now you can move each fish individually each frame, either by adding to the "
"``TRANSFORM`` directly or by writing to ``VELOCITY``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:113
msgid "Let's transform the fish by setting their ``VELOCITY``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:119
msgid ""
"This is the most basic way to set ``VELOCITY`` every particle (or fish) will "
"have the same velocity."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:121
msgid ""
"Just by setting ``VELOCITY`` you can make the fish swim however you want. "
"For example, try the code below."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:128
msgid "This will give each fish a unique speed between ``2`` and ``10``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:130
msgid ""
"If you used ``CUSTOM.y`` in the last tutorial, you can also set the speed of "
"the swim animation based on the ``VELOCITY``. Just use ``CUSTOM.y``."
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:137
msgid "This code gives you the following behavior:"
msgstr ""

#: ../../docs/tutorials/3d/vertex_animation/controlling_thousands_of_fish.rst:141
msgid ""
"Using a ParticlesMaterial you can make the fish behavior as simple or "
"complex as you like. In this tutorial we only set Velocity, but in your own "
"Shaders you can also set ``COLOR``, rotation, scale (through ``TRANSFORM``). "
"Please refer to the :ref:`Particles Shader Reference <doc_particle_shader>` "
"for more information on particle shaders."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:4
#: ../../docs/tutorials/audio/audio_buses.rst:48
#, fuzzy
msgid "Audio buses"
msgstr "שמע"

#: ../../docs/tutorials/audio/audio_buses.rst:9
msgid ""
"Godot's audio processing code has been written with games in mind, with the "
"aim of achieving an optimal balance between performance and sound quality."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:12
msgid ""
"Godot's audio engine allows any number of audio buses to be created and any "
"number of effect processors can be added to each bus. Only the hardware of "
"the device running your game will limit the number of buses and effects that "
"can be used before performance starts to suffer."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:18
msgid "Decibel scale"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:20
msgid ""
"Godot's sound interface is designed to meet the expectations of sound design "
"professionals. To this end, it primarily uses the decibel scale."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:23
msgid "For those unfamiliar with it, it can be explained with a few facts:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:25
msgid ""
"The decibel (dB) scale is a relative scale. It represents the ratio of sound "
"power by using 20 times the base 10 logarithm of the ratio (20 × log\\ :sub:"
"`10`\\ (P/P\\ :sub:`0`\\ ))."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:28
msgid ""
"For every 6 dB, sound amplitude doubles or halves. 12 dB represents a factor "
"of 4, 18 dB a factor of 8, 20 dB a factor of 10, 40 dB a factor of 100, etc."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:30
msgid ""
"Since the scale is logarithmic, true zero (no audio) can't be represented."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:31
msgid ""
"0 dB is the maximum amplitude possible in a digital audio system. This limit "
"is not the human limit, but a limit from the sound hardware. Audio with "
"amplitudes that are too high to be represented properly below 0 dB create a "
"kind of distortion called *clipping*."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:35
msgid ""
"To avoid clipping, your sound mix should be arranged so that the output of "
"the *master bus* (more on that later) never exceeds 0 dB."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:37
msgid ""
"Every 6 dB below the 0 dB limit, sound energy is *halved*. It means the "
"sound volume at -6 dB is half as loud as 0dB. -12 dB is half as loud as -6 "
"dB and so on."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:40
msgid ""
"When working with decibels, sound is considered no longer audible between "
"-60 dB and -80 dB. This makes your working range generally between -60 dB "
"and 0 dB."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:44
msgid ""
"This can take a bit getting used to, but it's friendlier in the end and will "
"allow you to communicate better with audio professionals."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:50
msgid "Audio buses can be found in the bottom panel of the Godot editor:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:54
msgid ""
"An *audio bus* (also called an *audio channel*) can be considered a place "
"that audio is channeled through on the way to playback through a device's "
"speakers. Audio data can be *modified* and *re-routed* by an audio bus. An "
"audio bus has a VU meter (the bars that light up when sound is played) which "
"indicates the amplitude of the signal passing through."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:60
msgid ""
"The leftmost bus is the *master bus*. This bus outputs the mix to your "
"speakers so, as mentioned in the *Decibel scale* section above, make sure "
"that your mix level doesn't reach 0 dB in this bus. The rest of the audio "
"buses can be flexibly routed. After modifying the sound, they send it to "
"another bus to the left. The destination bus can be specified for each of "
"the non-master audio buses. Routing always passes audio from buses on the "
"right to buses further to the left. This avoids infinite routing loops."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:70
msgid ""
"In the above image, the output of *Bus 2* has been routed to the *Master* "
"bus."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:73
msgid "Playback of audio through a bus"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:75
msgid ""
"To test passing audio to a bus, create an AudioStreamPlayer node, load an "
"AudioStream and select a target bus for playback:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:80
msgid "Finally, toggle the **Playing** property to **On** and sound will flow."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:84
msgid ""
"You may also be interested in reading about :ref:`doc_audio_streams` now."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:87
msgid "Adding effects"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:89
msgid ""
"Audio buses can contain all sorts of effects. These effects modify the sound "
"in one way or another and are applied in order."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:94
msgid ""
"Try them all out to get a sense of how they alter sound. Here follows a "
"short description of the available effects:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:98
msgid "Amplify"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:100
msgid ""
"Amplify changes the amplitude of the signal. Some care needs to be taken. "
"Setting the level too high can make the sound clip, which is usually "
"undesirable."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:105
msgid "BandLimit and BandPass"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:107
msgid ""
"These are resonant filters which block frequencies around the *Cutoff* "
"point. BandPass can be used to simulate sound passing through an old "
"telephone line or megaphone. Modulating the BandPass frequency can simulate "
"the sound of a wah-wah guitar pedal, think of the guitar in Jimi Hendrix's "
"*Voodoo Child (Slight Return)*."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:114
msgid "Chorus"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:116
msgid ""
"The Chorus effect duplicates the incoming audio, delays the duplicate "
"slightly and uses an LFO to continuously modulate the pitch of the "
"duplicated signal before mixing the duplicated signal(s) and the original "
"together again. This creates a shimmering effect and adds stereo width to "
"the sound."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:122
msgid "Compressor"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:124
msgid ""
"A dynamic range compressor automatically attenuates the level of the "
"incoming signal when its amplitude exceeds a certain threshold. The level of "
"attenuation applied is proportional to how far the incoming audio exceeds "
"the threshold. The compressor's Ratio parameter controls the degree of "
"attenuation. One of the main uses of a compressor is to reduce the dynamic "
"range of signals with very loud and quiet parts. Reducing the dynamic range "
"of a signal can make it easier to mix."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:132
msgid "The compressor has many uses. For example:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:134
msgid "It can be used in the Master bus to compress the whole output."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:135
msgid ""
"It can be used in voice channels to ensure they sound as even as possible."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:136
msgid ""
"It can be *sidechained*. This means it can reduce the sound level of one "
"signal using the level of another audio bus for threshold detection. This "
"technique is very common in video game mixing to \"duck\" the level of music "
"or sound effects when voices need to be heard."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:140
msgid ""
"It can accentuate transients by using a slower attack. This can make sound "
"effects more punchy."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:145
msgid ""
"If your goal is to prevent a signal from exceeding a given amplitude "
"altogether, rather than to reduce the dynamic range of the signal, a :ref:"
"`limiter <doc_audio_buses_limiter>` is likely a better choice than a "
"compressor."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:152
msgid "Delay"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:154
msgid ""
"Adds an \"echo\" effect with a feedback loop. It can be used together with "
"*Reverb* to simulate wide rooms, canyons, etc. where sound bounces are far "
"apart."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:159
msgid "Distortion"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:161
msgid ""
"Distortion effects make the sound \"dirty\". Godot offers several types of "
"distortion: *overdrive*, *tan* and *bit crushing*. Distortion can be used to "
"simulate sound coming through a low-quality speaker or device."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:166
msgid "EQ"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:168
msgid ""
"EQ is what all other equalizers inherit from. It can be extended with with "
"Custom scripts to create an equalizer with a custom number of bands."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:172
msgid "EQ6, EQ10, EQ21"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:174
msgid ""
"Godot provides three equalizers with different numbers of bands. An "
"equalizer on the Master bus can be useful to cut frequencies that the "
"device's speakers can't reproduce well (e.g. a mobile phone's speakers won't "
"reproduce bass content well). The equalizer effect can be disabled when "
"headphones are plugged in."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:182
msgid ""
"Filter is what all other filters inherit from and should not be used "
"directly."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:185
msgid "HighPassFilter, HighShelfFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:187
msgid ""
"These are filters that cut frequencies below a specific *Cutoff* frequency. "
"HighPassFilter and HighShelfFilter are used to reduce the bass content of a "
"signal."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:194
msgid "Limiter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:196
msgid ""
"A limiter is similar to a compressor, but it's less flexible and designed to "
"prevent a signal's amplitude exceeding a given dB threshold. Adding a "
"limiter to the Master bus is a safeguard against clipping."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:201
msgid "LowPassFilter, LowShelfFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:203
msgid ""
"These are the most common filters, they cut frequencies above a specific "
"*Cutoff* frequency and can also resonate (boost frequencies close to the "
"*Cutoff* frequency). Low pass filters can be used to simulate \"muffled\" "
"sound. For instance, underwater sounds, sounds blocked by walls, or distant "
"sounds."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:209
msgid "NotchFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:211
msgid ""
"The opposite of the BandPassFilter, it removes a band of sound from the "
"frequency spectrum at a given *Cutoff* frequency."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:215
msgid "Panner"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:217
msgid ""
"The Panner allows the stereo balance of a signal to be adjusted between the "
"left and right channels (wear headphones to audition this effect)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:221
msgid "Phaser"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:223
msgid ""
"It probably does not make much sense to explain that this effect is formed "
"by two signals being dephased and cancelling each other out. You can make a "
"Darth Vader voice with it, or jet-like sounds."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:228
msgid "PitchShift"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:230
msgid ""
"This effect allows the adjustment of the signal's pitch independently of its "
"speed. All frequencies can be increased/decreased with minimal effect on "
"transients. PitchShift can be useful to create unusually high or deep voices."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:235
msgid "Record"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:237
msgid ""
"The Record effect allows audio passing through the bus to be written to a "
"file."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:240
msgid "Reverb"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:242
msgid ""
"Reverb simulates rooms of different sizes. It has adjustable parameters that "
"can be tweaked to obtain the sound of a specific room. Reverb is commonly "
"outputted from :ref:`Areas <class_Area>` (see :ref:`Reverb buses "
"<doc_audio_streams_reverb_buses>`), or to apply a \"chamber\" feel to all "
"sounds."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:249
msgid "SpectrumAnalyzer"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:251
msgid ""
"This effect doesn't alter audio, instead, you add this effect to buses you "
"want a spectrum analysis of. This would typically be used for audio "
"visualization. A demo project using this can be found `here <https://github."
"com/godotengine/godot-demo-projects/tree/master/audio/spectrum>`__."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:256
msgid "StereoEnhance"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:258
msgid ""
"This effect uses a few algorithms to enhance a signal's stereo spectrum."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:261
msgid "Automatic bus disabling"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:263
msgid ""
"There is no need to disable buses manually when not in use. Godot detects "
"that the bus has been silent for a few seconds and disables it (including "
"all effects)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:269
msgid "Disabled buses have a blue VU meter instead of a red-green one."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:272
msgid "Bus rearrangement"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:274
msgid ""
"Stream Players use bus names to identify a bus, which allows adding, "
"removing and moving buses around while the reference to them is kept. "
"However, if a bus is renamed, the reference will be lost and the Stream "
"Player will output to Master. This system was chosen because rearranging "
"buses is a more common process than renaming them."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:281
msgid "Default bus layout"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:283
msgid ""
"The default bus layout is automatically saved to the ``res://"
"default_bus_layout.tres`` file. Custom bus arrangements can be saved and "
"loaded from disk."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:4
msgid "Audio streams"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:9
msgid ""
"As you might have already read in :ref:`doc_audio_buses`, sound is sent to "
"each bus via an AudioStreamPlayer node. There are different kinds of "
"AudioStreamPlayers. Each one loads an AudioStream and plays it back."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:14
msgid "AudioStream"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:16
msgid ""
"An audio stream is an abstract object that emits sound. The sound can come "
"from many places, but is most commonly loaded from the filesystem. Audio "
"files such as WAV (``.wav``) or Ogg Vorbis (``.ogg``) can be loaded as "
"AudioStreams and placed inside an AudioStreamPlayer."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:21
msgid ""
"Here is a comparison of the two file types to help you choose the one that "
"fits your use case best:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:24
msgid ""
"WAV files are quite large, but use little CPU power to play back. Hundreds "
"of them can be played simultaneously with little impact on performance. This "
"format is usually best for short sound effects."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:27
msgid ""
"Ogg Vorbis files are much smaller, but use considerably more CPU power to "
"play back, so only a few can be played back at once (especially on mobile). "
"This format works well for music, long sound effect sequences, and voice at "
"relatively low bitrates."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:32
msgid ""
"Keep in mind Ogg Vorbis files don't contain looping information. If looping "
"an Ogg Vorbis file is desired, it must be set up using the import options:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:37
msgid ""
"There are other types of AudioStreamPlayer, such as AudioStreamRandomPitch. "
"This one makes a random adjustment to the sound's pitch every time it's "
"played back. This can be helpful for adding variation to sounds that are "
"played back often."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:43
msgid "AudioStreamPlayer"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:45
msgid ""
"This is the standard, non-positional stream player. It can play to any bus. "
"In 5.1 sound setups, it can send audio to stereo mix or front speakers."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:49
msgid "AudioStreamPlayer2D"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:51
msgid ""
"This is a variant of AudioStreamPlayer, but emits sound in a 2D positional "
"environment. When close to the left of the screen, the panning will go left. "
"When close to the right side, it will go right."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:57
msgid ""
"Area2Ds can be used to divert sound from any AudioStreamPlayer2Ds they "
"contain to specific buses. This makes it possible to create buses with "
"different reverb or sound qualities to handle action happening in a "
"particular parts of your game world."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:65
msgid "AudioStreamPlayer3D"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:67
msgid ""
"This is a variant of AudioStreamPlayer, but emits sound in a 3D positional "
"environment. Depending on the location of the player relative to the screen, "
"it can position sound in stereo, 5.1 or 7.1 depending on the chosen audio "
"setup."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:71
msgid ""
"Similar to AudioStreamPlayer2D, an Area can divert the sound to an audio bus."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:75
msgid ""
"Unlike for 2D, the 3D version of AudioStreamPlayer has a few more advanced "
"options:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:80
msgid "Reverb buses"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:82
msgid ""
"Godot allows for 3D audio streams that enter a specific Area node to send "
"dry and wet audio to separate buses. This is useful when you have several "
"reverb configurations for different types of rooms. This is done by enabling "
"this type of reverb in the **Reverb Bus** section of the Area's properties:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:89
msgid ""
"At the same time, a special bus layout is created where each area receives "
"the reverb info from each area. A Reverb effect needs to be created and "
"configured in each reverb bus to complete the setup for the desired effect:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:95
msgid ""
"The Area's **Reverb Bus** section also has a parameter named **Uniformity**. "
"Some types of rooms bounce sounds more than others (like a warehouse), so "
"reverberation can be heard almost uniformly across the room even though the "
"source may be far away. Playing around with this parameter can simulate that "
"effect."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:102
msgid "Doppler"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:104
msgid ""
"When the relative velocity between an emitter and listener changes, this is "
"perceived as an increase or decrease in the pitch of the emitted sound. "
"Godot can track velocity changes in the AudioStreamPlayer3D and Camera "
"nodes. Both nodes have this property, which must be enabled manually:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:111
msgid ""
"Enable it by setting it depending on how objects will be moved: use **Idle** "
"for objects moved using ``_process``, or **Physics** for objects moved using "
"``_physics_process``. The tracking will happen automatically."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:4
msgid "Sync the gameplay with audio and music"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:9
msgid ""
"In any application or game, sound and music playback will have a slight "
"delay. For games, this delay is often so small that it is negligible. Sound "
"effects will come out a few milliseconds after any play() function is "
"called. For music this does not matter as in most games it does not interact "
"with the gameplay."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:11
msgid ""
"Still, for some games (mainly, rhythm games), it may be required to "
"synchronize player actions with something happening in a song (usually in "
"sync with the BPM). For this, having more precise timing information for an "
"exact playback position is useful."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:13
msgid ""
"Achieving very low playback timing precision is difficult. This is because "
"many factors are at play during audio playback:"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:15
msgid ""
"Audio is mixed in chunks (not continuously), depending on the size of audio "
"buffers used (check latency in project settings)."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:16
msgid "Mixed chunks of audio are not played immediately."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:17
msgid "Graphics APIs display two or three frames late."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:18
msgid "When playing on TVs, some delay may be added due to image processing."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:20
msgid ""
"The most common way to reduce latency is to shrink the audio buffers (again, "
"by editing the latency setting in the project settings). The problem is that "
"when latency is too small, sound mixing will require considerably more CPU. "
"This increases the risk of skipping (a crack in sound because a mix callback "
"was lost)."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:22
msgid ""
"This is a common tradeoff, so Godot ships with sensible defaults that should "
"not need to be altered."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:24
msgid ""
"The problem, in the end, is not this slight delay but synchronizing graphics "
"and audio for games that require it. Beginning with Godot 3.2, some helpers "
"were added to obtain more precise playback timing."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:27
msgid "Using the system clock to sync"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:29
msgid ""
"As mentioned before, If you call :ref:`AudioStreamPlayer."
"play()<class_AudioStreamPlayer_method_play>`, sound will not begin "
"immediately, but when the audio thread processes the next chunk."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:31
msgid ""
"This delay can't be avoided but it can be estimated by calling :ref:"
"`AudioServer."
"get_time_to_next_mix()<class_AudioServer_method_get_time_to_next_mix>`."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:33
msgid ""
"The output latency (what happens after the mix) can also be estimated by "
"calling :ref:`AudioServer."
"get_output_latency()<class_AudioServer_method_get_output_latency>`."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:35
msgid ""
"Add these two and it's possible to guess almost exactly when sound or music "
"will begin playing in the speakers during *_process()*:"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:58
msgid ""
"In the long run, though, as the sound hardware clock is never exactly in "
"sync with the system clock, the timing information will slowly drift away."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:60
msgid ""
"For a rhythm game where a song begins and ends after a few minutes, this "
"approach is fine (and it's the recommended approach). For a game where "
"playback can last a much longer time, the game will eventually go out of "
"sync and a different approach is needed."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:63
msgid "Using the sound hardware clock to sync"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:65
msgid ""
"Using :ref:`AudioStreamPlayer."
"get_playback_position()<class_AudioStreamPlayer_method_get_playback_position>` "
"to obtain the current position for the song sounds ideal, but it's not that "
"useful as-is. This value will increment in chunks (every time the audio "
"callback mixed a block of sound), so many calls can return the same value. "
"Added to this, the value will be out of sync with the speakers too because "
"of the previously mentioned reasons."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:67
msgid ""
"To compensate for the \"chunked\" output, there is a function that can "
"help: :ref:`AudioServer."
"get_time_since_last_mix()<class_AudioServer_method_get_time_since_last_mix>`."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:70
msgid ""
"Adding the return value from this function to *get_playback_position()* "
"increases precision:"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:77
msgid ""
"To increase precision, subtract the latency information (how much it takes "
"for the audio to be heard after it was mixed):"
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:84
msgid ""
"The result may be a bit jittery due how multiple threads work. Just check "
"that the value is not less than in the previous frame (discard it if so). "
"This is also a less precise approach than the one before, but it will work "
"for songs of any length, or synchronizing anything (sound effects, as an "
"example) to music."
msgstr ""

#: ../../docs/tutorials/audio/sync_with_audio.rst:86
msgid "Here is the same code as before using this approach:"
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:4
msgid "Recording with microphone"
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:6
msgid ""
"Godot supports in-game audio recording for Windows, macOS, Linux, Android "
"and iOS."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:9
msgid ""
"A simple demo is included in the official demo projects and will be used as "
"support for this tutorial: `<https://github.com/godotengine/godot-demo-"
"projects/tree/master/audio/mic_record>`_."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:14
msgid "The structure of the demo"
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:16
msgid ""
"The demo consists of a single scene. This scene includes two major parts: "
"the GUI and the audio."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:19
msgid ""
"We will focus on the audio part. In this demo, a bus named ``Record`` with "
"the effect ``Record`` is created to handle the audio recording. An "
"``AudioStreamPlayer`` named ``AudioStreamRecord`` is used for recording."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:40
msgid ""
"The audio recording is handled by the :ref:`class_AudioEffectRecord` "
"resource which has three methods: :ref:`get_recording() "
"<class_AudioEffectRecord_method_get_recording>`, :ref:`is_recording_active() "
"<class_AudioEffectRecord_method_is_recording_active>`, and :ref:"
"`set_recording_active() "
"<class_AudioEffectRecord_method_set_recording_active>`."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:64
msgid ""
"At the start of the demo, the recording effect is not active. When the user "
"presses the ``RecordButton``, the effect is enabled with "
"``set_recording_active(true)``."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:68
msgid ""
"On the next button press, as ``effect.is_recording_active()`` is ``true``, "
"the recorded stream can be stored into the ``recording`` variable by calling "
"``effect.get_recording()``."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:86
msgid ""
"To playback the recording, you assign the recording as the stream of the "
"``AudioStreamPlayer`` and call ``play()``."
msgstr ""

#: ../../docs/tutorials/audio/recording_with_microphone.rst:97
msgid ""
"To save the recording, you call ``save_to_wav()`` with the path to a file. "
"In this demo, the path is defined by the user via a ``LineEdit`` input box."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:4
msgid "Physics introduction"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:6
msgid ""
"In game development, you often need to know when two objects in the game "
"intersect or come into contact. This is known as **collision detection**. "
"When a collision is detected, you typically want something to happen. This "
"is known as **collision response**."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:11
msgid ""
"Godot offers a number of collision objects in 2D and 3D to provide both "
"collision detection and response. Trying to decide which one to use for your "
"project can be confusing. You can avoid problems and simplify development if "
"you understand how each works and what their pros and cons are."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:18
msgid "Godot's four collision object types"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:19
msgid "How each collision object works"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:20
msgid "When and why to choose one type over another"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:22
msgid ""
"This document's examples will use 2D objects. Every 2D physics object and "
"collision shape has a direct equivalent in 3D and in most cases they work in "
"much the same way."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:27
msgid "Collision objects"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:29
msgid ""
"Godot offers four kinds of physics bodies, extending :ref:`CollisionObject2D "
"<class_CollisionObject2D>`:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:35
msgid ":ref:`Area2D <class_Area2D>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:32
msgid ""
"``Area2D`` nodes provide **detection** and **influence**. They can detect "
"when objects overlap and can emit signals when bodies enter or exit. An "
"``Area2D`` can also be used to override physics properties, such as gravity "
"or damping, in a defined area."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:37
msgid ""
"The other three bodies extend :ref:`PhysicsBody2D <class_PhysicsBody2D>`:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:43
msgid ":ref:`StaticBody2D <class_StaticBody2D>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:40
msgid ""
"A static body is one that is not moved by the physics engine. It "
"participates in collision detection, but does not move in response to the "
"collision. They are most often used for objects that are part of the "
"environment or that do not need to have any dynamic behavior."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:48
msgid ":ref:`RigidBody2D <class_RigidBody2D>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:46
msgid ""
"This is the node that implements simulated 2D physics. You do not control a "
"``RigidBody2D`` directly, but instead you apply forces to it (gravity, "
"impulses, etc.) and the physics engine calculates the resulting movement. :"
"ref:`Read more about using rigid bodies. <doc_rigid_body>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:52
msgid ":ref:`KinematicBody2D <class_KinematicBody2D>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:51
msgid ""
"A body that provides collision detection, but no physics. All movement and "
"collision response must be implemented in code."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:57
msgid ""
"A physics body can hold any number of :ref:`Shape2D <class_Shape2D>` objects "
"as children. These shapes are used to define the object's collision bounds "
"and to detect contact with other objects."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:61
msgid ""
"In order to detect collisions, at least one ``Shape2D`` must be assigned to "
"the object."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:64
msgid ""
"The most common way to assign a shape is by adding a :ref:`CollisionShape2D "
"<class_CollisionShape2D>` or :ref:`CollisionPolygon2D "
"<class_CollisionPolygon2D>` as a child of the object. These nodes allow you "
"to draw the shape directly in the editor workspace."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:68
msgid ""
"Be careful to never scale your collision shapes in the editor. The \"Scale\" "
"property in the Inspector should remain ``(1, 1)``. When changing the size "
"of the collision shape, you should always use the size handles, **not** the "
"``Node2D`` scale handles. Scaling a shape can result in unexpected collision "
"behavior."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:77
msgid "Physics process callback"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:79
msgid ""
"The physics engine may spawn multiple threads to improve performance, so it "
"can use up to a full frame to process physics. Because of this, the value of "
"a body's state variables such as ``position`` or ``linear velocity`` may not "
"be accurate for the current frame."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:84
msgid ""
"In order to avoid this inaccuracy, any code that needs to access a body's "
"properties should be run in the :ref:`Node._physics_process() "
"<class_Node_method__physics_process>` callback, which is called before each "
"physics step at a constant frame rate (60 times per second by default). This "
"method will be passed a ``delta`` parameter, which is a floating-point "
"number equal to the time passed in *seconds* since the last step. When using "
"the default 60 Hz physics update rate, it will typically be equal to "
"``0.01666...`` (but not always, see below)."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:94
msgid ""
"It's recommended to always use the ``delta`` parameter when relevant in your "
"physics calculations, so that the game behaves correctly if you change the "
"physics update rate or if the player's device can't keep up."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:99
msgid "Collision layers and masks"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:101
msgid ""
"One of the most powerful, but frequently misunderstood, collision features "
"is the collision layer system. This system allows you to build up complex "
"interactions between a variety of objects. The key concepts are **layers** "
"and **masks**. Each ``CollisionObject2D`` has 20 different physics layers it "
"can interact with."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:107
msgid "Let's look at each of the properties in turn:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:111
msgid "collision_layer"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:110
msgid ""
"This describes the layers that the object appears **in**. By default, all "
"bodies are on layer ``1``."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:116
msgid "collision_mask"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:114
msgid ""
"This describes what layers the body will **scan** for collisions. If an "
"object isn't in one of the mask layers, the body will ignore it. By default, "
"all bodies scan layer ``1``."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:118
msgid ""
"These properties can be configured via code, or by editing them in the "
"Inspector."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:120
msgid ""
"Keeping track of what you're using each layer for can be difficult, so you "
"may find it useful to assign names to the layers you're using. Names can be "
"assigned in Project Settings -> Layer Names."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:126
msgid "**Example:**"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:128
msgid ""
"You have four node types in your game: Walls, Player, Enemy, and Coin. Both "
"Player and Enemy should collide with Walls. The Player node should detect "
"collisions with both Enemy and Coin, but Enemy and Coin should ignore each "
"other."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:133
msgid ""
"Start by naming layers 1-4 \"walls\", \"player\", \"enemies\", and \"coins\" "
"and place each node type in its respective layer using the \"Layer\" "
"property. Then set each node's \"Mask\" property by selecting the layers it "
"should interact with. For example, the Player's settings would look like "
"this:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:142
msgid "Area2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:144
msgid ""
"Area nodes provide **detection** and **influence**. They can detect when "
"objects overlap and emit signals when bodies enter or exit. Areas can also "
"be used to override physics properties, such as gravity or damping, in a "
"defined area."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:149
msgid "There are three main uses for :ref:`Area2D <class_Area2D>`:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:151
msgid "Overriding physics parameters (such as gravity) in a given region."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:153
msgid ""
"Detecting when other bodies enter or exit a region or what bodies are "
"currently in a region."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:155
msgid "Checking other areas for overlap."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:157
msgid "By default, areas also receive mouse and touchscreen input."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:160
msgid "StaticBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:162
msgid ""
"A static body is one that is not moved by the physics engine. It "
"participates in collision detection, but does not move in response to the "
"collision. However, it can impart motion or rotation to a colliding body "
"**as if** it were moving, using its ``constant_linear_velocity`` and "
"``constant_angular_velocity`` properties."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:167
msgid ""
"``StaticBody2D`` nodes are most often used for objects that are part of the "
"environment or that do not need to have any dynamic behavior."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:170
msgid "Example uses for ``StaticBody2D``:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:172
msgid "Platforms (including moving platforms)"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:173
msgid "Conveyor belts"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:174
msgid "Walls and other obstacles"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:177
msgid "RigidBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:179
msgid ""
"This is the node that implements simulated 2D physics. You do not control a :"
"ref:`RigidBody2D <class_RigidBody2D>` directly. Instead, you apply forces to "
"it and the physics engine calculates the resulting movement, including "
"collisions with other bodies, and collision responses, such as bouncing, "
"rotating, etc."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:185
msgid ""
"You can modify a rigid body's behavior via  properties such as \"Mass\", "
"\"Friction\", or \"Bounce\", which can be set in the Inspector."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:188
msgid ""
"The body's behavior is also affected by the world's properties, as set in "
"`Project Settings -> Physics`, or by entering an :ref:`Area2D "
"<class_Area2D>` that is overriding the global physics properties."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:192
msgid ""
"When a rigid body is at rest and hasn't moved for a while, it goes to sleep. "
"A sleeping body acts like a static body, and its forces are not calculated "
"by the physics engine. The body will wake up when forces are applied, either "
"by a collision or via code."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:198
msgid "Rigid body modes"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:200
msgid "A rigid body can be set to one of four modes:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:202
msgid ""
"**Rigid** - The body behaves as a physical object. It collides with other "
"bodies and responds to forces applied to it. This is the default mode."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:203
msgid ""
"**Static** - The body behaves like a :ref:`StaticBody2D "
"<class_StaticBody2D>` and does not move."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:204
msgid "**Character** - Similar to \"Rigid\" mode, but the body cannot rotate."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:205
msgid ""
"**Kinematic** - The body behaves like a :ref:`KinematicBody2D "
"<class_KinematicBody2D>` and must be moved by code."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:208
msgid "Using RigidBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:210
msgid ""
"One of the benefits of using a rigid body is that a lot of behavior can be "
"had \"for free\" without writing any code. For example, if you were making "
"an \"Angry Birds\"-style game with falling blocks, you would only need to "
"create RigidBody2Ds and adjust their properties. Stacking, falling, and "
"bouncing would automatically be calculated by the physics engine."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:216
msgid ""
"However, if you do wish to have some control over the body, you should take "
"care - altering the ``position``, ``linear_velocity``, or other physics "
"properties of a rigid body can result in unexpected behavior. If you need to "
"alter any of the physics-related properties, you should use the :ref:"
"`_integrate_forces() <class_RigidBody2D_method__integrate_forces>` callback "
"instead of ``_physics_process()``. In this callback, you have access to the "
"body's :ref:`Physics2DDirectBodyState <class_Physics2DDirectBodyState>`, "
"which allows for safely changing properties and synchronizing them with the "
"physics engine."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:225
msgid "For example, here is the code for an \"Asteroids\" style spaceship:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:270
msgid ""
"Note that we are not setting the ``linear_velocity`` or ``angular_velocity`` "
"properties directly, but rather applying forces (``thrust`` and ``torque``) "
"to the body and letting the physics engine calculate the resulting movement."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:274
msgid ""
"When a rigid body goes to sleep, the ``_integrate_forces()`` function will "
"not be called. To override this behavior, you will need to keep the body "
"awake by creating a collision, applying a force to it, or by disabling the :"
"ref:`can_sleep <class_RigidBody2D_property_can_sleep>` property. Be aware "
"that this can have a negative effect on performance."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:281
msgid "Contact reporting"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:283
msgid ""
"By default, rigid bodies do not keep track of contacts, because this can "
"require a huge amount of memory if many bodies are in the scene. To enable "
"contact reporting, set the :ref:`contacts_reported "
"<class_RigidBody2D_property_contacts_reported>` property to a non-zero "
"value. The contacts can then be obtained via :ref:`Physics2DDirectBodyState."
"get_contact_count() "
"<class_Physics2DDirectBodyState_method_get_contact_count>` and related "
"functions."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:290
msgid ""
"Contact monitoring via signals can be enabled via the :ref:`contact_monitor "
"<class_RigidBody2D_property_contact_monitor>` property. See :ref:"
"`RigidBody2D <class_RigidBody2D>` for the list of available signals."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:295
msgid "KinematicBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:297
msgid ""
":ref:`KinematicBody2D <class_KinematicBody2D>` bodies detect collisions with "
"other bodies, but are not affected by physics properties like gravity or "
"friction. Instead, they must be controlled by the user via code. The physics "
"engine will not move a kinematic body."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:302
msgid ""
"When moving a kinematic body, you should not set its ``position`` directly. "
"Instead, you use the ``move_and_collide()`` or ``move_and_slide()`` methods. "
"These methods move the body along a given vector, and it will instantly stop "
"if a collision is detected with another body. After the body has collided, "
"any collision response must be coded manually."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:309
msgid "Kinematic collision response"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:311
msgid ""
"After a collision, you may want the body to bounce, to slide along a wall, "
"or to alter the properties of the object it hit. The way you handle "
"collision response depends on which method you used to move the "
"KinematicBody2D."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:316
msgid ":ref:`move_and_collide <class_KinematicBody2D_method_move_and_collide>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:318
msgid ""
"When using ``move_and_collide()``, the function returns a :ref:"
"`KinematicCollision2D <class_KinematicCollision2D>` object, which contains "
"information about the collision and the colliding body. You can use this "
"information to determine the response."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:323
msgid ""
"For example, if you want to find the point in space where the collision "
"occurred:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:354
msgid "Or to bounce off of the colliding object:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:383
msgid ":ref:`move_and_slide <class_KinematicBody2D_method_move_and_slide>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:385
msgid ""
"Sliding is a common collision response; imagine a player moving along walls "
"in a top-down game or running up and down slopes in a platformer. While it's "
"possible to code this response yourself after using ``move_and_collide()``, "
"``move_and_slide()`` provides a convenient way to implement sliding movement "
"without writing much code."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:391
msgid ""
"``move_and_slide()`` automatically includes the timestep in its calculation, "
"so you should **not** multiply the velocity vector by ``delta``."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:395
msgid ""
"For example, use the following code to make a character that can walk along "
"the ground (including slopes) and jump when standing on the ground:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:462
msgid ""
"See :ref:`doc_kinematic_character_2d` for more details on using "
"``move_and_slide()``, including a demo project with detailed code."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:4
msgid "RigidBody"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:7
msgid "What is a rigid body?"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:9
msgid ""
"A rigid body is one that is directly controlled by the physics engine in "
"order to simulate the behavior of physical objects. In order to define the "
"shape of the body, it must have one or more :ref:`Shape <class_Shape>` "
"objects assigned. Note that setting the position of these shapes will affect "
"the body's center of mass."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:13
msgid "How to control a rigid body"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:15
msgid ""
"A rigid body's behavior can be altered by setting its properties, such as "
"friction, mass, bounce, etc. These properties can be set in the Inspector or "
"via code. See :ref:`RigidBody <class_RigidBody>` for the full list of "
"properties and their effects."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:17
msgid ""
"There are several ways to control a rigid body's movement, depending on your "
"desired application."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:19
msgid ""
"If you only need to place a rigid body once, for example to set its initial "
"location, you can use the methods provided by the :ref:`Spatial "
"<class_Spatial>` node, such as ``set_global_transform()`` or ``look_at()``. "
"However, these methods cannot be called every frame or the physics engine "
"will not be able to correctly simulate the body's state. As an example, "
"consider a rigid body that you want to rotate so that it points towards "
"another object. A common mistake when implementing this kind of behavior is "
"to use ``look_at()`` every frame, which breaks the physics simulation. "
"Below, we'll demonstrate how to implement this correctly."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:22
msgid ""
"The fact that you can't use ``set_global_transform()`` or ``look_at()`` "
"methods doesn't mean that you can't have full control of a rigid body. "
"Instead, you can control it by using the ``_integrate_forces()`` callback. "
"In this method, you can add *forces*, apply *impulses*, or set the "
"*velocity* in order to achieve any movement you desire."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:25
msgid "The \"look at\" method"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:27
msgid ""
"As described above, using the Spatial node's ``look_at()`` method can't be "
"used each frame to follow a target. Here is a custom ``look_at()`` method "
"that will work reliably with rigid bodies:"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:69
msgid ""
"This method uses the rigid body's ``set_angular_velocity()`` method to "
"rotate the body. It first calculates the difference between the current and "
"desired angle and then adds the velocity needed to rotate by that amount in "
"one frame's time."
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:71
msgid ""
"This script will not work with rigid bodies in *character mode* because "
"then, the body's rotation is locked. In that case, you would have to rotate "
"the attached mesh node instead using the standard Spatial methods."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:4
msgid "Using Area2D"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:9
msgid ""
"Godot offers a number of collision objects to provide both collision "
"detection and response. Trying to decide which one to use for your project "
"can be confusing. You can avoid problems and simplify development if you "
"understand how each of them works and what their pros and cons are. In this "
"tutorial, we'll look at the :ref:`Area2D <class_Area2D>` node and show some "
"examples of how it can be used."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:15
#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:16
msgid ""
"This document assumes you're familiar with Godot's various physics bodies. "
"Please read :ref:`doc_physics_introduction` first."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:19
msgid "What is an area?"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:21
msgid ""
"An Area2D defines a region of 2D space. In this space you can detect other :"
"ref:`CollisionObject2D <class_CollisionObject2D>` nodes overlapping, "
"entering, and exiting. Areas also allow for overriding local physics "
"properties. We'll explore each of these functions below."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:27
msgid "Area properties"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:29
msgid "Areas have many properties you can use to customize their behavior."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:33
msgid ""
"The first eight properties are used to configure the area's physics override "
"behavior. We'll look at how to use those in the section below."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:36
msgid "*Monitoring* and *Monitorable* are used to enable and disable the area."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:38
msgid ""
"The \"Collision\" section is where you configure the area's collision "
"layer(s) and mask(s)."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:41
msgid ""
"The \"Audio Bus\" section allows you to override audio in the area, for "
"example to apply an audio effect when the player moves through."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:44
msgid ""
"Note that Area2D extends :ref:`CollisionObject2D <class_CollisionObject2D>`, "
"so it also provides properties inherited from that class, such as "
"``input_pickable``."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:48
msgid "Overlap detection"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:50
msgid ""
"Perhaps the most common use of Area2D nodes is for contact and overlap "
"detection. When you need to know that two objects have touched, but don't "
"need physical collision, you can use an area to notify you of the contact."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:54
msgid ""
"For example, let's say we're making a coin for the player to pick up. The "
"coin is not a solid object - the player can't stand on it or push it - we "
"just want it to disappear when the player touches it."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:58
msgid "Here's the node setup for the coin:"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:62
msgid ""
"To detect the overlap, we'll connect the appropriate signal on the Area2d. "
"Which signal to use depends on the player's node type. If the player is "
"another area, use ``area_entered``. However, let's assume our player is a "
"``KinematicBody2D`` (and therefore a ``CollisionObject2D`` type), so we'll "
"connect the ``body_entered`` signal."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:68
msgid ""
"If you're not familiar with using signals, see :ref:`doc_signals` for an "
"introduction."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:90
msgid "Now our player can collect the coins!"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:92
msgid "Some other usage examples:"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:94
msgid ""
"Areas are great for bullets and other projectiles that hit and deal damage, "
"but don't need any other physics such as bouncing."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:95
msgid ""
"Use a large circular area around an enemy to define its \"detect\" radius. "
"When the player is outside the area, the enemy can't \"see\" it."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:96
msgid ""
"\"Security cameras\" - In a large level with multiple cameras, attach areas "
"to each camera and activate them when the player enters."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:98
msgid ""
"See the :ref:`doc_your_first_game` for an example of using Area2D in a game."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:101
msgid "Area influence"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:103
msgid ""
"The second major use for area nodes is to alter physics. By default, the "
"area won't do this, but you can enable this with the *Space Override* "
"property. When areas overlap, they are processed in *Priority* order (higher "
"priority areas are processed first). There are four options for override:"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:108
msgid ""
"*Combine* - The area adds its values to what has been calculated so far."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:109
msgid ""
"*Replace* - The area replaces physics properties, and lower priority areas "
"are ignored."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:110
msgid ""
"*Combine-Replace* - The area adds its gravity/damping values to whatever has "
"been calculated so far (in priority order), ignoring any lower priority "
"areas."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:111
msgid ""
"*Replace-Combine* - The area replaces any gravity/damping calculated so far, "
"but keeps calculating the rest of the areas."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:113
msgid ""
"Using these properties, you can create very complex behavior with multiple "
"overlapping areas."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:116
msgid "The physics properties that can be overridden are:"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:118
msgid "*Gravity* - Gravity's strength inside the area."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:119
msgid ""
"*Gravity Vec* - Gravity's direction. This vector does not need to be "
"normalized."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:120
msgid ""
"*Linear Damp* - How quickly objects stop moving - linear velocity lost per "
"second."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:121
msgid ""
"*Angular Damp* - How quickly objects stop spinning - angular velocity lost "
"per second."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:124
msgid "Point gravity"
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:126
msgid ""
"The *Gravity Point* property allows you to create an \"attractor\". Gravity "
"in the area will be calculated towards a point, given by the *Gravity Vec* "
"property. Values are relative to the Area2D, so for example using ``(0, 0)`` "
"will attract objects to the center of the area."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:134
msgid ""
"The example project attached below has three areas demonstrating physics "
"override."
msgstr ""

#: ../../docs/tutorials/physics/using_area_2d.rst:139
msgid ""
"You can download this project here: :download:`using_area_2d.zip <files/"
"using_area_2d.zip>`"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:4
msgid "Using KinematicBody2D"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:9
msgid ""
"Godot offers several collision objects to provide both collision detection "
"and response. Trying to decide which one to use for your project can be "
"confusing. You can avoid problems and simplify development if you understand "
"how each of them works and what their pros and cons are. In this tutorial, "
"we'll look at the :ref:`KinematicBody2D <class_KinematicBody2D>` node and "
"show some examples of how to use it."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:20
msgid "What is a kinematic body?"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:22
msgid ""
"``KinematicBody2D`` is for implementing bodies that are controlled via code. "
"Kinematic bodies detect collisions with other bodies when moving, but are "
"not affected by engine physics properties, like gravity or friction. While "
"this means that you have to write some code to create their behavior, it "
"also means you have more precise control over how they move and react."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:28
msgid ""
"A `KinematicBody2D` can be affected by gravity and other forces, but you "
"must calculate the movement in code. The physics engine will not move a "
"`KinematicBody2D`."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:33
msgid "Movement and collision"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:35
msgid ""
"When moving a ``KinematicBody2D``, you should not set its ``position`` "
"property directly. Instead, you use the ``move_and_collide()`` or "
"``move_and_slide()`` methods. These methods move the body along a given "
"vector and instantly stop if a collision is detected with another body. "
"After a KinematicBody2D has collided, any *collision response* must be coded "
"manually."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:41
msgid ""
"You should only do Kinematic body movement in the ``_physics_process()`` "
"callback."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:43
msgid ""
"The two movement methods serve different purposes, and later in this "
"tutorial, you'll see examples of how they work."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:47
msgid "``move_and_collide``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:49
msgid ""
"This method takes one parameter: a :ref:`Vector2 <class_Vector2>` indicating "
"the body's relative movement. Typically, this is your velocity vector "
"multiplied by the frame timestep (``delta``). If the engine detects a "
"collision anywhere along this vector, the body will immediately stop moving. "
"If this happens, the method will return a :ref:`KinematicCollision2D "
"<class_KinematicCollision2D>` object."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:55
msgid ""
"``KinematicCollision2D`` is an object containing data about the collision "
"and the colliding object. Using this data, you can calculate your collision "
"response."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:60
msgid "``move_and_slide``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:62
msgid ""
"The ``move_and_slide()`` method is intended to simplify the collision "
"response in the common case where you want one body to slide along the "
"other. It is especially useful in platformers or top-down games, for example."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:66
msgid ""
"``move_and_slide()`` automatically calculates frame-based movement using "
"``delta``. Do *not* multiply your velocity vector by ``delta`` before "
"passing it to ``move_and_slide()``."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:70
msgid ""
"In addition to the velocity vector, ``move_and_slide()`` takes a number of "
"other parameters allowing you to customize the slide behavior:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:73
msgid "``up_direction`` - *default value:* ``Vector2( 0, 0 )``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:75
msgid ""
"This parameter allows you to define what surfaces the engine should consider "
"being the floor. Setting this lets you use the ``is_on_floor()``, "
"``is_on_wall()``, and ``is_on_ceiling()`` methods to detect what type of "
"surface the body is in contact with. The default value means that all "
"surfaces are considered walls."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:80
msgid "``stop_on_slope`` - *default value:* ``false``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:82
msgid ""
"This parameter prevents a body from sliding down slopes when standing still."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:84
msgid "``max_slides`` - *default value:* ``4``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:86
msgid ""
"This parameter is the maximum number of collisions before the body stops "
"moving. Setting it too low may prevent movement entirely."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:89
msgid ""
"``floor_max_angle`` - *default value:* ``0.785398`` (in radians, equivalent "
"to ``45`` degrees)"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:91
msgid ""
"This parameter is the maximum angle before a surface is no longer considered "
"a \"floor.\""
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:93
msgid "``infinite_inertia`` - *default value:* ``true``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:95
msgid ""
"When this parameter is ``true``, the body can push :ref:`RigidBody2D "
"<class_RigidBody2D>` nodes, ignoring their mass, but won't detect collisions "
"with them. If it's ``false`` the body will collide with rigid bodies and "
"stop."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:100
msgid "``move_and_slide_with_snap``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:102
msgid ""
"This method adds some additional functionality to ``move_and_slide()`` by "
"adding the ``snap`` parameter. As long as this vector is in contact with the "
"ground, the body will remain attached to the surface. Note that this means "
"you must disable snapping when jumping, for example. You can do this either "
"by setting ``snap`` to ``Vector2.ZERO`` or by using ``move_and_slide()`` "
"instead."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:110
msgid "Detecting collisions"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:112
msgid ""
"When using ``move_and_collide()`` the function returns a "
"``KinematicCollision2D`` directly, and you can use this in your code."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:115
msgid ""
"When using ``move_and_slide()`` it's possible to have multiple collisions "
"occur, as the slide response is calculated. To process these collisions, use "
"``get_slide_count()`` and ``get_slide_collision()``:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:133
msgid ""
"See :ref:`KinematicCollision2D <class_KinematicCollision2D>` for details on "
"what collision data is returned."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:137
msgid "Which movement method to use?"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:139
msgid ""
"A common question from new Godot users is: \"How do you decide which "
"movement function to use?\" Often, the response is to use "
"``move_and_slide()`` because it's \"simpler,\" but this is not necessarily "
"the case. One way to think of it is that ``move_and_slide()`` is a special "
"case, and ``move_and_collide()`` is more general. For example, the following "
"two code snippets result in the same collision response:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:170
msgid ""
"Anything you do with ``move_and_slide()`` can also be done with "
"``move_and_collide()``, but it might take a little more code. However, as "
"we'll see in the examples below, there are cases where ``move_and_slide()`` "
"doesn't provide the response you want."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:174
msgid ""
"In the example above, we assign the velocity that ``move_and_slide()`` "
"returns back into the ``velocity`` variable. This is because when the "
"character collides with the environment, the function recalculates the speed "
"internally to reflect the slowdown."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:179
msgid ""
"For example, if your character fell on the floor, you don't want it to "
"accumulate vertical speed due to the effect of gravity. Instead, you want "
"its vertical speed to reset to zero."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:183
msgid ""
"``move_and_slide()`` may also recalculate the kinematic body's velocity "
"several times in a loop as, to produce a smooth motion, it moves the "
"character and collides up to five times by default. At the end of the "
"process, the function returns the character's new velocity that we can store "
"in our ``velocity`` variable, and use on the next frame."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:192
msgid ""
"To see these examples in action, download the sample project: :download:"
"`using_kinematic2d.zip <files/using_kinematic2d.zip>`."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:196
msgid "Movement and walls"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:198
msgid ""
"If you've downloaded the sample project, this example is in \"BasicMovement."
"tscn\"."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:200
msgid ""
"For this example, add a ``KinematicBody2D`` with two children: a ``Sprite`` "
"and a ``CollisionShape2D``. Use the Godot \"icon.png\" as the Sprite's "
"texture (drag it from the Filesystem dock to the *Texture* property of the "
"``Sprite``). In the ``CollisionShape2D``'s *Shape* property, select \"New "
"RectangleShape2D\" and size the rectangle to fit over the sprite image."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:206
msgid ""
"See :ref:`doc_2d_movement` for examples of implementing 2D movement schemes."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:208
msgid "Attach a script to the KinematicBody2D and add the following code:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:271
msgid ""
"Run this scene and you'll see that ``move_and_collide()`` works as expected, "
"moving the body along the velocity vector. Now let's see what happens when "
"you add some obstacles. Add a :ref:`StaticBody2D <class_StaticBody2D>` with "
"a rectangular collision shape. For visibility, you can use a sprite, a "
"Polygon2D, or turn on \"Visible Collision Shapes\" from the \"Debug\" menu."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:277
msgid ""
"Run the scene again and try moving into the obstacle. You'll see that the "
"``KinematicBody2D`` can't penetrate the obstacle. However, try moving into "
"the obstacle at an angle and you'll find that the obstacle acts like glue - "
"it feels like the body gets stuck."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:281
msgid ""
"This happens because there is no *collision response*. "
"``move_and_collide()`` stops the body's movement when a collision occurs. We "
"need to code whatever response we want from the collision."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:285
msgid ""
"Try changing the function to ``move_and_slide(velocity)`` and running again. "
"Note that we removed ``delta`` from the velocity calculation."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:288
msgid ""
"``move_and_slide()`` provides a default collision response of sliding the "
"body along the collision object. This is useful for a great many game types, "
"and may be all you need to get the behavior you want."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:293
msgid "Bouncing/reflecting"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:295
msgid ""
"What if you don't want a sliding collision response? For this example "
"(\"BounceandCollide.tscn\" in the sample project), we have a character "
"shooting bullets and we want the bullets to bounce off the walls."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:299
msgid ""
"This example uses three scenes. The main scene contains the Player and "
"Walls. The Bullet and Wall are separate scenes so that they can be instanced."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:302
msgid ""
"The Player is controlled by the `w` and `s` keys for forward and back. "
"Aiming uses the mouse pointer. Here is the code for the Player, using "
"``move_and_slide()``:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:389
msgid "And the code for the Bullet:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:451
msgid ""
"The action happens in ``_physics_process()``. After using "
"``move_and_collide()``, if a collision occurs, a ``KinematicCollision2D`` "
"object is returned (otherwise, the return is ``Nil``)."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:455
msgid ""
"If there is a returned collision, we use the ``normal`` of the collision to "
"reflect the bullet's ``velocity`` with the ``Vector2.bounce()`` method."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:458
msgid ""
"If the colliding object (``collider``) has a ``hit`` method, we also call "
"it. In the example project, we've added a flashing color effect to the Wall "
"to demonstrate this."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:465
msgid "Platformer movement"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:467
msgid ""
"Let's try one more popular example: the 2D platformer. ``move_and_slide()`` "
"is ideal for quickly getting a functional character controller up and "
"running. If you've downloaded the sample project, you can find this in "
"\"Platformer.tscn\"."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:471
msgid ""
"For this example, we'll assume you have a level made of ``StaticBody2D`` "
"objects. They can be any shape and size. In the sample project, we're using :"
"ref:`Polygon2D <class_Polygon2D>` to create the platform shapes."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:475
msgid "Here's the code for the player body:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:556
msgid ""
"When using ``move_and_slide()``, the function returns a vector representing "
"the movement that remained after the slide collision occurred. Setting that "
"value back to the character's ``velocity`` allows us to move up and down "
"slopes smoothly. Try removing ``velocity =`` and see what happens if you "
"don't do this."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:561
msgid ""
"Also note that we've added ``Vector2(0, -1)`` as the floor normal. This "
"vector points straight upward. As a result, if the character collides with "
"an object that has this normal, it will be considered a floor."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:565
msgid ""
"Using the floor normal allows us to make jumping work, using "
"``is_on_floor()``. This function will only return ``true`` after a "
"``move_and_slide()`` collision where the colliding body's normal is within "
"45 degrees of the given floor vector. You can control the maximum angle by "
"setting ``floor_max_angle``."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:570
msgid ""
"This angle also allows you to implement other features like wall jumps using "
"``is_on_wall()``, for example."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:4
msgid "Ray-casting"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:9
msgid ""
"One of the most common tasks in game development is casting a ray (or custom "
"shaped object) and checking what it hits. This enables complex behaviors, "
"AI, etc. to take place. This tutorial will explain how to do this in 2D and "
"3D."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:14
msgid ""
"Godot stores all the low level game information in servers, while the scene "
"is just a frontend. As such, ray casting is generally a lower-level task. "
"For simple raycasts, node such as :ref:`RayCast <class_RayCast>` and :ref:"
"`RayCast2D <class_RayCast2D>` will work, as they will return every frame "
"what the result of a raycast is."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:21
msgid ""
"Many times, though, ray-casting needs to be a more interactive process so a "
"way to do this by code must exist."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:25
msgid "Space"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:27
msgid ""
"In the physics world, Godot stores all the low level collision and physics "
"information in a *space*. The current 2d space (for 2D Physics) can be "
"obtained by accessing :ref:`CanvasItem.get_world_2d().space "
"<class_CanvasItem_method_get_world_2d>`. For 3D, it's :ref:`Spatial."
"get_world().space <class_Spatial_method_get_world>`."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:33
msgid ""
"The resulting space :ref:`RID <class_RID>` can be used in :ref:"
"`PhysicsServer <class_PhysicsServer>` and :ref:`Physics2DServer "
"<class_Physics2DServer>` respectively for 3D and 2D."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:38
msgid "Accessing space"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:40
msgid ""
"Godot physics runs by default in the same thread as game logic, but may be "
"set to run on a separate thread to work more efficiently. Due to this, the "
"only time accessing space is safe is during the :ref:`Node."
"_physics_process() <class_Node_method__physics_process>` callback. Accessing "
"it from outside this function may result in an error due to space being "
"*locked*."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:47
msgid ""
"To perform queries into physics space, the :ref:`Physics2DDirectSpaceState "
"<class_Physics2DDirectSpaceState>` and :ref:`PhysicsDirectSpaceState "
"<class_PhysicsDirectSpaceState>` must be used."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:52
msgid "Use the following code in 2D:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:69
msgid "Or more directly:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:84
msgid "And in 3D:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:100
msgid "Raycast query"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:102
msgid ""
"For performing a 2D raycast query, the method :ref:"
"`Physics2DDirectSpaceState.intersect_ray() "
"<class_Physics2DDirectSpaceState_method_intersect_ray>` may be used. For "
"example:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:123
msgid ""
"The result is a dictionary. If the ray didn't hit anything, the dictionary "
"will be empty. If it did hit something, it will contain collision "
"information:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:137
msgid ""
"The ``result`` dictionary when a collision occurs contains the following "
"data:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:152
msgid "The data is similar in 3D space, using Vector3 coordinates."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:155
msgid "Collision exceptions"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:157
msgid ""
"A common use case for ray casting is to enable a character to gather data "
"about the world around it. One problem with this is that the same character "
"has a collider, so the ray will only detect its parent's collider, as shown "
"in the following image:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:164
msgid ""
"To avoid self-intersection, the ``intersect_ray()`` function can take an "
"optional third parameter which is an array of exceptions. This is an example "
"of how to use it from a KinematicBody2D or any other collision object node:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:189
msgid "The exceptions array can contain objects or RIDs."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:192
msgid "Collision Mask"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:194
msgid ""
"While the exceptions method works fine for excluding the parent body, it "
"becomes very inconvenient if you need a large and/or dynamic list of "
"exceptions. In this case, it is much more efficient to use the collision "
"layer/mask system."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:198
msgid ""
"The optional fourth argument for ``intersect_ray()`` is a collision mask. "
"For example, to use the same mask as the parent body, use the "
"``collision_mask`` member variable:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:226
msgid "3D ray casting from screen"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:228
msgid ""
"Casting a ray from screen to 3D physics space is useful for object picking. "
"There is not much need to do this because :ref:`CollisionObject "
"<class_CollisionObject>` has an \"input_event\" signal that will let you "
"know when it was clicked, but in case there is any desire to do it manually, "
"here's how."
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:234
msgid ""
"To cast a ray from the screen, you need a :ref:`Camera <class_Camera>` node. "
"A ``Camera`` can be in two projection modes: perspective and orthogonal. "
"Because of this, both the ray origin and direction must be obtained. This is "
"because ``origin`` changes in orthogonal mode, while ``normal`` changes in "
"perspective mode:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:242
msgid "To obtain it using a camera, the following code can be used:"
msgstr ""

#: ../../docs/tutorials/physics/ray-casting.rst:270
msgid ""
"Remember that during ``_input()``, the space may be locked, so in practice "
"this query should be run in ``_physics_process()``."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:4
msgid "Ragdoll system"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:9
msgid ""
"Since version 3.1, Godot supports ragdoll physics. Ragdolls rely on physics "
"simulation to create realistic procedural animation. They are used for death "
"animations in many games."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:11
msgid ""
"In this tutorial, we will be using the Platformer3D demo to set up a ragdoll."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:13
msgid ""
"You can download the Platformer3D demo on `GitHub <https://github.com/"
"godotengine/godot-demo-projects/tree/master/3d/platformer>`_ or using the "
"`Asset Library <https://godotengine.org/asset-library/asset/125>`_."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:16
msgid "Setting up the ragdoll"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:19
msgid "Creating physical bones"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:21
msgid ""
"Like many other features in the engine, there is a node to set up a ragdoll: "
"the :ref:`PhysicalBone <class_PhysicalBone>` node. To simplify the setup, "
"you can generate ``PhysicalBone`` nodes with the \"Create physical skeleton"
"\" feature in the skeleton node."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:23
msgid ""
"Open the platformer demo in Godot, and then the Robi scene. Select the "
"``Skeleton`` node. A skeleton button appears on the top bar menu:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:27
msgid ""
"Click it and select the ``Create physical skeleton`` option. Godot will "
"generate ``PhysicalBone`` nodes and collision shapes for each bone in the "
"skeleton and pin joints to connect them together:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:31
msgid ""
"Some of the generated bones aren't necessary: the ``MASTER`` bone for "
"example. So we're going to clean up the skeleton by removing them."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:34
msgid "Cleaning up the skeleton"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:36
msgid ""
"Each ``PhysicalBone`` the engine needs to simulate has a performance cost, "
"so you want to remove every bone that is too small to make a difference in "
"the simulation, as well as all utility bones."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:38
msgid ""
"For example, if we take a humanoid, you do not want to have physical bones "
"for each finger. You can use a single bone for the entire hand instead, or "
"one for the palm, one for the thumb, and a last one for the other four "
"fingers."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:40
msgid ""
"Remove these physical bones: ``MASTER``, ``waist``, ``neck``, "
"``headtracker``. This gives us an optimized skeleton and makes it easier to "
"control the ragdoll."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:43
msgid "Collision shape adjustment"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:45
msgid ""
"The next task is adjusting the collision shape and the size of physical "
"bones to match the part of the body that each bone should simulate."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:50
msgid "Joints adjustment"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:52
msgid ""
"Once you adjusted the collision shapes, your ragdoll is almost ready. You "
"just want to adjust the pin joints to get a better simulation. "
"``PhysicalBone`` nodes have an unconstrained pin joint assigned to them by "
"default. To change the pin joint, select the ``PhysicalBone`` and change the "
"constraint type in the ``Joint`` section. There, you can change the "
"constraint's orientation and its limits."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:56
msgid "This is the final result:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:61
msgid "Simulating the ragdoll"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:63
msgid ""
"The ragdoll is now ready to use. To start the simulation and play the "
"ragdoll animation, you need to call the ``physical_bones_start_simulation`` "
"method. Attach a script to the skeleton node and call the method in the "
"``_ready`` method:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:71
msgid ""
"To stop the simulation, call the ``physical_bones_stop_simulation()`` method."
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:75
msgid ""
"You can also limit the simulation to only a few bones. To do so, pass the "
"bone names as a parameter. Here's an example of partial ragdoll simulation:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:80
msgid "Collision layer and mask"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:82
msgid ""
"Make sure to set up your collision layers and masks properly so the "
"``KinematicBody``'s capsule doesn't get in the way of the physics simulation:"
msgstr ""

#: ../../docs/tutorials/physics/ragdoll_system.rst:86
msgid "For more information, read :ref:`doc_physics_introduction`"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:4
msgid "Kinematic character (2D)"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:9
msgid ""
"Yes, the name sounds strange. \"Kinematic Character\". What is that? The "
"reason for the name is that, when physics engines came out, they were called "
"\"Dynamics\" engines (because they dealt mainly with collision responses). "
"Many attempts were made to create a character controller using the dynamics "
"engines, but it wasn't as easy as it seemed. Godot has one of the best "
"implementations of dynamic character controller you can find (as it can be "
"seen in the 2d/platformer demo), but using it requires a considerable level "
"of skill and understanding of physics engines (or a lot of patience with "
"trial and error)."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:19
msgid ""
"Some physics engines, such as Havok seem to swear by dynamic character "
"controllers as the best option, while others (PhysX) would rather promote "
"the kinematic one."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:23
msgid "So, what is the difference?:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:25
msgid ""
"A **dynamic character controller** uses a rigid body with an infinite "
"inertia tensor. It's a rigid body that can't rotate. Physics engines always "
"let objects move and collide, then solve their collisions all together. This "
"makes dynamic character controllers able to interact with other physics "
"objects seamlessly, as seen in the platformer demo. However, these "
"interactions are not always predictable. Collisions can take more than one "
"frame to be solved, so a few collisions may seem to displace a tiny bit. "
"Those problems can be fixed, but require a certain amount of skill."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:34
msgid ""
"A **kinematic character controller** is assumed to always begin in a non-"
"colliding state, and will always move to a non-colliding state. If it starts "
"in a colliding state, it will try to free itself like rigid bodies do, but "
"this is the exception, not the rule. This makes their control and motion a "
"lot more predictable and easier to program. However, as a downside, they "
"can't directly interact with other physics objects, unless done by hand in "
"code."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:42
msgid ""
"This short tutorial will focus on the kinematic character controller. "
"Basically, the old-school way of handling collisions (which is not "
"necessarily simpler under the hood, but well hidden and presented as a nice "
"and simple API)."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:48
msgid "Physics process"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:50
msgid ""
"To manage the logic of a kinematic body or character, it is always advised "
"to use physics process, because it's called before physics step and its "
"execution is in sync with physics server, also it is called the same amount "
"of times per second, always. This makes physics and motion calculation work "
"in a more predictable way than using regular process, which might have "
"spikes or lose precision if the frame rate is too high or too low."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:81
msgid ""
"To have something to test, here's the scene (from the tilemap tutorial): :"
"download:`kbscene.zip <files/kbscene.zip>`. We'll be creating a new scene "
"for the character. Use the robot sprite and create a scene like this:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:87
msgid ""
"You'll notice that there's a warning icon next to our CollisionShape2D node; "
"that's because we haven't defined a shape for it. Create a new CircleShape2D "
"in the shape property of CollisionShape2D. Click on <CircleShape2D> to go to "
"the options for it, and set the radius to 30:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:94
msgid ""
"**Note: As mentioned before in the physics tutorial, the physics engine "
"can't handle scale on most types of shapes (only collision polygons, planes "
"and segments work), so always change the parameters (such as radius) of the "
"shape instead of scaling it. The same is also true for the kinematic/rigid/"
"static bodies themselves, as their scale affects the shape scale.**"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:101
msgid ""
"Now, create a script for the character, the one used as an example above "
"should work as a base."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:104
msgid ""
"Finally, instance that character scene in the tilemap, and make the map "
"scene the main one, so it runs when pressing play."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:110
msgid "Moving the kinematic character"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:112
msgid ""
"Go back to the character scene, and open the script, the magic begins now! "
"Kinematic body will do nothing by default, but it has a useful function "
"called :ref:`KinematicBody2D.move_and_collide() "
"<class_KinematicBody2D_method_move_and_collide>`. This function takes a :ref:"
"`Vector2 <class_Vector2>` as an argument, and tries to apply that motion to "
"the kinematic body. If a collision happens, it stops right at the moment of "
"the collision."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:120
msgid "So, let's move our sprite downwards until it hits the floor:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:144
msgid ""
"The result is that the character will move, but stop right when hitting the "
"floor. Pretty cool, huh?"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:147
msgid ""
"The next step will be adding gravity to the mix, this way it behaves a "
"little more like a regular game character:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:183
msgid ""
"Now the character falls smoothly. Let's make it walk to the sides, left and "
"right when touching the directional keys. Remember that the values being "
"used (for speed at least) are pixels/second."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:187
msgid "This adds simple walking support by pressing left and right:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:252
msgid "And give it a try."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:254
msgid ""
"This is a good starting point for a platformer. A more complete demo can be "
"found in the demo zip distributed with the engine, or in the https://github."
"com/godotengine/godot-demo-projects/tree/master/2d/kinematic_character."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:4
msgid "SoftBody"
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:6
msgid ""
"Soft bodies (or *soft-body dynamics*) simulate movement, changing shape and "
"other physical properties of deformable objects. This can for example be "
"used to simulate cloth or to create more realistic characters."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:10
msgid "Basic set-up"
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:12
msgid ""
"A :ref:`SoftBody <class_SoftBody>` node is used for soft body simulations."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:14
msgid "We will create a bouncy cube to demonstrate the setup of a soft body."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:16
msgid ""
"Create a new scene with a ``Spatial`` node as root. Then, create a "
"``Softbody`` node. Add a ``CubeMesh`` in the ``mesh`` property of the node "
"in the inspector and increase the subdivision of the mesh for simulation."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:20
msgid ""
"Set the parameters to obtain the type of soft body you aim for. Try to keep "
"the ``Simulation Precision`` above 5, otherwise, the soft body may collapse."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:24
msgid ""
"Handle some parameters with care, as some value can lead to strange results. "
"For example, if the shape is not completely closed and you set pressure to "
"more than 0, the softbody will fly around like a plastic bag under strong "
"wind."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:26
msgid "Play the scene to view the simulation."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:28
msgid ""
"To improve the simulation's result, increase the ``Simulation Precision``, "
"this will give significant improvement at the cost of performance."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:31
msgid "Cloak simulation"
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:33
msgid "Let's make a cloak in the Platformer3D demo."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:35
msgid ""
"You can download the Platformer3D demo on `GitHub <https://github.com/"
"godotengine/godot-demo-projects/tree/master/3d/platformer>` or `the Asset "
"Library <https://godotengine.org/asset-library/asset/125>`_."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:37
msgid ""
"Open the ``Player`` scene, add a ``SoftBody`` node and assign a "
"``PlaneMesh`` to it."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:39
msgid ""
"Open the ``PlaneMesh`` properties and set the size(x: 0.5 y: 1) then set "
"``Subdivide Width`` and ``Subdivide Depth`` to 5. Adjust the ``SoftBody``'s "
"position. You should end up with something like this:"
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:43
msgid "Subdivision generates a more tessellated mesh for better simulations."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:45
msgid ""
"Add a :ref:`BoneAttachment <class_BoneAttachment>` node under the skeleton "
"node and select the Neck bone to attach the cloak to the character skeleton."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:47
msgid ""
"``BoneAttachment`` node is to attach objects to a bone of a armature. The "
"attached object will follow the bone's movement, weapon of a character can "
"be attached this way."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:51
msgid ""
"To create pinned joints, select the upper vertices in the ``SoftBody`` node:"
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:55
msgid ""
"The pinned joints can be find in ``SoftBody``'s ``Attachments`` property, "
"choose the ``BoneAttachment`` as the ``SpatialAttachment`` for each pinned "
"joints, the pinned joints are now attached to the neck."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:59
msgid ""
"Last step is to avoid clipping by adding the Kinematic Body `Player` to "
"``Parent Collision Ignore`` of the ``SoftBody``."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:63
msgid "Play the scene and the cloak should simulate correctly."
msgstr ""

#: ../../docs/tutorials/physics/soft_body.rst:67
msgid ""
"This covers the basic settings of softbody, experiment with the parameters "
"to achieve the effect you are aiming for when making your game."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:4
msgid "Vector math"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:9
msgid ""
"This tutorial is a short and practical introduction to linear algebra as it "
"applies to game development. Linear algebra is the study of vectors and "
"their uses. Vectors have many applications in both 2D and 3D development and "
"Godot uses them extensively. Developing a good understanding of vector math "
"is essential to becoming a strong game developer."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:15
msgid ""
"This tutorial is **not** a formal textbook on linear algebra. We will only "
"be looking at how it is applied to game development. For a broader look at "
"the mathematics, see https://www.khanacademy.org/math/linear-algebra"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:21
msgid "Coordinate systems (2D)"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:23
msgid ""
"In 2D space, coordinates are defined using a horizontal axis (``x``) and a "
"vertical axis (``y``). A particular position in 2D space is written as a "
"pair of values such as ``(4, 3)``."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:29
msgid ""
"If you're new to computer graphics, it might seem odd that the positive "
"``y`` axis points **downwards** instead of upwards, as you probably learned "
"in math class. However, this is common in most computer graphics "
"applications."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:34
msgid ""
"Any position in the 2D plane can be identified by a pair of numbers in this "
"way. However, we can also think of the position ``(4, 3)`` as an **offset** "
"from the ``(0, 0)`` point, or **origin**. Draw an arrow pointing from the "
"origin to the point:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:41
msgid ""
"This is a **vector**. A vector represents a lot of useful information. As "
"well as telling us that the point is at ``(4, 3)``, we can also think of it "
"as an angle ``θ`` and a length (or magnitude) ``m``. In this case, the arrow "
"is a **position vector** - it denotes a position in space, relative to the "
"origin."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:47
msgid ""
"A very important point to consider about vectors is that they only represent "
"**relative** direction and magnitude. There is no concept of a vector's "
"position. The following two vectors are identical:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:53
msgid ""
"Both vectors represent a point 4 units to the right and 3 units below some "
"starting point. It does not matter where on the plane you draw the vector, "
"it always represents a relative direction and magnitude."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:58
msgid "Vector operations"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:60
msgid ""
"You can use either method (x and y coordinates or angle and magnitude) to "
"refer to a vector, but for convenience, programmers typically use the "
"coordinate notation. For example, in Godot, the origin is the top-left "
"corner of the screen, so to place a 2D node named ``Node2D`` 400 pixels to "
"the right and 300 pixels down, use the following code:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:76
msgid ""
"Godot supports both :ref:`Vector2 <class_Vector2>` and :ref:`Vector3 "
"<class_Vector3>` for 2D and 3D usage, respectively. The same mathematical "
"rules discussed in this article apply to both types."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:81
msgid "Member access"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:83
msgid ""
"The individual components of the vector can be accessed directly by name."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:105
msgid "Adding vectors"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:107
msgid ""
"When adding or subtracting two vectors, the corresponding components are "
"added:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:118
msgid ""
"We can also see this visually by adding the second vector at the end of the "
"first:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:123
msgid "Note that adding ``a + b`` gives the same result as ``b + a``."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:126
msgid "Scalar multiplication"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:128
msgid ""
"Vectors represent both direction and magnitude. A value representing only "
"magnitude is called a **scalar**."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:131
msgid "A vector can be multiplied by a **scalar**:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:146
msgid ""
"Multiplying a vector by a scalar does not change its direction, only its "
"magnitude. This is how you **scale** a vector."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:150
msgid "Practical applications"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:152
msgid "Let's look at two common uses for vector addition and subtraction."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:155
msgid "Movement"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:157
msgid ""
"A vector can represent **any** quantity with a magnitude and direction. "
"Typical examples are: position, velocity, acceleration, and force. In this "
"image, the spaceship at step 1 has a position vector of ``(1,3)`` and a "
"velocity vector of ``(2,1)``. The velocity vector represents how far the "
"ship moves each step. We can find the position for step 2 by adding the "
"velocity to the current position."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:165
msgid ""
"Velocity measures the **change** in position per unit of time. The new "
"position is found by adding velocity to the previous position."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:169
msgid "Pointing toward a target"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:171
msgid ""
"In this scenario, you have a tank that wishes to point its turret at a "
"robot. Subtracting the tank's position from the robot's position gives the "
"vector pointing from the tank to the robot."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:177
msgid "To find a vector pointing from ``A`` to ``B`` use ``B - A``."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:180
msgid "Unit vectors"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:182
msgid ""
"A vector with **magnitude** of ``1`` is called a **unit vector**. They are "
"also sometimes referred to as **direction vectors** or **normals**. Unit "
"vectors are helpful when you need to keep track of a direction."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:187
msgid "Normalization"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:189
msgid ""
"**Normalizing** a vector means reducing its length to ``1`` while preserving "
"its direction. This is done by dividing each of its components by its "
"magnitude. Because this is such a common operation, ``Vector2`` and "
"``Vector3`` provide a method for normalizing:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:204
msgid ""
"Because normalization involves dividing by the vector's length, you cannot "
"normalize a vector of length ``0``. Attempting to do so will result in an "
"error."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:209
msgid "Reflection"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:211
msgid ""
"A common use of unit vectors is to indicate **normals**. Normal vectors are "
"unit vectors aligned perpendicularly to a surface, defining its direction. "
"They are commonly used for lighting, collisions, and other operations "
"involving surfaces."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:216
msgid ""
"For example, imagine we have a moving ball that we want to bounce off a wall "
"or other object:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:221
msgid ""
"The surface normal has a value of ``(0, -1)`` because this is a horizontal "
"surface. When the ball collides, we take its remaining motion (the amount "
"left over when it hits the surface) and reflect it using the normal. In "
"Godot, the :ref:`Vector2 <class_Vector2>` class has a ``bounce()`` method to "
"handle this. Here is a GDScript example of the diagram above using a :ref:"
"`KinematicBody2D <class_KinematicBody2D>`:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:251
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:696
msgid "Dot product"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:253
msgid ""
"The **dot product** is one of the most important concepts in vector math, "
"but is often misunderstood. Dot product is an operation on two vectors that "
"returns a **scalar**. Unlike a vector, which contains both magnitude and "
"direction, a scalar value has only magnitude."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:258
msgid "The formula for dot product takes two common forms:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:260
msgid ""
"A \\cdot B = \\left \\| A \\right \\|\\left \\| B \\right \\|\\cos \\Theta"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:266
msgid "A \\cdot B = A_{x}B_{x} + A_{y}B_{y}"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:270
msgid ""
"However, in most cases it is easiest to use the built-in method. Note that "
"the order of the two vectors does not matter:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:284
msgid ""
"The dot product is most useful when used with unit vectors, making the first "
"formula reduce to just ``cosθ``. This means we can use the dot product to "
"tell us something about the angle between two vectors:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:290
msgid ""
"When using unit vectors, the result will always be between ``-1`` (180°) and "
"``1`` (0°)."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:294
msgid "Facing"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:296
msgid ""
"We can use this fact to detect whether an object is facing toward another "
"object. In the diagram below, the player ``P`` is trying to avoid the "
"zombies ``A`` and ``B``. Assuming a zombie's field of view is **180°**, can "
"they see the player?"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:302
msgid ""
"The green arrows ``fA`` and ``fB`` are **unit vectors** representing the "
"zombies' facing directions and the blue semicircle represents its field of "
"view. For zombie ``A``, we find the direction vector ``AP`` pointing to the "
"player using ``P - A`` and normalize it, however, Godot has a helper method "
"to do this called ``direction_to``. If the angle between this vector and the "
"facing vector is less than 90°, then the zombie can see the player."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:310
msgid "In code it would look like this:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:328
msgid "Cross product"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:330
msgid ""
"Like the dot product, the **cross product** is an operation on two vectors. "
"However, the result of the cross product is a vector with a direction that "
"is perpendicular to both. Its magnitude depends on their relative angle. If "
"two vectors are parallel, the result of their cross product will be a null "
"vector."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:335
msgid ""
"\\left \\|a \\times b  \\right \\| = \\left \\| a \\right \\|\\left \\| b "
"\\right \\|\\ |\\sin(a,b)|"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:341
msgid "The cross product is calculated like this:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:360
msgid "With Godot, you can use the built-in method:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:371
msgid ""
"In the cross product, order matters. ``a.cross(b)`` does not give the same "
"result as ``b.cross(a)``. The resulting vectors point in **opposite** "
"directions."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:376
msgid "Calculating normals"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:378
msgid ""
"One common use of cross products is to find the surface normal of a plane or "
"surface in 3D space. If we have the triangle ``ABC`` we can use vector "
"subtraction to find two edges ``AB`` and ``AC``. Using the cross product, "
"``AB x AC`` produces a vector perpendicular to both: the surface normal."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:383
msgid "Here is a function to calculate a triangle's normal:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:407
msgid "Pointing to a target"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:409
msgid ""
"In the dot product section above, we saw how it could be used to find the "
"angle between two vectors. However, in 3D, this is not enough information. "
"We also need to know what axis to rotate around. We can find that by "
"calculating the cross product of the current facing direction and the target "
"direction. The resulting perpendicular vector is the axis of rotation."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:417
#: ../../docs/tutorials/math/vectors_advanced.rst:589
#, fuzzy
msgid "More information"
msgstr "אנימציות"

#: ../../docs/tutorials/math/vector_math.rst:419
msgid ""
"For more information on using vector math in Godot, see the following "
"articles:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:421
msgid ":ref:`doc_vectors_advanced`"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:422
#: ../../docs/tutorials/math/vectors_advanced.rst:593
msgid ":ref:`doc_matrices_and_transforms`"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:4
msgid "Advanced vector math"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:7
msgid "Planes"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:9
msgid ""
"The dot product has another interesting property with unit vectors. Imagine "
"that perpendicular to that vector (and through the origin) passes a plane. "
"Planes divide the entire space into positive (over the plane) and negative "
"(under the plane), and (contrary to popular belief) you can also use their "
"math in 2D:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:17
msgid ""
"Unit vectors that are perpendicular to a surface (so, they describe the "
"orientation of the surface) are called **unit normal vectors**. Though, "
"usually they are just abbreviated as *normals*. Normals appear in planes, 3D "
"geometry (to determine where each face or vertex is siding), etc. A "
"**normal** *is* a **unit vector**, but it's called *normal* because of its "
"usage. (Just like we call (0,0) the Origin!)."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:24
msgid ""
"It's as simple as it looks. The plane passes by the origin and the surface "
"of it is perpendicular to the unit vector (or *normal*). The side towards "
"the vector points to is the positive half-space, while the other side is the "
"negative half-space. In 3D this is exactly the same, except that the plane "
"is an infinite surface (imagine an infinite, flat sheet of paper that you "
"can orient and is pinned to the origin) instead of a line."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:33
msgid "Distance to plane"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:35
msgid ""
"Now that it's clear what a plane is, let's go back to the dot product. The "
"dot product between a **unit vector** and any **point in space** (yes, this "
"time we do dot product between vector and position), returns the **distance "
"from the point to the plane**:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:49
msgid ""
"But not just the absolute distance, if the point is in the negative half "
"space the distance will be negative, too:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:54
msgid "This allows us to tell which side of the plane a point is."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:57
msgid "Away from the origin"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:59
msgid ""
"I know what you are thinking! So far this is nice, but *real* planes are "
"everywhere in space, not only passing through the origin. You want real "
"*plane* action and you want it *now*."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:63
msgid ""
"Remember that planes not only split space in two, but they also have "
"*polarity*. This means that it is possible to have perfectly overlapping "
"planes, but their negative and positive half-spaces are swapped."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:67
msgid ""
"With this in mind, let's describe a full plane as a **normal** *N* and a "
"**distance from the origin** scalar *D*. Thus, our plane is represented by N "
"and D. For example:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:73
msgid ""
"For 3D math, Godot provides a :ref:`Plane <class_Plane>` built-in type that "
"handles this."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:76
msgid ""
"Basically, N and D can represent any plane in space, be it for 2D or 3D "
"(depending on the amount of dimensions of N) and the math is the same for "
"both. It's the same as before, but D is the distance from the origin to the "
"plane, travelling in N direction. As an example, imagine you want to reach a "
"point in the plane, you will just do:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:91
msgid ""
"This will stretch (resize) the normal vector and make it touch the plane. "
"This math might seem confusing, but it's actually much simpler than it "
"seems. If we want to tell, again, the distance from the point to the plane, "
"we do the same but adjusting for distance:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:105
msgid "The same thing, using a built-in function:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:116
msgid "This will, again, return either a positive or negative distance."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:118
msgid ""
"Flipping the polarity of the plane can be done by negating both N and D. "
"This will result in a plane in the same position, but with inverted negative "
"and positive half spaces:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:133
msgid ""
"Of course, Godot also implements this operator in :ref:`Plane "
"<class_Plane>`, so doing:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:145
msgid "Will work as expected."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:147
msgid ""
"So, remember, a plane is just that and its main practical use is calculating "
"the distance to it. So, why is it useful to calculate the distance from a "
"point to a plane? It's extremely useful! Let's see some simple examples.."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:153
msgid "Constructing a plane in 2D"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:155
msgid ""
"Planes clearly don't come out of nowhere, so they must be built. "
"Constructing them in 2D is easy, this can be done from either a normal (unit "
"vector) and a point, or from two points in space."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:159
msgid ""
"In the case of a normal and a point, most of the work is done, as the normal "
"is already computed, so just calculate D from the dot product of the normal "
"and the point."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:174
msgid ""
"For two points in space, there are actually two planes that pass through "
"them, sharing the same space but with normal pointing to the opposite "
"directions. To compute the normal from the two points, the direction vector "
"must be obtained first, and then it needs to be rotated 90° degrees to "
"either side:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:199
msgid ""
"The rest is the same as the previous example, either point_a or point_b will "
"work since they are in the same plane:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:217
msgid ""
"Doing the same in 3D is a little more complex and will be explained further "
"down."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:221
msgid "Some examples of planes"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:223
msgid ""
"Here is a simple example of what planes are useful for. Imagine you have a "
"`convex <https://www.mathsisfun.com/definitions/convex.html>`__ polygon. For "
"example, a rectangle, a trapezoid, a triangle, or just any polygon where no "
"faces bend inwards."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:228
msgid ""
"For every segment of the polygon, we compute the plane that passes by that "
"segment. Once we have the list of planes, we can do neat things, for example "
"checking if a point is inside the polygon."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:232
msgid ""
"We go through all planes, if we can find a plane where the distance to the "
"point is positive, then the point is outside the polygon. If we can't, then "
"the point is inside."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:238
#: ../../docs/tutorials/math/vectors_advanced.rst:277
msgid "Code should be something like this:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:263
msgid ""
"Pretty cool, huh? But this gets much better! With a little more effort, "
"similar logic will let us know when two convex polygons are overlapping too. "
"This is called the Separating Axis Theorem (or SAT) and most physics engines "
"use this to detect collision."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:268
msgid ""
"With a point, just checking if a plane returns a positive distance is enough "
"to tell if the point is outside. With another polygon, we must find a plane "
"where *all* *the* *other* *polygon* *points* return a positive distance to "
"it. This check is performed with the planes of A against the points of B, "
"and then with the planes of B against the points of A:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:368
msgid ""
"As you can see, planes are quite useful, and this is the tip of the iceberg. "
"You might be wondering what happens with non convex polygons. This is "
"usually just handled by splitting the concave polygon into smaller convex "
"polygons, or using a technique such as BSP (which is not used much nowadays)."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:375
msgid "Collision detection in 3D"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:377
msgid ""
"This is another bonus bit, a reward for being patient and keeping up with "
"this long tutorial. Here is another piece of wisdom. This might not be "
"something with a direct use case (Godot already does collision detection "
"pretty well) but it's used by almost all physics engines and collision "
"detection libraries :)"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:383
msgid ""
"Remember that converting a convex shape in 2D to an array of 2D planes was "
"useful for collision detection? You could detect if a point was inside any "
"convex shape, or if two 2D convex shapes were overlapping."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:387
msgid ""
"Well, this works in 3D too, if two 3D polyhedral shapes are colliding, you "
"won't be able to find a separating plane. If a separating plane is found, "
"then the shapes are definitely not colliding."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:391
msgid ""
"To refresh a bit a separating plane means that all vertices of polygon A are "
"in one side of the plane, and all vertices of polygon B are in the other "
"side. This plane is always one of the face-planes of either polygon A or "
"polygon B."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:396
msgid ""
"In 3D though, there is a problem to this approach, because it is possible "
"that, in some cases a separating plane can't be found. This is an example of "
"such situation:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:402
msgid ""
"To avoid it, some extra planes need to be tested as separators, these planes "
"are the cross product between the edges of polygon A and the edges of "
"polygon B"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:408
msgid "So the final algorithm is something like:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:591
msgid ""
"For more information on using vector math in Godot, see the following "
"article:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:595
msgid ""
"If you would like additional explanation, you should check out 3Blue1Brown's "
"excellent video series \"Essence of Linear Algebra\": https://www.youtube."
"com/watch?v=fNk_zzaMoSs&list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:4
msgid "Matrices and transforms"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:9
msgid ""
"Before reading this tutorial, we recommend that you thoroughly read and "
"understand the :ref:`doc_vector_math` tutorial, as this tutorial requires a "
"knowledge of vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:13
msgid ""
"This tutorial is about *transformations* and how we represent them in Godot "
"using matrices. It is not a full in-depth guide to matrices. Transformations "
"are most of the time applied as translation, rotation, and scale, so we will "
"focus on how to represent those with matrices."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:18
msgid ""
"Most of this guide focuses on 2D, using :ref:`class_Transform2D` and :ref:"
"`class_Vector2`, but the way things work in 3D is very similar."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:21
msgid ""
"As mentioned in the previous tutorial, it is important to remember that in "
"Godot, the Y axis points *down* in 2D. This is the opposite of how most "
"schools teach linear algebra, with the Y axis pointing up."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:26
msgid ""
"The convention is that the X axis is red, the Y axis is green, and the Z "
"axis is blue. This tutorial is color-coded to match these conventions, but "
"we will also represent the origin vector with a blue color."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:32
msgid "Matrix components and the Identity matrix"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:34
msgid ""
"The identity matrix represents a transform with no translation, no rotation, "
"and no scale. Let's start by looking at the identity matrix and how its "
"components relate to how it visually appears."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:40
msgid ""
"Matrices have rows and columns, and a transformation matrix has specific "
"conventions on what each does."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:43
msgid ""
"In the image above, we can see that the red X vector is represented by the "
"first column of the matrix, and the green Y vector is likewise represented "
"by the second column. A change to the columns will change these vectors. We "
"will see how they can be manipulated in the next few examples."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:49
msgid ""
"You should not worry about manipulating rows directly, as we usually work "
"with columns. However, you can think of the rows of the matrix as showing "
"which vectors contribute to moving in a given direction."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:53
msgid ""
"When we refer to a value such as `t.x.y`, that's the Y component of the X "
"column vector. In other words, the bottom-left of the matrix. Similarly, `t."
"x.x` is top-left, `t.y.x` is top-right, and `t.y.y` is bottom-right, where "
"`t` is the Transform2D."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:59
msgid "Scaling the transformation matrix"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:61
msgid ""
"Applying a scale is one of the easiest operations to understand. Let's start "
"by placing the Godot logo underneath our vectors so that we can visually see "
"the effects on an object:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:67
msgid ""
"Now, to scale the matrix, all we need to do is multiply each component by "
"the scale we want. Let's scale it up by 2. 1 times 2 becomes 2, and 0 times "
"2 becomes 0, so we end up with this:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:73
msgid "To do this in code, we can simply multiply each of the vectors:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:92
msgid ""
"If we wanted to return it to its original scale, we can multiply each "
"component by 0.5. That's pretty much all there is to scaling a "
"transformation matrix."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:96
msgid ""
"To calculate the object's scale from an existing transformation matrix, you "
"can use `length()` on each of the column vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:99
msgid ""
"In actual projects, you can use the `scaled()` method to perform scaling."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:103
#, fuzzy
msgid "Rotating the transformation matrix"
msgstr "אנימציות"

#: ../../docs/tutorials/math/matrices_and_transforms.rst:105
msgid ""
"We'll start the same way as earlier, with the Godot logo underneath the "
"identity matrix:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:110
msgid ""
"As an example, let's say we want to rotate our Godot logo clockwise by 90 "
"degrees. Right now the X axis points right and the Y axis points down. If we "
"rotate these in our head, we would logically see that the new X axis should "
"point down and the new Y axis should point left."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:116
msgid ""
"You can imagine that you grab both the Godot logo and its vectors, and then "
"spin it around the center. Wherever you finish spinning, the orientation of "
"the vectors determines what the matrix is."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:120
msgid ""
"We need to represent \"down\" and \"left\" in normal coordinates, so means "
"we'll set X to (0, 1) and Y to (-1, 0). These are also the values of "
"`Vector2.DOWN` and `Vector2.LEFT`. When we do this, we get the desired "
"result of rotating the object:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:127
msgid ""
"If you have trouble understanding the above, try this exercise: Cut a square "
"of paper, draw X and Y vectors on top of it, place it on graph paper, then "
"rotate it and note the endpoints."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:131
msgid ""
"To perform rotation in code, we need to be able to calculate the values "
"programmatically. This image shows the formulas needed to calculate the "
"transformation matrix from a rotation angle. Don't worry if this part seems "
"complicated, I promise it's the hardest thing you need to know."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:139
msgid ""
"Godot represents all rotations with radians, not degrees. A full turn is "
"`TAU` or `PI*2` radians, and a quarter turn of 90 degrees is `TAU/4` or "
"`PI/2` radians. Working with `TAU` usually results in more readable code."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:144
msgid ""
"Fun fact: In addition to Y being *down* in Godot, rotation is represented "
"clockwise. This means that all the math and trig functions behave the same "
"as a Y-is-up CCW system, since these differences \"cancel out\". You can "
"think of rotations in both systems being \"from X to Y\"."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:150
msgid ""
"In order to perform a rotation of 0.5 radians (about 28.65 degrees), we "
"simply plug in a value of 0.5 to the formula above and evaluate to find what "
"the actual values should be:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:156
msgid "Here's how that would be done in code (place the script on a Node2D):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:178
msgid ""
"To calculate the object's rotation from an existing transformation matrix, "
"you can use `atan2(t.x.y, t.x.x)`, where t is the Transform2D."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:181
msgid ""
"In actual projects, you can use the `rotated()` method to perform rotations."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:185
msgid "Basis of the transformation matrix"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:187
msgid ""
"So far we have only been working with the `x` and `y`, vectors, which are in "
"charge of representing rotation, scale, and/or shearing (advanced, covered "
"at the end). The X and Y vectors are together called the *basis* of the "
"transformation matrix. The terms \"basis\" and \"basis vectors\" are "
"important to know."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:193
msgid ""
"You might have noticed that :ref:`class_Transform2D` actually has three :ref:"
"`class_Vector2` values: `x`, `y`, and `origin`. The `origin` value is not "
"part of the basis, but it is part of the transform, and we need it to "
"represent position. From now on we'll keep track of the origin vector in all "
"examples. You can think of origin as another column, but it's often better "
"to think of it as completely separate."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:201
msgid ""
"Note that in 3D, Godot has a separate :ref:`class_Basis` structure for "
"holding the three :ref:`class_Vector3` values of the basis, since the code "
"can get complex and it makes sense to separate it from :ref:"
"`class_Transform` (which is composed of one :ref:`class_Basis` and one "
"extra :ref:`class_Vector3` for the origin)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:208
msgid "Translating the transformation matrix"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:210
msgid ""
"Changing the `origin` vector is called a *translating* the transformation "
"matrix. Translating is basically a technical term for \"moving\" the object, "
"but it explicitly does not involve any rotation."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:214
msgid ""
"Let's work through an example to help understand this. We will start with "
"the identity transform like last time, except we will keep track of the "
"origin vector this time."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:220
msgid ""
"If we want the object to move to a position of (1, 2), we simply need to set "
"its `origin` vector to (1, 2):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:225
msgid ""
"There is also a `translated()` method, which performs a different operation "
"to adding or changing `origin` directly. The `translated()` method will "
"translate the object *relative to its own rotation*. For example, an object "
"rotated 90 degrees clockwise will move to the right when `translated()` with "
"`Vector2.UP`."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:231
msgid ""
"Godot's 2D uses coordinates based on pixels, so in actual projects you will "
"want to translate by hundreds of units."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:235
msgid "Putting it all together"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:237
msgid ""
"We're going to apply everything we mentioned so far onto one transform. To "
"follow along, create a simple project with a Sprite node and use the Godot "
"logo for the texture resource."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:241
msgid ""
"Let's set the translation to (350, 150), rotate by -0.5 rad, and scale by 3. "
"I've posted a screenshot, and the code to reproduce it, but I encourage you "
"to try and reproduce the screenshot without looking at the code!"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:280
msgid "Shearing the transformation matrix (advanced)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:282
msgid ""
"If you are only looking for how to *use* transformation matrices, feel free "
"to skip this section of the tutorial. This section explores an uncommonly "
"used aspect of transformation matrices for the purpose of building an "
"understanding of them."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:287
msgid ""
"You may have noticed that a transform has more degrees of freedom than the "
"combination of the above actions. The basis of a 2D transformation matrix "
"has four total numbers in two :ref:`class_Vector2` values, while a rotation "
"value and a Vector2 for scale only has 3 numbers. The high-level concept for "
"the missing degree of freedom is called *shearing*."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:293
msgid ""
"Normally you will always have the basis vectors perpendicular to each other. "
"However, shearing can be useful in some situations, and understanding "
"shearing helps you understand how transforms work."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:297
msgid ""
"To show you visually how it will look, let's overlay a grid onto the Godot "
"logo:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:302
msgid ""
"Each point on this grid is obtained by adding the basis vectors together. "
"The bottom-right corner is X + Y, while the top-right corner is X - Y. If we "
"change the basis vectors, the entire grid moves with it, as the grid is "
"composed of the basis vectors. All lines on the grid that are currently "
"parallel will remain parallel no matter what changes we make to the basis "
"vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:309
msgid "As an example, let's set Y to (1, 1):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:328
msgid ""
"You can't set the raw values of a Transform2D in the editor, so you *must* "
"use code if you want to shear the object."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:331
msgid ""
"Due to the vectors no longer being perpendicular, the object has been "
"sheared. The bottom-center of the grid, which is (0, 1) relative to itself, "
"is now located at a world position of (1, 1)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:335
msgid ""
"The intra-object coordinates are called UV coordinates in textures, so let's "
"borrow that terminology for here. To find the world position from a relative "
"position, the formula is U * X + V * Y, where U and V are numbers and X and "
"Y are the basis vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:340
msgid ""
"The bottom-right corner of the grid, which is always at the UV position of "
"(1, 1), is at the world position of (2, 1), which is calculated from X*1 + "
"Y*1, which is (1, 0) + (1, 1), or (1 + 1, 0 + 1), or (2, 1). This matches up "
"with our observation of where the bottom-right corner of the image is."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:346
msgid ""
"Similarly, the top-right corner of the grid, which is always at the UV "
"position of (1, -1), is at the world position of (0, -1), which is "
"calculated from X*1 + Y*-1, which is (1, 0) - (1, 1), or (1 - 1, 0 - 1), or "
"(0, -1). This matches up with our observation of where the top-right corner "
"of the image is."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:352
msgid ""
"Hopefully you now fully understand the how a transformation matrix affects "
"the object, and the relationship between the basis vectors and how the "
"object's \"UV\" or \"intra-coordinates\" have their world position changed."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:356
msgid ""
"In Godot, all transform math is done relative to the parent node. When we "
"refer to \"world position\", that would be relative to the node's parent "
"instead, if the node had a parent."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:360
msgid ""
"If you would like additional explanation, you should check out 3Blue1Brown's "
"excellent video about linear transformations: https://www.youtube.com/watch?"
"v=kYB8IZa5AuE"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:365
msgid "Practical applications of transforms"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:367
msgid ""
"In actual projects, you will usually be working with transforms inside "
"transforms by having multiple :ref:`class_Node2D` or :ref:`class_Spatial` "
"nodes parented to each other."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:371
msgid ""
"However, sometimes it's very useful to manually calculate the values we "
"need. We will go over how you could use :ref:`class_Transform2D` or :ref:"
"`class_Transform` to manually calculate transforms of nodes."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:376
msgid "Converting positions between transforms"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:378
msgid ""
"There are many cases where you'd want to convert a position in and out of a "
"transform. For example, if you have a position relative to the player and "
"would like to find the world (parent-relative) position, or if you have a "
"world position and want to know where it is relative to the player."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:383
msgid ""
"We can find what a vector relative to the player would be defined in world "
"space as using the \"xform\" method:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:397
msgid ""
"And we can use the \"xform_inv\" method to find a what world space position "
"would be if it was instead defined relative to the player:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:411
msgid ""
"If you know in advance that the transform is positioned at (0, 0), you can "
"use the \"basis_xform\" or \"basis_xform_inv\" methods instead, which skip "
"dealing with translation."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:416
msgid "Moving an object relative to itself"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:418
msgid ""
"A common operation, especially in 3D games, is to move an object relative to "
"itself. For example, in first-person shooter games, you would want the "
"character to move forward (-Z axis) when you press :kbd:`W`."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:422
msgid ""
"Since the basis vectors are the orientation relative to the parent, and the "
"origin vector is the position relative to the parent, we can simply add "
"multiples of the basis vectors to move an object relative to itself."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:426
msgid "This code moves an object 100 units to its own right:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:439
msgid "For moving in 3D, you would need to replace \"x\" with \"basis.x\"."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:441
msgid ""
"In actual projects, you can use `translate_object_local` in 3D or "
"`move_local_x` and `move_local_y` in 2D to do this."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:445
msgid "Applying transforms onto transforms"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:447
msgid ""
"One of the most important things to know about transforms is how you can use "
"several of them together. A parent node's transform affects all of its "
"children. Let's dissect an example."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:451
msgid ""
"In this image, the child node has a \"2\" after the component names to "
"distinguish them from the parent node. It might look a bit overwhelming with "
"so many numbers, but remember that each number is displayed twice (next to "
"the arrows and also in the matrices), and that almost half of the numbers "
"are zero."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:459
msgid ""
"The only transformations going on here are that the parent node has been "
"given a scale of (2, 1), the child has been given a scale of (0.5, 0.5), and "
"both nodes have been given positions."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:463
msgid ""
"All child transformations are affected by the parent transformations. The "
"child has a scale of (0.5, 0.5), so you would expect it to be a 1:1 ratio "
"square, and it is, but only relative to the parent. The child's X vector "
"ends up being (1, 0) in world space, because it is scaled by the parent's "
"basis vectors. Similarly, the child node's `origin` vector is set to (1, 1), "
"but this actually moves it (2, 1) in world space, due to the parent node's "
"basis vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:472
msgid ""
"To calculate a child transform's world space transform manually, this is the "
"code we would use:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:510
msgid ""
"In actual projects, we can find the world transform of the child by applying "
"one transform onto another using the `*` operator:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:532
msgid "When multiplying matrices, order matters! Don't mix them up."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:534
msgid "Lastly, applying the identity transform will always do nothing."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:536
msgid ""
"If you would like additional explanation, you should check out 3Blue1Brown's "
"excellent video about matrix composition: https://www.youtube.com/watch?"
"v=XkY2DOUCWMU"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:541
msgid "Inverting a transformation matrix"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:543
msgid ""
"The \"affine_inverse\" function returns a transform that \"undoes\" the "
"previous transform. This can be useful in some situations, but it's easier "
"to just provide a few examples."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:547
msgid ""
"Multiplying an inverse transform by the normal transform undoes all "
"transformations:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:563
msgid ""
"Transforming a position by a transform and its inverse results in the same "
"position (same for \"xform_inv\"):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:582
msgid "How does it all work in 3D?"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:584
msgid ""
"One of the great things about transformation matrices is that they work very "
"similarly between 2D and 3D transformations. All the code and formulas used "
"above for 2D work the same in 3D, with 3 exceptions: the addition of a third "
"axis, that each axis is of type :ref:`class_Vector3`, and also that Godot "
"stores the :ref:`class_Basis` separately from the :ref:`class_Transform`, "
"since the math can get complex and it makes sense to separate it."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:592
msgid ""
"All of the concepts for how translation, rotation, scale, and shearing work "
"in 3D are all the same compared to 2D. To scale, we take each component and "
"multiply it; to rotate, we change where each basis vector is pointing; to "
"translate, we manipulate the origin; and to shear, we change the basis "
"vectors to be non-perpendicular."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:600
msgid ""
"If you would like, it's a good idea to play around with transforms to get an "
"understanding of how they work. Godot allows you to edit 3D transform "
"matrices directly from the inspector. You can download this project which "
"has colored lines and cubes to help visualize the :ref:`class_Basis` vectors "
"and the origin in both 2D and 3D: https://github.com/godotengine/godot-demo-"
"projects/tree/master/misc/matrix_transform"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:607
msgid ""
"Spatial's \"Matrix\" section in Godot 3.2's inspector displays the matrix as "
"transposed, with the columns horizontal and the rows vertical. This may be "
"changed to be less confusing in a future release of Godot."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:612
msgid ""
"You cannot edit Node2D's transform matrix directly in Godot 3.2's inspector. "
"This may be changed in a future release of Godot."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:615
msgid ""
"If you would like additional explanation, you should check out 3Blue1Brown's "
"excellent video about 3D linear transformations: https://www.youtube.com/"
"watch?v=rHLEWRxRGiM"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:620
msgid "Representing rotation in 3D (advanced)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:622
msgid ""
"The biggest difference between 2D and 3D transformation matrices is how you "
"represent rotation by itself without the basis vectors."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:625
msgid ""
"With 2D, we have an easy way (atan2) to switch between a transformation "
"matrix and an angle. In 3D, we can't simply represent rotation as one "
"number. There is something called Euler angles, which can represent "
"rotations as a set of 3 numbers, however, they are limited and not very "
"useful, except for trivial cases."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:631
msgid ""
"In 3D we do not typically use angles, we either use a transformation basis "
"(used pretty much everywhere in Godot), or we use quaternions. Godot can "
"represent quaternions using the :ref:`class_Quat` struct. My suggestion to "
"you is to completely ignore how they work under-the-hood, because they are "
"very complicated and unintuitive."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:637
msgid ""
"However, if you really must know how it works, here are some great "
"resources, which you can follow in order:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:640
msgid "https://www.youtube.com/watch?v=mvmuCPvRoWQ"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:642
msgid "https://www.youtube.com/watch?v=d4EgbgTm0Bg"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:644
msgid "https://eater.net/quaternions"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:6
msgid ""
"Interpolation is a very basic operation in graphics programming. It's good "
"to become familiar with it in order to expand your horizons as a graphics "
"developer."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:8
msgid ""
"The basic idea is that you want to transition from A to B. A value ``t``, "
"represents the states in-between."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:10
msgid ""
"As an example if ``t`` is 0, then the state is A. If ``t`` is 1, then the "
"state is B. Anything in-between is an *interpolation*."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:12
msgid ""
"Between two real (floating-point) numbers, a simple interpolation is usually "
"described as:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:19
msgid "And often simplified to:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:26
msgid ""
"The name of this type of interpolation, which transforms a value into "
"another at *constant speed* is *\"linear\"*. So, when you hear about *Linear "
"Interpolation*, you know they are referring to this simple formula."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:28
msgid ""
"There are other types of interpolations, which will not be covered here. A "
"recommended read afterwards is the :ref:`Bezier <doc_beziers_and_curves>` "
"page."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:31
#, fuzzy
msgid "Vector interpolation"
msgstr "אנימציות"

#: ../../docs/tutorials/math/interpolation.rst:33
msgid ""
"Vector types (:ref:`Vector2 <class_Vector2>` and :ref:`Vector3 "
"<class_Vector3>`) can also be interpolated, they come with handy functions "
"to do it :ref:`Vector2.linear_interpolate() "
"<class_Vector2_method_linear_interpolate>` and :ref:`Vector3."
"linear_interpolate() <class_Vector3_method_linear_interpolate>`."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:36
msgid ""
"For cubic interpolation, there are also :ref:`Vector2.cubic_interpolate() "
"<class_Vector2_method_linear_interpolate>` and :ref:`Vector3."
"cubic_interpolate() <class_Vector3_method_linear_interpolate>`, which do a :"
"ref:`Bezier <doc_beziers_and_curves>` style interpolation."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:38
msgid ""
"Here is simple pseudo-code for going from point A to B using interpolation:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:48
msgid "It will produce the following motion:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:53
#, fuzzy
msgid "Transform interpolation"
msgstr "התמרה"

#: ../../docs/tutorials/math/interpolation.rst:55
msgid ""
"It is also possible to interpolate whole transforms (make sure they have "
"either uniform scale or, at least, the same non-uniform scale). For this, "
"the function :ref:`Transform.interpolate_with() "
"<class_Transform_method_interpolate_with>` can be used."
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:58
msgid ""
"Here is an example of transforming a monkey from Position1 to Position2:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:62
msgid "Using the following pseudocode:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:74
msgid "And again, it will produce the following motion:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:80
#, fuzzy
msgid "Smoothing motion"
msgstr "אנימציות"

#: ../../docs/tutorials/math/interpolation.rst:82
msgid ""
"Interpolation can be used to smooth movement, rotation, etc. Here is an "
"example of a circle following the mouse using smoothed motion:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:94
msgid "Here is how it looks:"
msgstr ""

#: ../../docs/tutorials/math/interpolation.rst:98
msgid ""
"This useful for smoothing camera movement, allies following you (ensuring "
"they stay within a certain range), and many other common game patterns."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:4
msgid "Beziers, curves and paths"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:6
msgid ""
"Bezier curves are a mathematical approximation of natural geometric shapes. "
"We use them to represent a curve with as little information as possible and "
"with a high level of flexibility."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:10
msgid ""
"Unlike more abstract mathematical concepts, Bezier curves were created for "
"industrial design. They are a popular tool in the graphics software industry."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:13
msgid ""
"They rely on :ref:`interpolation<doc_interpolation>`, which we saw in the "
"previous article, combining multiple steps to create smooth curves. To "
"better understand how Bezier curves work, let's start from its simplest "
"form: Quadratic Bezier."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:19
msgid "Quadratic Bezier"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:21
msgid "Take three points, the minimum required for Quadratic Bezier to work:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:25
msgid ""
"To draw a curve between them, we first interpolate gradually over the two "
"vertices of each of the two segments formed by the three points, using "
"values ranging from 0 to 1. This gives us two points that move along the "
"segments as we change the value of ``t`` from 0 to 1."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:37
msgid ""
"We then interpolate ``q0`` and ``q1`` to obtain a single point ``r`` that "
"moves along a curve."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:46
msgid "This type of is called a *Quadratic Bezier* curve."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:50
#: ../../docs/tutorials/math/beziers_and_curves.rst:114
msgid "*(Image credit: Wikipedia)*"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:53
msgid "Cubic Bezier"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:55
msgid ""
"Building upon the previous example, we can get more control by interpolating "
"between four points."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:60
msgid ""
"We first use a function with four parameters to take four points as an "
"input, ``p0``, ``p1``, ``p2`` and ``p3``:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:68
msgid ""
"We apply a linear interpolation to each couple of points to reduce them to "
"three:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:78
msgid "We then take our three points and reduce them to two:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:86
msgid "And to one:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:94
msgid "Here is the full function:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:110
msgid ""
"The result will be a smooth curve interpolating between all four points:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:116
msgid ""
"Cubic Bezier interpolation works the same in 3D, just use ``Vector3`` "
"instead of ``Vector2``."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:120
msgid "Adding control points"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:122
msgid ""
"Building upon Cubic Bezier, we can change the way two of the points work to "
"control the shape of our curve freely. Instead of having ``p0``, ``p1``, "
"``p2`` and ``p3``, we will store them as:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:126
msgid "``point0 = p0``: Is the first point, the source"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:127
msgid "``control0 = p1 - p0``: Is a vector relative to the first control point"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:128
msgid ""
"``control1 = p3 - p2``: Is a vector relative to the second control point"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:129
msgid "``point1 = p3``: Is the second point, the destination"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:131
msgid ""
"This way, we have two points and two control points which are relative "
"vectors to the respective points. If you've used graphics or animation "
"software before, this might look familiar:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:137
msgid ""
"This is how graphics software presents Bezier curves to the users, and how "
"they work and look in Godot."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:141
msgid "Curve2D, Curve3D, Path and Path2D"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:143
msgid ""
"There are two objects that contain curves: :ref:`Curve3D <class_Curve3D>` "
"and :ref:`Curve2D <class_Curve2D>` (for 3D and 2D respectively)."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:145
msgid ""
"They can contain several points, allowing for longer paths. It is also "
"possible to set them to nodes: :ref:`Path <class_Path>` and :ref:`Path2D "
"<class_Path2D>` (also for 3D and 2D respectively):"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:149
msgid ""
"Using them, however, may not be completely obvious, so following is a "
"description of the most common use cases for Bezier curves."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:152
msgid "Evaluating"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:154
msgid ""
"Just evaluating them may be an option, but in most cases it's not very "
"useful. The big drawback with Bezier curves is that if you traverse them at "
"constant speed, from ``t = 0`` to ``t = 1``, the actual interpolation will "
"*not* move at constant speed. The speed is also an interpolation between the "
"distances between points ``p0``, ``p1``, ``p2`` and ``p3`` and there is not "
"a mathematically simple way to traverse the curve at constant speed."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:156
msgid "Let's do a simple example with the following pseudocode:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:170
msgid ""
"As you can see, the speed (in pixels per second) of the circle varies, even "
"though ``t`` is increased at constant speed. This makes beziers difficult to "
"use for anything practical out of the box."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:173
#: ../../docs/tutorials/gui/custom_gui_controls.rst:17
msgid "Drawing"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:175
msgid ""
"Drawing beziers (or objects based on the curve) is a very common use case, "
"but it's also not easy. For pretty much any case, Bezier curves need to be "
"converted to some sort of segments. This is normally difficult, however, "
"without creating a very high amount of them."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:177
msgid ""
"The reason is that some sections of a curve (specifically, corners) may "
"require considerable amounts of points, while other sections may not:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:181
msgid ""
"Additionally, if both control points were ``0, 0`` (remember they are "
"relative vectors), the Bezier curve would just be a straight line (so "
"drawing a high amount of points would be wasteful)."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:183
msgid ""
"Before drawing Bezier curves, *tessellation* is required. This is often done "
"with a recursive or divide and conquer function that splits the curve until "
"the curvature amount becomes less than a certain threshold."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:185
msgid ""
"The *Curve* classes provide this via the :ref:`Curve2D.tessellate() "
"<class_Curve2D_method_tessellate>` function (which receives optional "
"``stages`` of recursion and angle ``tolerance`` arguments). This way, "
"drawing something based on a curve is easier."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:189
msgid "Traversal"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:191
msgid ""
"The last common use case for the curves is to traverse them. Because of what "
"was mentioned before regarding constant speed, this is also difficult."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:193
msgid ""
"To make this easier, the curves need to be *baked* into equidistant points. "
"This way, they can be approximated with regular  interpolation (which can be "
"improved further with a cubic option). To do this, just use the :ref:`Curve."
"interpolate_baked()<class_Curve_method_interpolate_baked>` method together "
"with :ref:`Curve2D."
"get_baked_length()<class_Curve2D_method_get_baked_length>`. The first call "
"to either of them will bake the curve internally."
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:196
msgid ""
"Traversal at constant speed, then, can be done with the following pseudo-"
"code:"
msgstr ""

#: ../../docs/tutorials/math/beziers_and_curves.rst:207
msgid "And the output will, then, move at constant speed:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:4
msgid "Introduction to the 2D animation features"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:9
msgid ""
"The :ref:`class_AnimationPlayer` node allows you to create anything from "
"simple to complex animations."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:12
msgid "In this guide you learn to:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:14
msgid "Work with the Animation Panel"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:15
msgid "Animate any property of any node"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:16
msgid "Create a simple animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:17
msgid "Call functions with the powerful Call Function Tracks"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:19
msgid ""
"In Godot, you can animate anything available in the Inspector, such as Node "
"transforms, sprites, UI elements, particles, visibility and color of "
"materials, and so on. You can also modify values of script variables and "
"call any function."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:25
msgid "Create an AnimationPlayer node"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:27
msgid ""
"To use the animation tools we first have to create an :ref:"
"`class_AnimationPlayer` node."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:30
msgid ""
"The AnimationPlayer node type is the data container for your animations. One "
"AnimationPlayer node can hold multiple animations, that can automatically "
"transition to one another."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:37
msgid "The AnimationPlayer node"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:39
msgid ""
"After creating one click on the AnimationPlayer node in the Node tab to open "
"the Animation Panel at the bottom of the viewport."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:45
msgid "The animation panel position"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:47
msgid "It consists of four parts:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:52
msgid "The animation panel"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:54
msgid "Animation controls (i.e. add, load, save, and delete animations)"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:55
msgid "The tracks listing"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:56
msgid "The timeline with keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:57
msgid ""
"The timeline and track controls, where you can zoom the timeline and edit "
"tracks for example."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:61
msgid "Computer animation relies on keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:63
msgid "A keyframe defines the value of a property at a certain point in time."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:65
msgid ""
"Diamond shapes represent keyframes in the timeline. A line between two "
"keyframes indicates that the value hasn't changed."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:71
msgid "Keyframes in Godot"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:73
msgid ""
"The engine interpolates values between keyframes, resulting in a gradual "
"change in values over time."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:79
msgid "Two keyframes are all it takes to obtain a smooth motion"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:81
msgid ""
"The timeline lets you insert keyframes and change their timing. It also "
"defines how long the animation is."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:87
msgid "The timeline in the animation panel"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:89
msgid ""
"Each line of the Animation Panel is an animation track. Normal and Transform "
"tracks reference node properties. Their name or id is a path to the node and "
"the affected property."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:96
msgid "Example of Normal animation tracks"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:100
msgid ""
"If you animate the wrong property, you can edit a track's path anytime. "
"Double click on it and type the new path. Play the animation using the "
"\"Play from beginning\" button |Play from beginning| (or pressing :kbd:"
"`Shift + D` on keyboard) to see the changes instantly."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:106
msgid "Tutorial: Creating a simple animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:111
msgid ""
"For this tutorial, we'll create an AnimationPlayer node and a sprite node as "
"its child."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:117
msgid "Our scene setup"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:119
msgid ""
"The sprite holds an image texture. We animate that sprite to move between "
"two points on the screen. For this tutorial, use the default Godot icon as "
"the sprite's texture. As a starting point, move the sprite to a left "
"position on the screen."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:126
msgid ""
"Adding animated nodes as children to the AnimationPlayer node is not "
"required, but it is a nice way of distinguishing animated nodes from non-"
"animated nodes in the Scene Tree."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:130
msgid ""
"Select the AnimationPlayer node, then click the \"Animation\" button in the "
"animation editor. From the list select \"New\" (|Add Animation|) to add a "
"new animation. And Enter a name for the animation in the dialog box."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:138
msgid "Add a new animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:141
msgid "Adding a track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:143
msgid ""
"To add a new track for our sprite, select it and take a look in the toolbar:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:149
msgid "Convenience buttons"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:151
msgid ""
"These switches and buttons allow you to add keyframes for the selected "
"node's location, rotation, and scale respectively."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:154
msgid ""
"Deselect rotation, because we are only interested in the location of our "
"sprite for this tutorial and click on the key button."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:157
msgid ""
"As we don't have a track already set up for the transform/location property, "
"Godot asks whether it should set it up for us. Click **Create**."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:160
msgid ""
"This creates a new track and our first keyframe at the beginning of the "
"timeline:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:166
msgid "The sprite track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:169
msgid "The second keyframe"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:171
msgid ""
"Now we need to set the destination where our sprite should be headed and how "
"much time it takes to get there."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:174
msgid ""
"Let's say, we want it to take 2 seconds to go to the other point. By default "
"the animation is set to last only 1 second, so change this in the timeline "
"controls in animation panel's lower panel to 2."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:181
msgid "Animation length"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:183
msgid ""
"Click on the timeline header near the 2-second mark and move the sprite to "
"the target destination on the right side."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:186
msgid ""
"Again, click the key button in the toolbar. This creates our second keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:190
msgid "Run the animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:192
msgid "Click on the \"Play from beginning\" (|Play from beginning|) button."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:194
msgid "Yay! Our animation runs:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:199
msgid "The animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:202
msgid "Back and forth"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:204
msgid ""
"Godot has an additional feature here. Like said before, Godot always "
"calculates the frames between two keyframes. In a loop, the first keyframe "
"is also the last keyframe, if no keyframe is specified at the end."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:212
msgid "Animation loop"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:214
msgid ""
"If you set the animation length to 4 seconds now, the animation moves back "
"and forth. You can change this behavior if you change the track's loop mode. "
"This is covered in the next chapter."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:219
#: ../../docs/tutorials/animation/introduction_2d.rst:227
msgid "Track settings"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:221
msgid ""
"Each track has a settings panel at the end, where you can set the update "
"mode, the track interpolation, and the loop mode."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:229
msgid ""
"The update mode of a track tells Godot when to update the property values. "
"This can be:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:232
msgid "Continuous: Update the property on each frame"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:233
msgid "Discrete: Only update the property on keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:234
msgid "Trigger: Only update the property on keyframes or triggers"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:235
msgid ""
"Capture: The current value of a property is remembered, and it will blend "
"with the first animation key found"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:240
msgid "Track mode"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:242
msgid ""
"In normal animations, you usually use \"Continuous\". The other types are "
"used to script complex animations."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:245
msgid ""
"The interpolation tells Godot how to calculate the frame values between the "
"keyframes. These interpolation modes are supported:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:248
msgid "Nearest: Set the nearest keyframe value"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:249
msgid ""
"Linear: Set the value based on a linear function calculation between the two "
"keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:251
msgid ""
"Cubic: Set the value based on a cubic function calculation between the two "
"keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:257
msgid "Track interpolation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:259
msgid ""
"Cubic interpolation leads to a more natural movement, where the animation is "
"slower at a keyframe and faster between keyframes. This is usually used for "
"character animation. Linear interpolation creates more of a robotic movement."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:264
msgid ""
"Godot supports two loop modes, which affect the animation if it's set to "
"loop:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:270
msgid "Loop modes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:272
msgid ""
"Clamp loop interpolation: When this is selected, the animation stops after "
"the last keyframe for this track. When the first keyframe is reached again, "
"the animation will reset to its values."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:275
msgid ""
"Wrap loop interpolation: When this is selected, Godot calculates the "
"animation after the last keyframe to reach the values of the first keyframe "
"again."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:280
#: ../../docs/tutorials/animation/introduction_2d.rst:293
msgid "Keyframes for other properties"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:282
msgid ""
"Godot doesn't restrict you to only edit transform properties. Every property "
"can be used as a track where you can set keyframes."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:285
msgid ""
"If you select your sprite while the animation panel is visible, you get a "
"small keyframe button for all the sprite's properties. Click on this button "
"and Godot automatically adds a track and keyframe to the current animation."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:296
msgid "Edit keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:298
msgid ""
"For advanced use and to edit keyframes in detail, You can click on them to "
"bring up the keyframe editor in the inspector. You can use this to directly "
"edit its values."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:305
msgid "Keyframe editor editing a key"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:307
msgid ""
"Additionally, you can also edit the easing value for this keyframe by "
"clicking and dragging the easing setting. This tells Godot, how to change "
"the property values when it reaches this keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:311
msgid ""
"You usually tweak your animations this way, when the movement doesn't \"look "
"right\"."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:315
msgid "Advanced: Call Method tracks"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:317
msgid ""
"Godot's animation engine doesn't stop here. If you're already comfortable "
"with Godot's scripting language :ref:`doc_gdscript` and :doc:`/classes/"
"index` you know that each node type is a class and has a bunch of callable "
"methods."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:323
msgid ""
"For example, the :ref:`class_AudioStreamPlayer` node type has a method to "
"play an audio stream."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:326
msgid ""
"Wouldn't it be great to use a method at a specific keyframe in an animation? "
"This is where \"Call Method Tracks\" come in handy. These tracks reference a "
"node again, this time without a reference to a property. Instead, a keyframe "
"holds the name and arguments of a method, that Godot should call when it "
"reaches this keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:332
msgid ""
"To demonstrate, we're going to use a call method track to play audio at a "
"specific keyframe. Normally to play audio you should use an audio track, but "
"for the sake of demonstrating methods we're going to do it this way."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:336
msgid ""
"Add a :ref:`class_AudioStreamPlayer` to the Scene Tree and setup a stream "
"using an audio file you put in your project."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:339
msgid ""
"Click on \"Add track\" (|Add track|) on the animation panel's track controls."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:342
msgid "Select \"Add Call Method Track\" from the list of possible track types."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:347
msgid "Add Call Method Track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:349
msgid ""
"Select the :ref:`class_AudioStreamPlayer` node in the selection window. "
"Godot adds the track with the reference to the node."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:355
msgid "Select AudioStreamPlayer"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:357
msgid ""
"Right click the timeline where Godot should play the sample and click the "
"\"Insert Key\" option. This will bring up a list of methods that can be "
"called for the AudioStreamPlayer node. Select the first one."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:364
msgid ""
"When Godot reaches the keyframe, Godot calls the :ref:"
"`class_AudioStreamPlayer` node's \"play\" function and the stream plays."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:368
msgid ""
"You can change its position by dragging it on the timeline, you can also "
"click on the keyframe and use the keyframe settings in the inspector."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:4
msgid "Cutout animation"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:7
#: ../../docs/tutorials/inputs/inputevent.rst:7
msgid "What is it?"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:9
msgid ""
"Traditionally, `cutout animation <https://en.wikipedia.org/wiki/"
"Cutout_animation>`__ is a type of `stop motion animation <https://en."
"wikipedia.org/wiki/Stop_motion>`__ in which pieces of paper (or other thin "
"material) are cut into special shapes and arranged in two-dimensional "
"representations of characters and objects. Characters' bodies are usually "
"made out of several pieces. The pieces are arranged and photographed once "
"for each frame of the film. The animator moves and rotates the parts in "
"small increments between each shot to create the illusion of movement when "
"the images are played back quickly in sequence."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:18
msgid ""
"Simulations of cutout animation can now be created using software as seen in "
"`South Park <https://en.wikipedia.org/wiki/South_Park>`__ and `Jake and the "
"Never Land Pirates <https://en.wikipedia.org/wiki/"
"Jake_and_the_Never_Land_Pirates>`__."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:22
msgid ""
"In video games, this technique has also become popular. Examples of this are "
"`Paper Mario <https://en.wikipedia.org/wiki/Super_Paper_Mario>`__ or `Rayman "
"Origins <https://en.wikipedia.org/wiki/Rayman_Origins>`__ ."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:27
msgid "Cutout animation in Godot"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:29
msgid ""
"Godot provides tools for working with cutout rigs, and is ideal for the "
"workflow:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:31
msgid ""
"**The animation system is fully integrated with the engine**: This means "
"animations can control much more than just motion of objects. Textures, "
"sprite sizes, pivots, opacity, color modulation, and more, can all be "
"animated and blended."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:35
msgid ""
"**Combine animation styles**: AnimatedSprite allows traditional cel "
"animation to be used alongside cutout animation. In cel animation different "
"animation frames use entirely different drawings rather than the same pieces "
"positioned differently. In an otherwise cutout-based animation, cel "
"animation can be used selectively for complex parts such as hands, feet, "
"changing facial expressions, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:41
msgid ""
"**Custom Shaped Elements**: Custom shapes can be created with :ref:"
"`Polygon2D <class_Polygon2D>` allowing UV animation, deformations, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:44
msgid ""
"**Particle Systems**: A cutout animation rig can be combined with particle "
"systems. This can be useful for magic effects, jetpacks, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:46
msgid ""
"**Custom Colliders**: Set colliders and influence areas in different parts "
"of the skeletons, great for bosses and fighting games."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:48
msgid ""
"**Animation Tree**: Allows complex combinations and blending between several "
"animations, the same way it works in 3D."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:51
#: ../../docs/tutorials/shading/shader_materials.rst:24
msgid "And much more!"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:54
msgid "Making of GBot"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:56
msgid ""
"For this tutorial, we will use as demo content the pieces of the `GBot "
"<https://www.youtube.com/watch?"
"v=S13FrWuBMx4&list=UUckpus81gNin1aV8WSffRKw>`__ character, created by "
"Andreas Esau."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:62
msgid ""
"Get your assets: :download:`gbot_resources.zip <files/gbot_resources.zip>`."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:65
msgid "Setting up the rig"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:67
msgid "Create an empty Node2D as root of the scene, we will work under it:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:71
msgid ""
"The first node of the model is the hip. Generally, both in 2D and 3D, the "
"hip is the root of the skeleton. This makes it easier to animate:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:77
msgid ""
"Next will be the torso. The torso needs to be a child of the hip, so create "
"a child sprite and load the torso texture, later accommodate it properly:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:82
msgid ""
"This looks good. Let's see if our hierarchy works as a skeleton by rotating "
"the torso. We can do this be pressing :kbd:`E` to enter rotate mode, and "
"dragging with the left mouse button. To exit rotate mode hit :kbd:`ESC`."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:88
msgid "The rotation pivot is wrong and needs to be adjusted."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:90
msgid ""
"This small cross in the middle of the :ref:`Sprite <class_Sprite>` is the "
"rotation pivot:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:96
msgid "Adjusting the pivot"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:98
msgid ""
"The pivot can be adjusted by changing the *offset* property in the Sprite:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:103
msgid ""
"The pivot can also be adjusted *visually*. While hovering over the desired "
"pivot point,  press :kbd:`V` to move the pivot there for the selected "
"Sprite. There is also a tool in the tool bar that has a similar function."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:110
msgid ""
"Continue adding body pieces, starting with the right arm. Make sure to put "
"each sprite in its correct place in the hierarchy, so its rotations and "
"translations are relative to its parent:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:116
msgid ""
"With the left arm there's a problem. In 2D, child nodes appear in front of "
"their parents:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:121
msgid ""
"We want the left arm to appear *behind* the hip and the torso. We could move "
"the left arm nodes behind the hip (above the hip node in the scene "
"hierarchy), but then the left arm is no longer in its proper place in the "
"hierarchy. This means it wouldn't be affected by the movement of the torso. "
"We'll fix this problem with ``RemoteTransform2D`` nodes."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:127
msgid ""
"You can also fix depth ordering problems by adjusting the Z property of any "
"node inheriting from Node2D."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:131
msgid "RemoteTransform2D node"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:133
msgid ""
"The :ref:`RemoteTransform2D <class_RemoteTransform2D>` node transforms nodes "
"somewhere else in the hierarchy. This node applies its own transform "
"(including any transformation it inherits from its parents) to the remote "
"node it targets."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:137
msgid ""
"This allows us to correct the visibility order of our elements, "
"independently of the locations of those parts in the cutout hierarchy."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:140
msgid ""
"Create a ``RemoteTransform2D`` node as a child of the torso. Call it "
"``remote_arm_l``. Create another RemoteTransform2D node inside the first and "
"call it ``remote_hand_l``. Use the ``Remote Path`` property of the two new "
"nodes to target the ``arm_l`` and ``hand_l`` sprites respectively:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:147
msgid ""
"Moving the ``RemoteTransform2D`` nodes now moves the sprites. So we can "
"create animations by adjusting the ``RemoteTransform2D`` transforms:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:153
msgid "Completing the skeleton"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:155
msgid ""
"Complete the skeleton by following the same steps for the rest of the parts. "
"The resulting scene should look similar to this:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:160
msgid ""
"The resulting rig will be easy to animate. By selecting the nodes and "
"rotating them you can animate forward kinematics (FK) efficiently."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:163
msgid "For simple objects and rigs this is fine, but there are limitations:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:165
msgid ""
"Selecting sprites in the main viewport can become difficult in complex rigs. "
"The scene tree ends up being used to select parts instead, which can be "
"slower."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:167
msgid ""
"Inverse Kinematics (IK) is useful for animating extremities like hands and "
"feet, and can't be used with our rig in its current state."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:170
msgid "To solve these problems we'll use Godot's skeletons."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:173
msgid "Skeletons"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:175
msgid ""
"In Godot there is a helper to create \"bones\" between nodes. The bone-"
"linked nodes are called skeletons."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:178
msgid ""
"As an example, let's turn the right arm into a skeleton. To create a "
"skeleton, a chain of nodes must be selected from top to bottom:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:183
msgid "Then, click on the Skeleton menu and select ``Make Bones``."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:187
msgid "This will add bones covering the arm, but the result may be surprising."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:191
msgid ""
"Why does the hand lack a bone? In Godot, a bone connects a node with its "
"parent. And there's currently no child of the hand node. With this knowledge "
"let's try again."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:195
msgid ""
"The first step is creating an endpoint node. Any kind of node will do, but :"
"ref:`Position2D <class_Position2D>` is preferred because it's visible in the "
"editor. The endpoint node will ensure that the last bone has orientation."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:202
msgid ""
"Now select the whole chain, from the endpoint to the arm and create bones:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:207
msgid ""
"The result resembles a skeleton a lot more, and now the arm and forearm can "
"be selected and animated."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:210
msgid ""
"Create endpoints for all important extremities. Generate bones for all "
"articulable parts of the cutout, with the hip as the ultimate connection "
"between all of them."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:214
msgid ""
"You may notice that an extra bone is created when connecting the hip and "
"torso. Godot has connected the hip node to the scene root with a bone, and "
"we don't want that. To fix this, select the root and hip node, open the "
"Skeleton menu, click ``clear bones``."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:221
msgid "Your final skeleton should look something like this:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:225
msgid ""
"You might have noticed a second set of endpoints in the hands. This will "
"make sense soon."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:228
msgid ""
"Now that the whole figure is rigged, the next step is setting up the IK "
"chains. IK chains allow for more natural control of extremities."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:232
msgid "IK chains"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:234
msgid ""
"IK stands for inverse kinematics. It's a convenient technique for animating "
"the position of hands, feet and other extremities of rigs like the one we've "
"made. Imagine you want to pose a character's foot in a specific position on "
"the ground. Without IK chains, each motion of the foot would require "
"rotating and positioning several other bones (the shin and the thigh at "
"least). This would be quite complex and lead to imprecise results."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:241
msgid ""
"IK allows us to move directly the foot while the shin and thigh self-adjust."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:243
msgid ""
"To create an IK chain, select a chain of bones from endpoint to the base for "
"the chain. For example, to create an IK chain for the right leg, select the "
"following:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:249
msgid "Then enable this chain for IK. Go to Edit > Make IK Chain."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:253
msgid "As a result, the base of the chain will turn *Yellow*."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:257
msgid ""
"Once the IK chain is set-up grab any child or grand-child of the base of the "
"chain (e.g. a foot) and move it. You'll see the rest of the chain adjust as "
"you adjust its position."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:264
#, fuzzy
msgid "Animation tips"
msgstr "אנימציות"

#: ../../docs/tutorials/animation/cutout_animation.rst:266
msgid ""
"The following section will be a collection of tips for creating animation "
"for your cutout rigs. For more information on how the animation system in "
"Godot works, see :ref:`doc_animations`."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:271
msgid "Setting keyframes and excluding properties"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:273
msgid ""
"Special contextual elements appear in the top toolbar when the animation "
"editor window is open:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:278
msgid ""
"The key button inserts location, rotation, and scale keyframes for the "
"selected objects or bones at the current playhead position."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:281
msgid ""
"The \"loc\", \"rot\", and \"scl\" toggle buttons to the left of the key "
"button modify its function, allowing you to specify which of the three "
"properties keyframes will be created for."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:285
msgid ""
"Here's an illustration of how this can be useful: Imagine you have a node "
"which already has two keyframes animating its scale only. You want to add an "
"overlapping rotation movement to the same node. The rotation movement should "
"begin and end at different times from the scale change that's already set "
"up. You can use the toggle buttons to have only rotation information added "
"when you add a new keyframe. This way, you can avoid adding unwanted scale "
"keyframes which would disrupt the existing scale animation."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:294
#, fuzzy
msgid "Creating a rest pose"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/animation/cutout_animation.rst:296
msgid ""
"Think of a rest pose as a default pose that your cutout rig should be set to "
"when no other pose is active in your game. Create a rest pose as follows:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:299
msgid ""
"1. Make sure the rig parts are positioned in what looks like a \"resting\" "
"arrangement."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:302
#, fuzzy
msgid "Create a new animation, rename it \"rest\"."
msgstr "אנימציות"

#: ../../docs/tutorials/animation/cutout_animation.rst:304
msgid "Select all nodes in your rig (box selection should work fine)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:306
msgid ""
"4. Make sure the \"loc\", \"rot\", and \"scl\" toggle buttons are all active "
"in the toolbar."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:309
msgid ""
"5. Press the key button. Keys will be inserted for all selected parts "
"storing their current arrangement. This pose can now be recalled when "
"necessary in your game by playing the \"rest\" animation you've created."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:316
msgid "Modifying rotation only"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:318
msgid ""
"When animating a cutout rig, often it's only the rotation of the nodes that "
"needs to change. Location and scale are rarely used."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:322
msgid ""
"So when inserting keys, you might find it convenient to have only the \"rot"
"\" toggle active most of the time:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:327
msgid ""
"This will avoid the creation of unwanted animation tracks for position and "
"scale."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:331
msgid "Keyframing IK chains"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:333
msgid ""
"When editing IK chains, it's not necessary to select the whole chain to add "
"keyframes. Selecting the endpoint of the chain and inserting a keyframe will "
"automatically insert keyframes for all other parts of the chain too."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:338
msgid "Visually move a sprite behind its parent"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:340
msgid ""
"Sometimes it is necessary to have a node change its visual depth relative to "
"its parent node during an animation. Think of a character facing the camera, "
"who pulls something out from behind his back and holds it out in front of "
"him. During this animation the whole arm and the object in his hand would "
"need to change their visual depth relative to the body of the character."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:346
msgid ""
"To help with this there's a keyframable \"Behind Parent\" property on all "
"Node2D-inheriting nodes. When planning your rig, think about the movements "
"it will need to perform and give some thought to how you'll use \"Behind "
"Parent\" and/or RemoteTransform2D nodes. They provide overlapping "
"functionality."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:354
msgid "Setting easing curves for multiple keys"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:356
msgid "To apply the same easing curve to multiple keyframes at once:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:358
msgid "Select the relevant keys."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:359
msgid ""
"Click on the pencil icon in the bottom right of the animation panel. This "
"will open the transition editor."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:361
msgid "In the transition editor, click on the desired curve to apply it."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:366
msgid "2D Skeletal deform"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:368
msgid ""
"Skeletal deform can be used to augment a cutout rig, allowing single pieces "
"to deform organically (e.g. antennae that wobble as an insect character "
"walks)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:371
msgid ""
"This process is described in a :ref:`separate tutorial <doc_2d_skeletons>`."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:4
msgid "2D skeletons"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:9
msgid ""
"When working with 3D, skeletal deforms are common for characters and "
"creatures and most 3D modelling applications support it. For 2D, as this "
"function is not used as often, it's difficult to find mainstream software "
"aimed for this."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:13
msgid ""
"One option is to create animations in third-party software such as Spine or "
"Dragonbones. From Godot 3.1 onwards, though, this functionality is supported "
"built-in."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:17
msgid ""
"Why would you want to do skeletal animations directly in Godot? The answer "
"is that there are many advantages to it:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:20
msgid ""
"Better integration with the engine, so less hassle importing and editing "
"from an external tool."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:22
msgid ""
"Ability to control particle systems, shaders, sounds, call scripts, colors, "
"transparency, etc. in animations."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:24
msgid ""
"The built-in skeletal system in Godot is very efficient and designed for "
"performance."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:27
msgid "The following tutorial will, then, explain 2D skeletal deformations."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:34
msgid ""
"Before starting, we recommend you to go through the :ref:"
"`doc_cutout_animation` tutorial to gain a general understanding of animating "
"within Godot."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:38
msgid ""
"For this tutorial, we will be using a single image to construct our "
"character. Download it from :download:`gBot_pieces.png <img/gBot_pieces."
"png>` or save the image below."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:44
msgid ""
"It is also advised to download the final character image :download:"
"`gBot_complete.png <img/gBot_complete.png>` to have a good reference for "
"putting the different pieces together."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:51
#, fuzzy
msgid "Creating the polygons"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/animation/2d_skeletons.rst:53
msgid ""
"Create a new scene for your model (if it's going to be an animated "
"character, you may want to use a ``KinematicBody2D``). For ease of use, an "
"empty 2D node is created as a root for the polygons."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:57
msgid ""
"Begin with a ``Polygon2D`` node. There is no need to place it anywhere in "
"the scene for now, so simply create it like this:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:62
msgid ""
"Select it and assign the texture with the character pieces you have "
"downloaded before:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:67
msgid ""
"Drawing a polygon directly is not advised. Instead, open the \"UV\" dialog "
"for the polygon:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:72
msgid ""
"Head over to the *Points* mode, select the pencil and draw a polygon around "
"the desired piece:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:77
msgid ""
"Duplicate the polygon node and give it a proper name. Then, enter the \"UV\" "
"dialog again and replace the old polygon with another one in the new desired "
"piece."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:81
msgid ""
"When you duplicate nodes and the next piece has a similar shape, you can "
"edit the previous polygon instead of drawing a new one."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:84
msgid ""
"After moving the polygon, remember to update the UV by selecting Edit -> "
"\"Polygon -> UV\" in the Polygon 2D UV Editor."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:89
msgid "Keep doing this until you mapped all pieces."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:93
msgid ""
"You will notice that pieces for nodes appear in the same layout as they do "
"in the original texture. This is because by default, when you draw a "
"polygon, the UV and points are the same."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:97
msgid ""
"Rearrange the pieces and build the character. This should be pretty quick. "
"There is no need to change pivots, so don't bother making sure rotation "
"pivots for each piece are right; you can leave them be for now."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:103
msgid ""
"Ah, the visual order of the pieces is not correct yet, as some are covering "
"wrong pieces. Rearrange the order of the nodes to fix this:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:108
msgid ""
"And there you go! It was definitely much easier than in the cutout tutorial."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:111
#, fuzzy
msgid "Creating the skeleton"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/animation/2d_skeletons.rst:113
msgid ""
"Create a ``Skeleton2D`` node as a child of the root node. This will be the "
"base of our skeleton:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:118
msgid ""
"Create a ``Bone2D`` node as a child of the skeleton. Put it on the hip "
"(usually skeletons start here). The bone will be pointing to the right, but "
"you can ignore this for now."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:124
msgid "Keep creating bones in hierarchy and naming them accordingly."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:128
msgid ""
"At the end of this chain, there will be a *jaw* node. It is, again, very "
"short and pointing to the right. This is normal for bones without children. "
"The length of *tip* bones can be changed with a property in the inspector:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:134
msgid ""
"In this case, we don't need to rotate the bone (coincidentally the jaw "
"points right in the sprite), but in case you need to, feel free to do it. "
"Again, this is only really needed for tip bones as nodes with children don't "
"usually need a length or a specific rotation."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:139
msgid "Keep going and build the whole skeleton:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:143
msgid ""
"You will notice that all bones raise an annoying warning about a missing "
"rest pose. This means that it's time to set one. Go to the *skeleton* node "
"and create a rest pose. This pose is the default one, you can come back to "
"it anytime you want (which is very handy for animating):"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:150
msgid ""
"The warnings will go away. If you modify the skeleton (add/remove bones) you "
"will need to set the rest pose again."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:154
msgid "Deforming the polygons"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:156
msgid ""
"Select the previously created polygons and assign the skeleton node to their "
"``Skeleton`` property. This will ensure that they can eventually be deformed "
"by it."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:162
msgid "Click the property highlighted above and select the skeleton node:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:166
msgid ""
"Again, open the UV editor for the polygon and go to the *Bones* section."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:170
msgid ""
"You will not be able to paint weights yet. For this you need to synchronize "
"the list of bones from the skeleton with the polygon. This step is done only "
"once and manually (unless you modify the skeleton by adding/removing/"
"renaming bones). It ensures that your rigging information is kept in the "
"polygon, even if a skeleton node is accidentally lost or the skeleton "
"modified. Push the \"Sync Bones to Polygon\" button to sync the list."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:179
msgid ""
"The list of bones will automatically appear. By default, your polygon has no "
"weight assigned to any of them. Select the bones you want to assign weight "
"to and paint them:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:185
msgid ""
"Points in white have a full weight assigned, while points in black are not "
"influenced by the bone. If the same point is painted white for multiple "
"bones, the influence will be distributed amongst them (so usually there is "
"not that much need to use shades in-between unless you want to polish the "
"bending effect)."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:193
msgid ""
"After painting the weights, animating the bones (NOT the polygons!) will "
"have the desired effect of modifying and bending the polygons accordingly. "
"As you only need to animate bones in this approach, work becomes much easier!"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:197
msgid ""
"But it's not all roses. Trying to animate bones that bend the polygon will "
"often yield unexpected results:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:202
msgid ""
"This happens because Godot generates internal triangles that connect the "
"points when drawing the polygon. They don't always bend the way you would "
"expect. To solve this, you need to set hints in the geometry to clarify how "
"you expect it to deform."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:208
msgid "Internal vertices"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:210
msgid ""
"Open the UV menu for each bone again and go to the *Points* section. Add "
"some internal vertices in the regions where you expect the geometry to bend:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:215
msgid ""
"Now, go to the *Polygon* section and redraw your own polygons with more "
"detail. Imagine that, as your polygons bend, you need to make sure they "
"deform the least possible, so experiment a bit to find the right setup."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:221
msgid ""
"Once you start drawing, the original polygon will disappear and you will be "
"free to create your own:"
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:226
msgid ""
"This amount of detail is usually fine, though you may want to have more fine-"
"grained control over where triangles go. Experiment by yourself until you "
"get the results you like."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:230
msgid ""
"**Note:** Don't forget that your newly added internal vertices also need "
"weight painting! Go to the *Bones* section again to assign them to the right "
"bones."
msgstr ""

#: ../../docs/tutorials/animation/2d_skeletons.rst:233
msgid "Once you are all set, you will get much better results:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:4
#, fuzzy
msgid "AnimationTree"
msgstr "אנימציות"

#: ../../docs/tutorials/animation/animation_tree.rst:9
msgid ""
"With :ref:`AnimationPlayer <class_AnimationPlayer>`, Godot has one of the "
"most flexible animation systems that you can find in any game engine. The "
"ability to animate pretty much any property in any node or resource, as well "
"as having dedicated transform, bezier, function calling, audio and sub-"
"animation tracks, is pretty much unique."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:13
msgid ""
"However, the support for blending those animations via ``AnimationPlayer`` "
"is relatively limited, as only a fixed cross-fade transition time can be set."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:15
msgid ""
":ref:`AnimationTree <class_AnimationTree>` is a new node introduced in Godot "
"3.1 to deal with advanced transitions. It supersedes the ancient "
"``AnimationTreePlayer``, while adding a huge amount of features and "
"flexibility."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:19
#, fuzzy
msgid "Creating an AnimationTree"
msgstr "אנימציות"

#: ../../docs/tutorials/animation/animation_tree.rst:21
msgid ""
"Before starting, it must be made clear that an ``AnimationTree`` node does "
"not contain its own animations. Instead, it uses animations contained in an "
"``AnimationPlayer`` node. This way, you can edit your animations (or import "
"them from a 3D scene) as usual and then use this extra node to control the "
"playback."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:25
msgid ""
"The most common way to use ``AnimationTree`` is in a 3D scene. When "
"importing your scenes from a 3D exchange format, they will usually come with "
"animations built-in (either multiple ones or split from a large one on "
"import). At the end, the imported Godot scene will contain the animations in "
"a ``AnimationPlayer`` node."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:29
msgid ""
"As you rarely use imported scenes directly in Godot (they are either "
"instantiated or inherited from), you can place the ``AnimationTree`` node in "
"your new scene which contains the imported one. Afterwards, point the "
"``AnimationTree`` node to the ``AnimationPlayer`` that was created in the "
"imported scene."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:32
msgid ""
"This is how it's done in the `Third Person Shooter demo <https://github.com/"
"godotengine/tps-demo>`_, for reference:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:36
msgid ""
"A new scene was created for the player with a ``KinematicBody`` as root. "
"Inside this scene, the original ``.dae`` (Collada) file was instantiated and "
"an ``AnimationTree`` node was created."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:40
#, fuzzy
msgid "Creating a tree"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/animation/animation_tree.rst:42
msgid ""
"There are three main types of nodes that can be used in ``AnimationTree``:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:44
msgid ""
"Animation nodes, which reference an animation from the linked "
"``AnimationTree``."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:45
msgid "Animation Root nodes, which are used to blend sub-nodes."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:46
msgid ""
"Animation Blend nodes, which are used within ``AnimationNodeBlendTree`` as "
"single-graph blending via multiple input ports."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:48
msgid "To set a root node in ``AnimationTree``, a few types are available:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:52
msgid ""
"``AnimationNodeAnimation``: Selects an animation from the list and plays it. "
"This is the simplest root node, and generally not used directly as root."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:53
msgid ""
"``AnimationNodeBlendTree``: Contains many *blend* type nodes, such as mix, "
"blend2, blend3, one shot, etc. This is one of the most commonly used roots."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:54
msgid ""
"``AnimationNodeStateMachine``: Contains multiple root nodes as children in a "
"graph. Each node is used as a *state*, and provides multiple functions to "
"alternate between states."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:55
msgid ""
"``AnimationNodeBlendSpace2D``: Allows placing root nodes in a 2D blend "
"space. Control the blend position in 2D to mix between multiple animations."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:56
msgid "``AnimationNodeBlendSpace1D``: Simplified version of the above (1D)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:59
msgid "Blend tree"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:61
msgid ""
"An ``AnimationNodeBlendTree`` can contain both root and regular nodes used "
"for blending. Nodes are added to the graph from a menu:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:65
msgid ""
"All blend trees contain an ``Output`` node by default, and something has to "
"be connected to it in order for animations to play."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:67
msgid ""
"The easiest way to test this functionality is to connect an ``Animation`` "
"node to it directly:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:71
msgid ""
"This will simply play back the animation. Make sure that the "
"``AnimationTree`` is active for something to actually happen."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:73
msgid "Following is a short description of available nodes:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:76
msgid "Blend2 / Blend3"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:78
msgid ""
"These nodes will blend between two or three inputs by a user-specified blend "
"value:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:82
msgid "For more complex blending, it is advised to use blend spaces instead."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:84
msgid ""
"Blending can also use filters, i.e. you can control individually which "
"tracks go through the blend function. This is very useful for layering "
"animations on top of each other."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:90
msgid "OneShot"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:92
msgid ""
"This node will execute a sub-animation and return once it finishes. Blend "
"times for fading in and out can be customized, as well as filters."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:97
msgid "Seek"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:99
msgid ""
"This node can be used to cause a seek command to happen to any sub-children "
"of the graph. After setting the time, this value returns to -1."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:102
msgid "TimeScale"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:104
msgid ""
"Allows scaling the speed of the animation (or reverse it) in any children "
"nodes. Setting it to 0 will pause the animation."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:107
#, fuzzy
msgid "Transition"
msgstr "התמרה"

#: ../../docs/tutorials/animation/animation_tree.rst:109
msgid ""
"Very simple state machine (when you don't want to cope with a "
"``StateMachine`` node). Animations can be connected to the outputs and "
"transition times can be specified."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:112
msgid "BlendSpace2D"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:114
msgid ""
"``BlendSpace2D`` is a node to do advanced blending in two dimensions. Points "
"are added to a two-dimensional space and then a position can be controlled "
"to determine blending:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:119
msgid ""
"The ranges in X and Y can be controlled (and labeled for convenience). By "
"default, points can be placed anywhere (just right-click on the coordinate "
"system or use the *add point* button) and triangles will be generated "
"automatically using Delaunay."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:124
msgid ""
"It is also possible to draw the triangles manually by disabling the *auto "
"triangle* option, though this is rarely necessary:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:128
msgid ""
"Finally, it is possible to change the blend mode. By default, blending "
"happens by interpolating points inside the closest triangle. When dealing "
"with 2D animations (frame by frame), you may want to switch to *Discrete* "
"mode. Alternatively, if you want to keep the current play position when "
"switching between discrete animations, there is a *Carry* mode. This mode "
"can be changed in the *Blend* menu:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:136
msgid "BlendSpace1D"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:138
msgid ""
"This is similar to 2D blend spaces, but in one dimension (so triangles are "
"not needed)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:141
msgid "StateMachine"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:143
msgid ""
"This node is a relatively simple state machine. Root nodes can be created "
"and connected via lines. States are connected via *Transitions*, which are "
"connections with special properties. Transitions are uni-directional, but "
"two can be used to connect in both ways."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:148
#, fuzzy
msgid "There are many types of transitions:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/tutorials/animation/animation_tree.rst:152
msgid ""
"*Immediate*: Will switch to the next state immediately. The current state "
"will end and blend into the beginning of the new one."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:153
msgid ""
"*Sync*: Will switch to the next state immediately, but will seek the new "
"state to the playback position of the old state."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:154
msgid ""
"*At End*: Will wait for the current state playback to end, then switch to "
"the beginning of the next state animation."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:156
msgid ""
"Transitions also have a few properties. Click any transition and it will be "
"displayed in the inspector dock:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:160
msgid ""
"*Switch Mode* is the transition type (see above), it can be modified after "
"creation here."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:161
msgid ""
"*Auto Advance* will turn on the transition automatically when this state is "
"reached. This works best with the *At End* switch mode."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:162
msgid ""
"*Advance Condition* will turn on auto advance when this condition is set. "
"This is a custom text field that can be filled with a variable name. The "
"variable can be modified from code (more on this later)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:164
msgid "*Xfade Time* is the time to cross-fade between this state and the next."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:165
msgid ""
"*Priority* is used together with the ``travel()`` function from code (more "
"on this later). When travelling from a state to another, give more priority "
"to this node."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:166
msgid ""
"*Disabled* allows to disable this transition (it will not be used during "
"travel or auto advance)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:170
msgid "Root motion"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:172
msgid ""
"When working with 3D animations, a popular technique is for animators to use "
"the root skeleton bone to give motion to the rest of the skeleton. This "
"allows animating characters in a way where steps actually match the floor "
"below. It also allows precise interaction with objects during cinematics."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:175
msgid ""
"When playing back the animation in Godot, it is possible to select this bone "
"as the *root motion track*. Doing so will cancel the bone transformation "
"visually (the animation will stay in place)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:180
msgid ""
"Afterwards, the actual motion can be retrieved via the :ref:`AnimationTree "
"<class_AnimationTree>` API as a transform:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:191
msgid ""
"This can be fed to functions such as :ref:`KinematicBody.move_and_slide "
"<class_KinematicBody_method_move_and_slide>` to control the character "
"movement."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:193
msgid ""
"There is also a tool node, ``RootMotionView``, that can be placed in a scene "
"and will act as a custom floor for your character and animations (this node "
"is normally disabled during the game)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:200
msgid "Controlling from code"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:202
msgid ""
"After building the tree and previewing it, the only question remaining is "
"\"How is all this controlled from code?\"."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:204
msgid ""
"Keep in mind that the animation nodes are just resources and, as such, they "
"are shared between all the instances. Setting values in the nodes directly "
"will affect all instances of the scene that uses this ``AnimationTree``. "
"This has some cool use cases, though, e.g. you can copy and paste parts of "
"your animation tree, or reuse nodes with a complex layout (such as a state "
"machine or blend space) in different animation trees."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:209
msgid ""
"The actual animation data is contained in the ``AnimationTree`` node and is "
"accessed via properties. Check the \"Parameters\" section of the "
"``AnimationTree`` node to see all the parameters that can be modified in "
"real-time:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:214
msgid ""
"This is handy because it makes it possible to animate them from an "
"``AnimationPlayer``, or even the ``AnimationTree`` itself, allowing the "
"realization of very complex animation logic."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:217
msgid ""
"To modify these values from code, the property path must be obtained. This "
"is done easily by hovering the mouse over any of the parameters:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:221
msgid "Which allows setting them or reading them:"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:236
msgid "State machine travel"
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:238
msgid ""
"One of the nice features in Godot's ``StateMachine`` implementation is the "
"ability to travel. The graph can be instructed to go from the current state "
"to another one, while visiting all the intermediate ones. This is done via "
"the A\\* algorithm."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:241
msgid ""
"To use the travel ability, you should first retrieve the :ref:"
"`AnimationNodeStateMachinePlayback "
"<class_AnimationNodeStateMachinePlayback>` object from the ``AnimationTree`` "
"node (it is exported as a property)."
msgstr ""

#: ../../docs/tutorials/animation/animation_tree.rst:254
msgid ""
"Once retrieved, it can be used by calling one of the many functions it "
"offers:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:4
msgid "InputEvent"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:9
msgid ""
"Managing input is usually complex, no matter the OS or platform. To ease "
"this a little, a special built-in type is provided, :ref:`InputEvent "
"<class_InputEvent>`. This datatype can be configured to contain several "
"types of input events. Input events travel through the engine and can be "
"received in multiple locations, depending on the purpose."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:15
msgid "Here is a quick example, closing your game if the escape key is hit:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:34
msgid ""
"However, it is cleaner and more flexible to use the provided :ref:`InputMap "
"<class_InputMap>` feature, which allows you to define input actions and "
"assign them different keys. This way, you can define multiple keys for the "
"same action (e.g. they keyboard escape key and the start button on a "
"gamepad). You can then more easily change this mapping in the project "
"settings without updating your code, and even build a key mapping feature on "
"top of it to allow your game to change the key mapping at runtime!"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:40
msgid ""
"You can set up your InputMap under **Project > Project Settings > Input "
"Map** and then use those actions like this:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:60
msgid "How does it work?"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:62
msgid ""
"Every input event is originated from the user/player (though it's possible "
"to generate an InputEvent and feed them back to the engine, which is useful "
"for gestures). The OS object for each platform will read events from the "
"device, then feed them to MainLoop. As :ref:`SceneTree <class_SceneTree>` is "
"the default MainLoop implementation, events are fed to it. Godot provides a "
"function to get the current SceneTree object : **get_tree()**."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:70
msgid ""
"But SceneTree does not know what to do with the event, so it will give it to "
"the viewports, starting by the \"root\" :ref:`Viewport <class_Viewport>` "
"(the first node of the scene tree). Viewport does quite a lot of stuff with "
"the received input, in order:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:77
msgid ""
"First of all, the standard :ref:`Node._input() <class_Node_method__input>` "
"function will be called in any node that overrides it (and hasn't disabled "
"input processing with :ref:`Node.set_process_input() "
"<class_Node_method_set_process_input>`). If any function consumes the event, "
"it can call :ref:`SceneTree.set_input_as_handled() "
"<class_SceneTree_method_set_input_as_handled>`, and the event will not "
"spread any more. This ensures that you can filter all events of interest, "
"even before the GUI. For gameplay input, :ref:`Node._unhandled_input() "
"<class_Node_method__unhandled_input>` is generally a better fit, because it "
"allows the GUI to intercept the events."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:82
msgid ""
"Second, it will try to feed the input to the GUI, and see if any control can "
"receive it. If so, the :ref:`Control <class_Control>` will be called via the "
"virtual function :ref:`Control._gui_input() "
"<class_Control_method__gui_input>` and the signal \"input_event\" will be "
"emitted (this function is re-implementable by script by inheriting from it). "
"If the control wants to \"consume\" the event, it will call :ref:`Control."
"accept_event() <class_Control_method_accept_event>` and the event will not "
"spread any more. Use the :ref:`Control.mouse_filter "
"<class_Control_property_mouse_filter>` property to control whether a :ref:"
"`Control <class_Control>` is notified of mouse events via :ref:`Control."
"_gui_input() <class_Control_method__gui_input>` callback, and whether these "
"events are propagated further."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:92
msgid ""
"If so far no one consumed the event, the unhandled input callback will be "
"called if overridden (and not disabled with :ref:`Node."
"set_process_unhandled_input() "
"<class_Node_method_set_process_unhandled_input>`). If any function consumes "
"the event, it can call :ref:`SceneTree.set_input_as_handled() "
"<class_SceneTree_method_set_input_as_handled>`, and the event will not "
"spread any more. The unhandled input callback is ideal for full-screen "
"gameplay events, so they are not received when a GUI is active."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:97
msgid ""
"If no one wanted the event so far, and a :ref:`Camera <class_Camera>` is "
"assigned to the Viewport, a ray to the physics world (in the ray direction "
"from the click) will be cast. If this ray hits an object, it will call the :"
"ref:`CollisionObject._input_event() "
"<class_CollisionObject_method__input_event>` function in the relevant "
"physics object (bodies receive this callback by default, but areas do not. "
"This can be configured through :ref:`Area <class_Area>` properties)."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:103
msgid ""
"Finally, if the event was unhandled, it will be passed to the next Viewport "
"in the tree, otherwise it will be ignored."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:106
msgid ""
"When sending events to all listening nodes within a scene, the viewport will "
"do so in a reverse depth-first order: Starting with the node at the bottom "
"of the scene tree, and ending at the root node:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:112
msgid ""
"GUI events also travel up the scene tree but, since these events target "
"specific Controls, only direct ancestors of the targeted Control node "
"receive the event."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:115
msgid ""
"In accordance with Godot's node-based design, this enables specialized child "
"nodes to handle and consume particular events, while their ancestors, and "
"ultimately the scene root, can provide more generalized behavior if needed."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:121
msgid "Anatomy of an InputEvent"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:123
msgid ""
":ref:`InputEvent <class_InputEvent>` is just a base built-in type, it does "
"not represent anything and only contains some basic information, such as "
"event ID (which is increased for each event), device index, etc."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:127
msgid ""
"There are several specialized types of InputEvent, described in the table "
"below:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:130
msgid "Event"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:130
msgid "Type Index"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:132
msgid ":ref:`InputEvent <class_InputEvent>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:132
msgid "NONE"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:132
msgid "Empty Input Event."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:134
msgid ":ref:`InputEventKey <class_InputEventKey>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:134
msgid "KEY"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:134
msgid "Contains a scancode and Unicode value, as well as modifiers."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:137
msgid ":ref:`InputEventMouseButton <class_InputEventMouseButton>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:137
msgid "MOUSE_BUTTON"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:137
msgid "Contains click information, such as button, modifiers, etc."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid ":ref:`InputEventMouseMotion <class_InputEventMouseMotion>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid "MOUSE_MOTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid ""
"Contains motion information, such as relative, absolute positions and speed."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
msgid ":ref:`InputEventJoypadMotion <class_InputEventJoypadMotion>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
msgid "JOYSTICK_MOTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
msgid "Contains Joystick/Joypad analog axis information."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:146
msgid ":ref:`InputEventJoypadButton <class_InputEventJoypadButton>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:146
msgid "JOYSTICK_BUTTON"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:146
msgid "Contains Joystick/Joypad button information."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:149
msgid ":ref:`InputEventScreenTouch <class_InputEventScreenTouch>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:149
msgid "SCREEN_TOUCH"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:149
msgid ""
"Contains multi-touch press/release information. (only available on mobile "
"devices)"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:153
msgid ":ref:`InputEventScreenDrag <class_InputEventScreenDrag>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:153
msgid "SCREEN_DRAG"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:153
msgid ""
"Contains multi-touch drag information. (only available on mobile devices)"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:156
msgid ":ref:`InputEventAction <class_InputEventAction>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:156
msgid "SCREEN_ACTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:156
msgid ""
"Contains a generic action. These events are often generated by the "
"programmer as feedback. (more on this below)"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:162
msgid "Actions"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:164
msgid ""
"An InputEvent may or may not represent a pre-defined action. Actions are "
"useful because they abstract the input device when programming the game "
"logic. This allows for:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:168
msgid ""
"The same code to work on different devices with different inputs (e.g., "
"keyboard on PC, Joypad on console)."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:170
msgid "Input to be reconfigured at run-time."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:172
msgid ""
"Actions can be created from the Project Settings menu in the Actions tab."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:175
msgid ""
"Any event has the methods :ref:`InputEvent.is_action() "
"<class_InputEvent_method_is_action>`, :ref:`InputEvent.is_pressed() "
"<class_InputEvent_method_is_pressed>` and :ref:`InputEvent "
"<class_InputEvent>`."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:178
msgid ""
"Alternatively, it may be desired to supply the game back with an action from "
"the game code (a good example of this is detecting gestures). The Input "
"singleton has a method for this: :ref:`Input.parse_input_event() "
"<class_input_method_parse_input_event>`. You would normally use it like this:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:203
#: ../../docs/tutorials/inputs/input_examples.rst:140
msgid "InputMap"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:205
msgid ""
"Customizing and re-mapping input from code is often desired. If your whole "
"workflow depends on actions, the :ref:`InputMap <class_InputMap>` singleton "
"is ideal for reassigning or creating different actions at run-time. This "
"singleton is not saved (must be modified manually) and its state is run from "
"the project settings (project.godot). So any dynamic system of this type "
"needs to store settings in the way the programmer best sees fit."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:4
msgid "Input examples"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:9
msgid ""
"In this tutorial, you'll learn how to use Godot's :ref:`InputEvent "
"<class_InputEvent>` system to capture player input. There are many different "
"types of input your game may use - keyboard, gamepad, mouse, etc. - and many "
"different ways to turn those inputs into actions in your game. This document "
"will show you some of the most common scenarios, which you can use as "
"starting points for your own projects."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:16
msgid ""
"For a detailed overview of how Godot's input event system works, see :ref:"
"`doc_inputevent`."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:20
msgid "Events versus polling"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:22
msgid ""
"Sometimes you want your game to respond to a certain input event - pressing "
"the \"jump\" button, for example. For other situations, you might want "
"something to happen as long as a key is pressed, such as movement. In the "
"first case, you can use the ``_input()`` function, which will be called "
"whenever an input event occurs. In the second case, Godot provides the :ref:"
"`Input <class_Input>` singleton, which you can use to query the state of an "
"input."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:29
#: ../../docs/tutorials/platform/services_for_ios.rst:399
msgid "Examples:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:62
msgid ""
"This gives you the flexibility to mix-and-match the type of input processing "
"you do."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:65
msgid ""
"For the remainder of this tutorial, we'll focus on capturing individual "
"events in ``_input()``."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:69
#: ../../docs/tutorials/gui/custom_gui_controls.rst:118
msgid "Input events"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:71
msgid ""
"Input events are objects that inherit from :ref:`InputEvent "
"<class_InputEvent>`. Depending on the event type, the object will contain "
"specific properties related to that event. To see what events actually look "
"like, add a Node and attach the following script:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:91
msgid ""
"As you press keys, move the mouse, and perform other inputs, you'll see each "
"event scroll by in the output window. Here's an example of the output:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:105
msgid ""
"As you can see, the results are very different for the different types of "
"input. Key events are even printed as their key symbols. For example, let's "
"consider :ref:`InputEventMouseButton <class_InputEventMouseButton>`. It "
"inherits from the following classes:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:109
msgid ""
":ref:`InputEvent <class_InputEvent>` - the base class for all input events"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:110
msgid ""
":ref:`InputEventWithModifiers <class_InputEventWithModifiers>` - adds the "
"ability to check if modifiers are pressed, such as :kbd:`Shift` or :kbd:"
"`Alt`."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:111
msgid ""
":ref:`InputEventMouse <class_InputEventMouse>` - adds mouse event "
"properties, such as ``position``"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:112
msgid ""
":ref:`InputEventMouseButton <class_InputEventMouseButton>` - contains the "
"index of the button that was pressed, whether it was a double-click, etc."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:114
msgid ""
"It's a good idea to keep the class reference open while you're working with "
"events so you can check the event type's available properties and methods."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:118
msgid ""
"You can encounter errors if you try to access a property on an input type "
"that doesn't contain it - calling ``position`` on ``InputEventKey`` for "
"example. To avoid this, make sure to test the event type first:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:142
msgid ""
"The :ref:`InputMap <class_InputMap>` is the most flexible way to handle a "
"variety of inputs. You use this by creating named input *actions*, to which "
"you can assign any number of input events, such as keypresses or mouse "
"clicks. A new Godot project includes a number of default actions already "
"defined. To see them, and to add your own, open Project -> Project Settings "
"and select the InputMap tab:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:152
#, fuzzy
msgid "Capturing actions"
msgstr "אנימציות"

#: ../../docs/tutorials/inputs/input_examples.rst:154
msgid ""
"Once you've defined your actions, you can process them in your scripts using "
"``is_action_pressed()`` and ``is_action_released()`` by passing the name of "
"the action you're looking for:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:176
msgid "Keyboard events"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:178
msgid ""
"Keyboard events are captured in :ref:`InputEventKey <class_InputEventKey>`. "
"While it's recommended to use input actions instead, there may be cases "
"where you want to specifically look at key events. For this example, let's "
"check for the :kbd:`T`:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:204
#: ../../docs/tutorials/inputs/input_examples.rst:242
msgid ""
"See :ref:`@GlobalScope_KeyList <enum_@GlobalScope_KeyList>` for a list of "
"scancode constants."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:208
msgid "Keyboard modifiers"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:210
msgid ""
"Modifier properties are inherited from :ref:`InputEventWithModifiers "
"<class_InputEventWithModifiers>`. This  allows you to check for modifier "
"combinations using boolean properties. Let's imagine you want one thing to "
"happen when the :kbd:`T` is pressed, but something different when it's :kbd:"
"`Shift + T`:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:246
msgid "Mouse events"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:248
msgid ""
"Mouse events stem from the :ref:`InputEventMouse <class_InputEventMouse>` "
"class, and are separated into two types: :ref:`InputEventMouseButton "
"<class_InputEventMouseButton>` and :ref:`InputEventMouseMotion "
"<class_InputEventMouseMotion>`. Note that this means that all mouse events "
"will contain a ``position`` property."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:254
msgid "Mouse buttons"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:256
msgid ""
"Capturing mouse buttons is very similar to handling key events. :ref:"
"`@GlobalScope_ButtonList <enum_@GlobalScope_ButtonList>` contains a list of "
"``BUTTON_*`` constants for each possible button, which will be reported in "
"the event's ``button_index`` property. Note that the scrollwheel also counts "
"as a button - two buttons, to be precise, with both ``BUTTON_WHEEL_UP`` and "
"``BUTTON_WHEEL_DOWN`` being separate events."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:291
#, fuzzy
msgid "Mouse motion"
msgstr "אנימציות"

#: ../../docs/tutorials/inputs/input_examples.rst:293
msgid ""
":ref:`InputEventMouseMotion <class_InputEventMouseMotion>` events occur "
"whenever the mouse moves. You can find the move's distance with the "
"``relative`` property."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:297
msgid ""
"Here's an example using mouse events to drag-and-drop a :ref:`Sprite "
"<class_Sprite>` node:"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:355
msgid "Touch events"
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:357
msgid ""
"If you are using a touchscreen device, you can generate touch events. :ref:"
"`InputEventScreenTouch <class_InputEventScreenTouch>` is equivalent to a "
"mouse click event, and :ref:`InputEventScreenDrag "
"<class_InputEventScreenDrag>` works much the same as mouse motion."
msgstr ""

#: ../../docs/tutorials/inputs/input_examples.rst:362
msgid ""
"To test your touch events on a non-touchscreen device, open Project Settings "
"and go to the \"Input Devices/Pointing\" section. Enable \"Emulate Touch "
"From Mouse\" and your project will interpret mouse clicks and motion as "
"touch events."
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:4
msgid "Mouse and input coordinates"
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:9
msgid ""
"The reason for this small tutorial is to clear up many common mistakes about "
"input coordinates, obtaining mouse position and screen resolution, etc."
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:14
msgid "Hardware display coordinates"
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:16
msgid ""
"Using hardware coordinates makes sense in the case of writing complex UIs "
"meant to run on PC, such as editors, MMOs, tools, etc. However, it does not "
"make as much sense outside of that scope."
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:21
msgid "Viewport display coordinates"
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:23
msgid ""
"Godot uses viewports to display content, and viewports can be scaled by "
"several options (see :ref:`doc_multiple_resolutions` tutorial). Use, then, "
"the functions in nodes to obtain the mouse coordinates and viewport size, "
"for example:"
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:55
msgid ""
"Alternatively, it's possible to ask the viewport for the mouse position:"
msgstr ""

#: ../../docs/tutorials/inputs/mouse_and_input_coordinates.rst:66
msgid ""
"When the mouse mode is set to ``Input.MOUSE_MODE_CAPTURED``, the ``event."
"position`` value from ``InputEventMouseMotion`` is the center of the screen. "
"Use ``event.relative`` instead of ``event.position`` and ``event.speed`` to "
"process mouse movement and position changes."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:4
msgid "Customizing the mouse cursor"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:6
msgid ""
"You might want to change the appearance of the mouse cursor in your game in "
"order to suit the overall design. There are two ways to customize the mouse "
"cursor:"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:8
#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:25
msgid "Using project settings"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:9
#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:37
msgid "Using a script"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:11
msgid ""
"Using project settings is a simpler (but more limited) way to customize the "
"mouse cursor. The second way is more customizable, but involves scripting."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:15
msgid ""
"You could display a \"software\" mouse cursor by hiding the mouse cursor and "
"moving a Sprite to the cursor position in a ``_process`` method, but this "
"will add at least one frame of latency compared to an \"hardware\" mouse "
"cursor. Therefore, it's recommended to use the approach described here "
"whenever possible."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:21
msgid ""
"If you have to use the \"software\" approach, consider adding an "
"extrapolation step to better display the actual mouse input."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:27
msgid ""
"Open project settings, go to Display>Mouse Cursor. You will see Custom Image "
"and Custom Image Hotspot."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:31
msgid ""
"Custom Image is the desired image that you would like to set as the mouse "
"cursor. Custom Hotspot is the point in the image that you would like to use "
"as the cursor's detection point."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:34
msgid "The custom image **must** be less than 256x256."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:39
msgid "Create a Node and attach the following script."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:75
msgid ""
"Check :ref:`Input.set_custom_mouse_cursor() "
"<class_Input_method_set_custom_mouse_cursor>`."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:79
msgid "Demo project"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:81
msgid ""
"Find out more by studying this demo project: https://github.com/"
"guilhermefelipecgs/custom_hardware_cursor"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:85
msgid "Cursor list"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:87
msgid ""
"As documented in the :ref:`Input <class_Input>` class (see the "
"**CursorShape** enum), there are multiple mouse cursors you can define. "
"Which ones you want to use depends on your use case."
msgstr ""

#: ../../docs/tutorials/io/index.rst:2
msgid "I/O"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:4
msgid "Background loading"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:6
msgid ""
"When switching the main scene of your game (e.g. going to a new level), you "
"might want to show a loading screen with some indication that progress is "
"being made. The main load method (``ResourceLoader::load`` or just ``load`` "
"from GDScript) blocks your thread, making your game appear frozen and "
"unresponsive while the resource is being loaded. This document discusses the "
"alternative of using the ``ResourceInteractiveLoader`` class for smoother "
"load screens."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:15
msgid "ResourceInteractiveLoader"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:17
msgid ""
"The ``ResourceInteractiveLoader`` class allows you to load a resource in "
"stages. Every time the method ``poll`` is called, a new stage is loaded, and "
"control is returned to the caller. Each stage is generally a sub-resource "
"that is loaded by the main resource. For example, if you're loading a scene "
"that loads 10 images, each image will be one stage."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:24
#: ../../docs/tutorials/platform/android_in_app_purchases.rst:32
#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Usage"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:26
msgid "Usage is generally as follows"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:29
msgid "Obtaining a ResourceInteractiveLoader"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:35
msgid ""
"This method will give you a ResourceInteractiveLoader that you will use to "
"manage the load operation."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:39
msgid "Polling"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:45
msgid ""
"Use this method to advance the progress of the load. Each call to ``poll`` "
"will load the next stage of your resource. Keep in mind that each stage is "
"one entire \"atomic\" resource, such as an image, or a mesh, so it will take "
"several frames to load."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:50
msgid ""
"Returns ``OK`` on no errors, ``ERR_FILE_EOF`` when loading is finished. Any "
"other return value means there was an error and loading has stopped."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:54
msgid "Load progress (optional)"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:56
msgid "To query the progress of the load, use the following methods:"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:63
msgid ""
"``get_stage_count`` returns the total number of stages to load. "
"``get_stage`` returns the current stage being loaded."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:67
msgid "Forcing completion (optional)"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:73
msgid ""
"Use this method if you need to load the entire resource in the current "
"frame, without any more steps."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:77
msgid "Obtaining the resource"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:83
msgid ""
"If everything goes well, use this method to retrieve your loaded resource."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:89
msgid ""
"This example demonstrates how to load a new scene. Consider it in the "
"context of the :ref:`doc_singletons_autoload` example."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:92
msgid ""
"First, we set up some variables and initialize the ``current_scene`` with "
"the main scene of the game:"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:106
msgid ""
"The function ``goto_scene`` is called from the game when the scene needs to "
"be switched. It requests an interactive loader, and calls "
"``set_process(true)`` to start polling the loader in the ``_process`` "
"callback. It also starts a \"loading\" animation, which could show a "
"progress bar or loading screen."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:128
msgid ""
"``_process`` is where the loader is polled. ``poll`` is called, and then we "
"deal with the return value from that call. ``OK`` means keep polling, "
"``ERR_FILE_EOF`` means loading is done, anything else means there was an "
"error. Also note we skip one frame (via ``wait_frames``, set on the "
"``goto_scene`` function) to allow the loading screen to show up."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:134
msgid ""
"Note how we use ``OS.get_ticks_msec`` to control how long we block the "
"thread. Some stages might load fast, which means we might be able to cram "
"more than one call to ``poll`` in one frame; some might take way more than "
"your value for ``time_max``, so keep in mind we won't have precise control "
"over the timings."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:170
msgid ""
"Some extra helper functions. ``update_progress`` updates a progress bar, or "
"can also update a paused animation (the animation represents the entire load "
"process from beginning to end). ``set_new_scene`` puts the newly loaded "
"scene on the tree. Because it's a scene being loaded, ``instance()`` needs "
"to be called on the resource obtained from the loader."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:195
#: ../../docs/tutorials/threads/using_multiple_threads.rst:4
msgid "Using multiple threads"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:197
msgid ""
"ResourceInteractiveLoader can be used from multiple threads. A couple of "
"things to keep in mind if you attempt it:"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:201
msgid "Use a semaphore"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:203
msgid ""
"While your thread waits for the main thread to request a new resource, use a "
"``Semaphore`` to sleep (instead of a busy loop or anything similar)."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:207
msgid "Not blocking main thread during the polling"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:209
msgid ""
"If you have a mutex to allow calls from the main thread to your loader "
"class, don't lock the main thread while you call ``poll`` on your loader "
"class. When a resource is done loading, it might require some resources from "
"the low-level APIs (VisualServer, etc), which might need to lock the main "
"thread to acquire them. This might cause a deadlock if the main thread is "
"waiting for your mutex while your thread is waiting to load a resource."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:218
msgid "Example class"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:220
msgid ""
"You can find an example class for loading resources in threads here: :"
"download:`resource_queue.gd <files/resource_queue.gd>`. Usage is as follows:"
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:227
msgid "Call after you instance the class to start the thread."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:233
msgid ""
"Queue a resource. Use optional argument \"p_in_front\" to put it in front of "
"the queue."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:240
msgid "Remove a resource from the queue, discarding any loading done."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:246
msgid ""
"Returns ``true`` if a resource is fully loaded and ready to be retrieved."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:252
msgid ""
"Get the progress of a resource. Returns -1 if there was an error (for "
"example if the resource is not in the queue), or a number between 0.0 and "
"1.0 with the progress of the load. Use mostly for cosmetic purposes "
"(updating progress bars, etc), use ``is_ready`` to find out if a resource is "
"actually ready."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:262
msgid ""
"Returns the fully loaded resource, or ``null`` on error. If the resource is "
"not fully loaded (``is_ready`` returns ``false``), it will block your thread "
"and finish the load. If the resource is not on the queue, it will call "
"``ResourceLoader::load`` to load it normally and return it."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:298
msgid ""
"**Note**: this code, in its current form, is not tested in real world "
"scenarios. If you run into any issues, ask for help in one of `Godot's "
"community channels <https://godotengine.org/community>`__."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:4
msgid "Data paths"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:7
msgid "Path separators"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:9
msgid ""
"For the sake of supporting as many platforms as possible, Godot only accepts "
"UNIX-style path separators (``/``). These work on all platforms, including "
"Windows."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:13
msgid "A path like ``C:\\Projects`` will become ``C:/Projects``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:18
msgid ""
"As mentioned in the :ref:`doc_command_line_tutorial`, Godot considers that a "
"project exists in any given folder that contains a ``project.godot`` text "
"file, even if such file is empty."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:22
msgid ""
"Accessing project files can be done by opening any path with ``res://`` as a "
"base. For example, a texture located in the root of the project folder may "
"be opened from the following path: ``res://some_texture.png``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:27
msgid "User path (persistent data)"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:29
msgid ""
"While the project is running, it is a common scenario that the resource path "
"will be read-only, due to it being inside a package, self-contained "
"executable, or system-wide install location."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:33
msgid ""
"Storing persistent files in such scenarios should be done by using the "
"``user://`` prefix, for example: ``user://game_save.txt``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:36
msgid ""
"On some devices (for example, mobile and consoles), this path is unique to "
"the project. On desktop operating systems, the engine uses the typical ``~/."
"local/share/godot/app_userdata/Name`` on macOS and Linux, and ``%APPDATA%/"
"Name`` on Windows. ``Name`` is taken from the application name defined in "
"the Project Settings, but it can be overridden on a per-platform basis "
"using :ref:`feature tags <doc_feature_tags>`."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:45
msgid "Editor data paths"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:47
msgid ""
"The editor uses different paths for user data, user settings and cache "
"depending on the platform. By default, these paths are:"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:53
msgid "User data"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:53
#: ../../docs/tutorials/io/data_paths.rst:57
msgid "Windows: ``%APPDATA%\\Godot\\``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:54
#: ../../docs/tutorials/io/data_paths.rst:58
msgid "macOS: ``~/Library/Application Support/Godot/``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:55
msgid "Linux: ``~/.local/share/godot/``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:57
msgid "User settings"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:59
msgid "Linux: ``~/.config/godot/``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:61
msgid "Cache"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:61
msgid "Windows: ``%TEMP%\\Godot\\``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:62
msgid "macOS: ``~/Library/Caches/Godot/``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:63
msgid "Linux: ``~/.cache/godot/``"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:66
msgid "**User data** contains export templates and project-specific data."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:67
msgid ""
"**User settings** contains editor settings, text editor themes, script "
"templates, etc."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:69
msgid ""
"**Cache** contains temporary data. It can safely be removed when Godot is "
"closed."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:72
msgid ""
"Godot complies with the `XDG Base Directory Specification <https://"
"specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html>`__ on "
"all platforms. Environment variables can be overridden as per the "
"specification to change the editor (and project) data paths."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:77
msgid ""
"If you use `Godot packaged as a Flatpak <https://flathub.org/apps/details/"
"org.godotengine.Godot>`__, the editor data paths will be located in "
"subfolders in ``~/.var/app/org.godotengine.Godot/``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:85
msgid "Self-contained mode"
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:87
msgid ""
"If you create a file called ``._sc_`` or ``_sc_`` in the same directory as "
"the editor binary, Godot will enable *self-contained mode*. This will make "
"Godot write all user data to a directory named ``editor_data/`` in the same "
"directory as the editor binary. This is useful to create a \"portable\" "
"installation, which can then be placed on an USB drive."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:93
msgid ""
"The `Steam release of Godot <https://store.steampowered.com/app/404790/>`__ "
"uses self-contained mode by default."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:4
msgid "Saving games"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:9
msgid ""
"Save games can be complicated. For example, it may be desirable to store "
"information from multiple objects across multiple levels. Advanced save game "
"systems should allow for additional information about an arbitrary number of "
"objects. This will allow the save function to scale as the game grows more "
"complex."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:17
msgid ""
"If you're looking to save user configuration, you can use the :ref:"
"`class_ConfigFile` class for this purpose."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:21
msgid "Identify persistent objects"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:23
msgid ""
"Firstly, we should identify what objects we want to keep between game "
"sessions and what information we want to keep from those objects. For this "
"tutorial, we will use groups to mark and handle objects to be saved, but "
"other methods are certainly possible."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:28
msgid ""
"We will start by adding objects we wish to save to the \"Persist\" group. As "
"in the :ref:`doc_scripting_continued` tutorial, we can do this through "
"either the GUI or script. Let's add the relevant nodes using the GUI:"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:34
msgid ""
"Once this is done, when we need to save the game, we can get all objects to "
"save them and then tell them all to save with this script:"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:54
msgid "Serializing"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:56
msgid ""
"The next step is to serialize the data. This makes it much easier to read "
"from and store to disk. In this case, we're assuming each member of group "
"Persist is an instanced node and thus has a path. GDScript has helper "
"functions for this, such as :ref:`to_json() "
"<class_@GDScript_method_to_json>` and :ref:`parse_json() "
"<class_@GDScript_method_parse_json>`, so we will use a dictionary. Our node "
"needs to contain a save function that returns this data. The save function "
"will look like this:"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:119
msgid ""
"This gives us a dictionary with the style ``{ \"variable_name\":"
"value_of_variable }``, which will be useful when loading."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:124
msgid "Saving and reading data"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:126
msgid ""
"As covered in the :ref:`doc_filesystem` tutorial, we'll need to open a file "
"so we can write to it or read from it. Now that we have a way to call our "
"groups and get their relevant data, let's use :ref:`to_json() "
"<class_@GDScript_method_to_json>` to convert it into an easily stored string "
"and store them in a file. Doing it this way ensures that each line is its "
"own object, so we have an easy way to pull the data out of the file as well."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:202
msgid ""
"Game saved! Loading is fairly simple as well. For that, we'll read each "
"line, use parse_json() to read it back to a dict, and then iterate over the "
"dict to read our values. But we'll need to first create the object and we "
"can use the filename and parent values to achieve that. Here is our load "
"function:"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:292
msgid ""
"Now we can save and load an arbitrary number of objects laid out almost "
"anywhere across the scene tree! Each object can store different data "
"depending on what it needs to save."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:297
msgid "Some notes"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:299
msgid ""
"We have glossed over setting up the game state for loading. It's ultimately "
"up to the project creator where much of this logic goes. This is often "
"complicated and will need to be heavily customized based on the needs of the "
"individual project."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:304
msgid ""
"Additionally, our implementation assumes no Persist objects are children of "
"other Persist objects. Otherwise, invalid paths would be created. To "
"accommodate nested Persist objects, consider saving objects in stages. Load "
"parent objects first so they are available for the :ref:`add_child() "
"<class_node_method_add_child>` call when child objects are loaded. You will "
"also need a way to link children to parents as the :ref:`NodePath "
"<class_nodepath>` will likely be invalid."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:4
msgid "Encrypting save games"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:12
msgid ""
"Because the world today is not the world of yesterday. A capitalist "
"oligarchy runs the world and forces us to consume in order to keep the gears "
"of this rotten society on track. As such, the biggest market for video game "
"consumption today is the mobile one. It is a market of poor souls forced to "
"compulsively consume digital content in order to forget the misery of their "
"everyday life, commute, or just any other brief free moment they have that "
"they are not using to produce goods or services for the ruling class. These "
"individuals need to keep focusing on their video games (because not doing so "
"will fill them with tremendous existential angst), so they go as far as "
"spending money on them to extend their experience, and their preferred way "
"of doing so is through in-app purchases and virtual currency."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:25
msgid ""
"But what if someone were to find a way to edit the saved games and assign "
"the items and currency without effort? That would be terrible, because it "
"would help players consume the content much faster, and therefore run out of "
"it sooner than expected. If that happens, they will have nothing that avoids "
"them to think, and the tremendous agony of realizing their own irrelevance "
"would again take over their life."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:32
msgid ""
"No, we definitely do not want that to happen, so let's see how to encrypt "
"savegames and protect the world order."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:36
msgid "How?"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:38
msgid ""
"The class :ref:`File <class_File>` can open a file at a location and read/"
"write data (integers, strings and variants). It also supports encryption. To "
"create an encrypted file, a passphrase must be provided, like this:"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:58
msgid ""
"This will make the file unreadable to users, but will still not prevent them "
"from sharing savefiles. To solve this, use the device unique id or some "
"unique user identifier, for example:"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:77
msgid "Note that ``OS.get_unique_id()`` does not work on UWP or HTML5."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:79
msgid "That is all! Thank you for your cooperation, citizen."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:81
msgid ""
"This method cannot really prevent players from editing their savegames "
"locally because, since the encryption key is stored inside the game, the "
"player can still decrypt and edit the file themselves. The only way to "
"prevent this from being possible is to store the save data on a remote "
"server, where players can only make authorized changes to their save data. "
"If your game deals with real money, you need to be doing this anyway."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:4
msgid "Internationalizing games"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:9
msgid ""
"Sería excelente que el mundo hablara solo un idioma (It would be great if "
"the world spoke only one language). Unfortunately for us developers, that is "
"not the case. While indie or niche games usually do not need localization, "
"games targeting a more massive market often require localization. Godot "
"offers many tools to make this process more straightforward, so this "
"tutorial is more like a collection of tips and tricks."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:17
msgid ""
"Localization is usually done by specific studios hired for the job and, "
"despite the huge amount of software and file formats available for this, the "
"most common way to do localization to this day is still with spreadsheets. "
"The process of creating the spreadsheets and importing them is already "
"covered in the :ref:`doc_importing_translations` tutorial, so this one could "
"be seen more like a follow-up to that one."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:25
msgid ""
"We will be using the official demo as an example; you can `download it from "
"the Asset Library <https://godotengine.org/asset-library/asset/134>`_."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:29
msgid "Configuring the imported translation"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:31
msgid ""
"Translations can get updated and re-imported when they change, but they "
"still have to be added to the project. This is done in **Project → Project "
"Settings → Localization**:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:37
msgid "The above dialog is used to add or remove translations project-wide."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:40
msgid "Localizing resources"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:42
msgid ""
"It is also possible to instruct Godot to use alternate versions of assets "
"(resources) depending on the current language. The **Remaps** tab can be "
"used for this:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:48
msgid ""
"Select the resource to be remapped, then add some alternatives for each "
"locale."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:52
msgid "Converting keys to text"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:54
msgid ""
"Some controls, such as :ref:`Button <class_Button>` and :ref:`Label "
"<class_Label>`, will automatically fetch a translation if their text matches "
"a translation key. For example, if a label's text is "
"\"MAIN_SCREEN_GREETING1\" and that key exists in the current translation, "
"then the text will automatically be translated."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:59
msgid ""
"In code, the :ref:`Object.tr() <class_Object_method_tr>` function can be "
"used. This will just look up the text in the translations and convert it if "
"found:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:69
msgid "Making controls resizable"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:71
msgid ""
"The same text in different languages can vary greatly in length. For this, "
"make sure to read the tutorial on :ref:`doc_size_and_anchors`, as "
"dynamically adjusting control sizes may help. :ref:`Container "
"<class_Container>` can be useful, as well as the text wrapping options "
"available in :ref:`Label <class_Label>`."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:78
msgid "TranslationServer"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:80
msgid ""
"Godot has a server handling low-level translation management called the :ref:"
"`TranslationServer <class_TranslationServer>`. Translations can be added or "
"removed during run-time; the current language can also be changed at run-"
"time."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:86
msgid "Command line"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:88
msgid ""
"Language can be tested when running Godot from the command line. For "
"example, to test a game in French, the following argument can be supplied:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:97
msgid "Translating the project name"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:99
msgid ""
"The project name becomes the app name when exporting to different operating "
"systems and platforms. To specify the project name in more than one "
"language, create a new setting ``application/name`` in the **Project "
"Settings** and append the locale identifier to it. For instance, for "
"Spanish, this would be ``application/name_es``:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:107
msgid ""
"If you are unsure about the language code to use, refer to the :ref:`list of "
"locale codes <doc_locales>`."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:4
msgid "Localization using gettext"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:6
msgid ""
"In addition to :ref:`doc_importing_translations` in CSV format, Godot also "
"supports loading translation files written in the GNU gettext (``.po``) "
"format."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:10
msgid ""
"For an introduction to gettext, check out `A Quick Gettext Tutorial <https://"
"www.labri.fr/perso/fleury/posts/programming/a-quick-gettext-tutorial."
"html>`_. It's written with C projects in mind, but much of the advice also "
"applies to Godot (with the exception of ``xgettext``)."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:16
msgid "Advantages"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:18
msgid ""
"gettext is a standard format, which can be edited using any text editor or "
"GUI editors such as `Poedit <https://poedit.net/>`_."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:20
msgid ""
"gettext is supported by translation platforms such as `Transifex <https://"
"www.transifex.com/>`_ and `Weblate <https://weblate.org/>`_, which makes it "
"easier for people to collaborate to localization."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:23
msgid ""
"Compared to CSV, gettext works better with version control systems like Git, "
"as each locale has its own messages file."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:25
msgid ""
"Multiline strings are more convenient to edit in gettext files compared to "
"CSV files."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:29
msgid "Disadvantages"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:31
msgid ""
"gettext is a more complex format than CSV and can be harder to grasp for "
"people new to software localization."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:33
msgid ""
"People who maintain localization files will have to install gettext tools on "
"their system. However, as Godot doesn't use compiled message object files "
"(``.mo``), translators can test their work without having to install gettext "
"tools."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:39
msgid "Caveats"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:41
msgid ""
"As Godot uses its own PO file parser behind the scenes (which is more "
"limited than the reference GNU gettext implementation), some features such "
"as pluralization aren't supported."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:46
msgid "Installing gettext tools"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:48
msgid ""
"The command line gettext tools are required to perform maintenance "
"operations, such as updating message files. Therefore, it's strongly "
"recommended to install them."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:52
msgid ""
"**Windows:** Download an installer from `this page <https://mlocati.github."
"io/articles/gettext-iconv-windows.html>`_. Any architecture and binary type "
"(shared or static) works; if in doubt, choose the 64-bit static installer."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:56
msgid ""
"**macOS:** Use `Homebrew <https://brew.sh/>`_ to install gettext with the "
"``brew install gettext`` command."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:58
msgid ""
"**Linux:** On most distributions, install the ``gettext`` package from your "
"distribution's package manager."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:62
#, fuzzy
msgid "Creating the PO template (POT) manually"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:64
msgid ""
"Godot currently doesn't support extracting source strings using "
"``xgettext``, so the ``.pot`` file must be created manually. This file can "
"be placed anywhere in the project directory, but it's recommended to keep it "
"in a subdirectory, as each locale will be defined in its own file."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:69
msgid ""
"Create a directory named `locale` in the project directory. In this "
"directory, save a file named ``messages.pot`` with the following contents:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:81
msgid ""
"Messages in gettext are made of ``msgid`` and ``msgstr`` pairs. ``msgid`` is "
"the source string (usually in English), ``msgstr`` will be the translated "
"string."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:85
msgid ""
"The ``msgstr`` value in PO template files (``.pot``) should **always** be "
"empty. Localization will be done in the generated ``.po`` files instead."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:89
#, fuzzy
msgid "Creating the PO template (POT) using pybabel"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:91
msgid ""
"The Python tool pybabel has support for Godot and can be used to "
"automatically create and update the POT file from your scene files and "
"scripts."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:94
msgid "After installing ``babel`` and ``babel-godot``, for example using pip:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:100
msgid ""
"Write a mapping file (for example ``babelrc``) which will indicate which "
"files pybabel needs to process (note that we process GDScript as Python, "
"which is generally sufficient):"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:112
msgid "You can then run pybabel like so:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:118
msgid ""
"Use the ``-k`` option to specify what needs to be extracted. In this case, "
"arguments to :ref:`tr() <class_Object_method_tr>` will be translated, as "
"well as properties named \"text\" (commonly used by Control nodes) and "
"LineEdit's \"placeholder_text\" property."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:124
msgid "Creating a messages file from a PO template"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:126
msgid ""
"The ``msginit`` command is used to turn a PO template into a messages file. "
"For instance, to create a French localization file, use the following "
"command while in the ``locale`` directory:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:134
msgid ""
"The command above will create a file named ``fr.po`` in the same directory "
"as the PO template."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:137
msgid ""
"Alternatively, you can do that graphically using Poedit, or by uploading the "
"POT file to your web platform of choice."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:141
msgid "Loading a messages file in Godot"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:143
msgid ""
"To register a messages file as a translation in a project, open the "
"**Project Settings**, then go to the **Localization** tab. In "
"**Translations**, click **Add…** then choose the ``.po`` file in the file "
"dialog. The locale will be inferred from the ``\"Language: <code>\\n\"`` "
"property in the messages file."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:149
msgid ""
"See :ref:`doc_internationalizing_games` for more information on importing "
"and testing translations in Godot."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:153
msgid "Updating message files to follow the PO template"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:155
msgid ""
"After updating the PO template, you will have to update message files so "
"that they contain new strings, while removing strings that are no longer "
"present in the PO template removed in the PO template. This can be done "
"automatically using the ``msgmerge`` tool:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:165
msgid ""
"If you want to keep a backup of the original message file (which would be "
"saved as ``fr.po~`` in this example), remove the ``--backup=none`` argument."
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:169
msgid "Checking the validity of a PO file or template"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:171
msgid ""
"It is possible to check whether a gettext file's syntax is valid by running "
"the command below:"
msgstr ""

#: ../../docs/tutorials/i18n/localization_using_gettext.rst:178
msgid ""
"If there are syntax errors or warnings, they will be displayed in the "
"console. Otherwise, ``msgfmt`` won't output anything."
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:4
msgid "Locales"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:6
msgid ""
"This is the list of supported locales and variants in the engine. It's based "
"on the Unix standard locale strings:"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:10
msgid "Locale"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:10
msgid "Language and Variant"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:12
msgid "aa"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:12
msgid "Afar"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:14
msgid "aa_DJ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:14
msgid "Afar (Djibouti)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:16
msgid "aa_ER"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:16
msgid "Afar (Eritrea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:18
msgid "aa_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:18
msgid "Afar (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:20
msgid "af"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:20
msgid "Afrikaans"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:22
msgid "af_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:22
msgid "Afrikaans (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:24
msgid "agr_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:24
msgid "Aguaruna (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:26
msgid "ak_GH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:26
msgid "Akan (Ghana)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:28
msgid "am_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:28
msgid "Amharic (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:30
msgid "an_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:30
msgid "Aragonese (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:32
msgid "anp_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:32
msgid "Angika (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:34
msgid "ar"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:34
msgid "Arabic"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:36
msgid "ar_AE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:36
msgid "Arabic (United Arab Emirates)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:38
msgid "ar_BH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:38
msgid "Arabic (Bahrain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:40
msgid "ar_DZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:40
msgid "Arabic (Algeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:42
msgid "ar_EG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:42
msgid "Arabic (Egypt)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:44
msgid "ar_IQ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:44
msgid "Arabic (Iraq)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:46
msgid "ar_JO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:46
msgid "Arabic (Jordan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:48
msgid "ar_KW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:48
msgid "Arabic (Kuwait)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:50
msgid "ar_LB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:50
msgid "Arabic (Lebanon)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:52
msgid "ar_LY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:52
msgid "Arabic (Libya)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:54
msgid "ar_MA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:54
msgid "Arabic (Morocco)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:56
msgid "ar_OM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:56
msgid "Arabic (Oman)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:58
msgid "ar_QA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:58
msgid "Arabic (Qatar)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:60
msgid "ar_SA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:60
msgid "Arabic (Saudi Arabia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:62
msgid "ar_SD"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:62
msgid "Arabic (Sudan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:64
msgid "ar_SY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:64
msgid "Arabic (Syria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:66
msgid "ar_TN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:66
msgid "Arabic (Tunisia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:68
msgid "ar_YE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:68
msgid "Arabic (Yemen)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:70
msgid "as_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:70
msgid "Assamese (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:72
msgid "ast_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:72
msgid "Asturian (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:74
msgid "ayc_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:74
msgid "Southern Aymara (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:76
msgid "ay_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:76
msgid "Aymara (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:78
msgid "az_AZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:78
msgid "Azerbaijani (Azerbaijan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:80
msgid "be"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:80
msgid "Belarusian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:82
msgid "be_BY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:82
msgid "Belarusian (Belarus)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:84
msgid "bem_ZM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:84
msgid "Bemba (Zambia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:86
msgid "ber_DZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:86
msgid "Berber languages (Algeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:88
msgid "ber_MA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:88
msgid "Berber languages (Morocco)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:90
msgid "bg"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:90
msgid "Bulgarian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:92
msgid "bg_BG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:92
msgid "Bulgarian (Bulgaria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:94
msgid "bhb_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:94
msgid "Bhili (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:96
msgid "bho_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:96
msgid "Bhojpuri (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:98
msgid "bi_TV"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:98
msgid "Bislama (Tuvalu)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:100
msgid "bn"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:100
msgid "Bengali"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:102
msgid "bn_BD"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:102
msgid "Bengali (Bangladesh)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:104
msgid "bn_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:104
msgid "Bengali (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:106
msgid "bo"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:106
msgid "Tibetan"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:108
msgid "bo_CN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:108
msgid "Tibetan (China)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:110
msgid "bo_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:110
msgid "Tibetan (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:112
msgid "br_FR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:112
msgid "Breton (France)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:114
msgid "brx_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:114
msgid "Bodo (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:116
msgid "bs_BA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:116
msgid "Bosnian (Bosnia and Herzegovina)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:118
msgid "byn_ER"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:118
msgid "Bilin (Eritrea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:120
msgid "ca"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:120
msgid "Catalan"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:122
msgid "ca_AD"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:122
msgid "Catalan (Andorra)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:124
msgid "ca_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:124
msgid "Catalan (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:126
msgid "ca_FR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:126
msgid "Catalan (France)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:128
msgid "ca_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:128
msgid "Catalan (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:130
msgid "ce_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:130
msgid "Chechen (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:132
msgid "chr_US"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:132
msgid "Cherokee (United States)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:134
msgid "cmn_TW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:134
msgid "Mandarin Chinese (Taiwan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:136
msgid "crh_UA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:136
msgid "Crimean Tatar (Ukraine)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:138
msgid "csb_PL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:138
msgid "Kashubian (Poland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:140
msgid "cs"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:140
msgid "Czech"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:142
msgid "cs_CZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:142
msgid "Czech (Czech Republic)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:144
msgid "cv_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:144
msgid "Chuvash (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:146
msgid "cy_GB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:146
msgid "Welsh (United Kingdom)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:148
msgid "da"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:148
msgid "Danish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:150
msgid "da_DK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:150
msgid "Danish (Denmark)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:152
msgid "de"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:152
msgid "German"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:154
msgid "de_AT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:154
msgid "German (Austria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:156
msgid "de_BE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:156
msgid "German (Belgium)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:158
msgid "de_CH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:158
msgid "German (Switzerland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:160
msgid "de_DE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:160
msgid "German (Germany)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:162
msgid "de_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:162
msgid "German (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:164
msgid "de_LU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:164
msgid "German (Luxembourg)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:166
msgid "doi_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:166
msgid "Dogri (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:168
msgid "dv_MV"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:168
msgid "Dhivehi (Maldives)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:170
msgid "dz_BT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:170
msgid "Dzongkha (Bhutan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:172
msgid "el"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:172
msgid "Greek"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:174
msgid "el_CY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:174
msgid "Greek (Cyprus)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:176
msgid "el_GR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:176
msgid "Greek (Greece)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:178
msgid "English"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:180
msgid "en_AG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:180
msgid "English (Antigua and Barbuda)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:182
msgid "en_AU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:182
msgid "English (Australia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:184
msgid "en_BW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:184
msgid "English (Botswana)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:186
msgid "en_CA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:186
msgid "English (Canada)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:188
msgid "en_DK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:188
msgid "English (Denmark)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:190
msgid "en_GB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:190
msgid "English (United Kingdom)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:192
msgid "en_HK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:192
msgid "English (Hong Kong)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:194
msgid "en_IE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:194
msgid "English (Ireland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:196
msgid "en_IL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:196
msgid "English (Israel)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:198
msgid "en_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:198
msgid "English (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:200
msgid "en_NG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:200
msgid "English (Nigeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:202
msgid "en_MT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:202
msgid "English (Malta)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:204
msgid "en_NZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:204
msgid "English (New Zealand)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:206
msgid "en_PH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:206
msgid "English (Philippines)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:208
msgid "en_SG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:208
msgid "English (Singapore)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:210
msgid "en_US"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:210
msgid "English (United States)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:212
msgid "en_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:212
msgid "English (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:214
msgid "en_ZM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:214
msgid "English (Zambia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:216
msgid "en_ZW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:216
msgid "English (Zimbabwe)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:218
msgid "eo"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:218
msgid "Esperanto"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:220
msgid "Spanish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:222
msgid "es_AR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:222
msgid "Spanish (Argentina)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:224
msgid "es_BO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:224
msgid "Spanish (Bolivia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:226
msgid "es_CL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:226
msgid "Spanish (Chile)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:228
msgid "es_CO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:228
msgid "Spanish (Colombia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:230
msgid "es_CR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:230
msgid "Spanish (Costa Rica)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:232
msgid "en_CU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:232
msgid "Spanish (Cuba)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:234
msgid "es_DO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:234
msgid "Spanish (Dominican Republic)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:236
msgid "es_EC"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:236
msgid "Spanish (Ecuador)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:238
msgid "es_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:238
msgid "Spanish (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:240
msgid "es_GT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:240
msgid "Spanish (Guatemala)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:242
msgid "es_HN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:242
msgid "Spanish (Honduras)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:244
msgid "es_MX"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:244
msgid "Spanish (Mexico)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:246
msgid "es_NI"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:246
msgid "Spanish (Nicaragua)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:248
msgid "es_PA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:248
msgid "Spanish (Panama)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:250
msgid "es_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:250
msgid "Spanish (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:252
msgid "es_PR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:252
msgid "Spanish (Puerto Rico)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:254
msgid "es_PY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:254
msgid "Spanish (Paraguay)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:256
msgid "es_SV"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:256
msgid "Spanish (El Salvador)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:258
msgid "es_US"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:258
msgid "Spanish (United States)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:260
msgid "es_UY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:260
msgid "Spanish (Uruguay)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:262
msgid "es_VE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:262
msgid "Spanish (Venezuela)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:264
msgid "et"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:264
msgid "Estonian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:266
msgid "et_EE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:266
msgid "Estonian (Estonia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:268
msgid "eu"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:268
msgid "Basque"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:270
msgid "eu_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:270
msgid "Basque (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:272
msgid "fa"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:272
msgid "Persian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:274
msgid "fa_IR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:274
msgid "Persian (Iran)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:276
msgid "ff_SN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:276
msgid "Fulah (Senegal)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:278
msgid "fi"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:278
msgid "Finnish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:280
msgid "fi_FI"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:280
msgid "Finnish (Finland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:282
msgid "fil_PH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:282
msgid "Filipino (Philippines)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:284
msgid "fo_FO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:284
msgid "Faroese (Faroe Islands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:286
msgid "fr"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:286
msgid "French"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:288
msgid "fr_BE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:288
msgid "French (Belgium)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:290
msgid "fr_CA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:290
msgid "French (Canada)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:292
msgid "fr_CH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:292
msgid "French (Switzerland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:294
msgid "fr_FR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:294
msgid "French (France)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:296
msgid "fr_LU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:296
msgid "French (Luxembourg)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:298
msgid "fur_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:298
msgid "Friulian (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:300
msgid "fy_DE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:300
msgid "Western Frisian (Germany)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:302
msgid "fy_NL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:302
msgid "Western Frisian (Netherlands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:304
msgid "ga"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:304
msgid "Irish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:306
msgid "ga_IE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:306
msgid "Irish (Ireland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:308
msgid "gd_GB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:308
msgid "Scottish Gaelic (United Kingdom)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:310
msgid "gez_ER"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:310
msgid "Geez (Eritrea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:312
msgid "gez_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:312
msgid "Geez (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:314
msgid "gl_ES"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:314
msgid "Galician (Spain)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:316
msgid "gu_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:316
msgid "Gujarati (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:318
msgid "gv_GB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:318
msgid "Manx (United Kingdom)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:320
msgid "hak_TW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:320
msgid "Hakka Chinese (Taiwan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:322
msgid "ha_NG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:322
msgid "Hausa (Nigeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:324
msgid "he"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:324
msgid "Hebrew"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:326
msgid "he_IL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:326
msgid "Hebrew (Israel)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:328
msgid "hi"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:328
msgid "Hindi"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:330
msgid "hi_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:330
msgid "Hindi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:332
msgid "hne_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:332
msgid "Chhattisgarhi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:334
msgid "hr"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:334
msgid "Croatian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:336
msgid "hr_HR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:336
msgid "Croatian (Croatia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:338
msgid "hsb_DE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:338
msgid "Upper Sorbian (Germany)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:340
msgid "ht_HT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:340
msgid "Haitian (Haiti)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:342
msgid "hu"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:342
msgid "Hungarian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:344
msgid "hu_HU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:344
msgid "Hungarian (Hungary)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:346
msgid "hus_MX"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:346
msgid "Huastec (Mexico)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:348
msgid "hy_AM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:348
msgid "Armenian (Armenia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:350
msgid "ia_FR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:350
msgid "Interlingua (France)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:352
msgid "id"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:352
msgid "Indonesian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:354
msgid "id_ID"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:354
msgid "Indonesian (Indonesia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:356
msgid "ig_NG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:356
msgid "Igbo (Nigeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:358
msgid "ik_CA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:358
msgid "Inupiaq (Canada)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:360
msgid "Icelandic"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:362
msgid "is_IS"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:362
msgid "Icelandic (Iceland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:364
msgid "it"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:364
msgid "Italian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:366
msgid "it_CH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:366
msgid "Italian (Switzerland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:368
msgid "it_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:368
msgid "Italian (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:370
msgid "iu_CA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:370
msgid "Inuktitut (Canada)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:372
msgid "Japanese"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:374
msgid "ja_JP"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:374
msgid "Japanese (Japan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:376
msgid "kab_DZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:376
msgid "Kabyle (Algeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:378
msgid "ka_GE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:378
msgid "Georgian (Georgia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:380
msgid "kk_KZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:380
msgid "Kazakh (Kazakhstan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:382
msgid "kl_GL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:382
msgid "Kalaallisut (Greenland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:384
msgid "km_KH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:384
msgid "Central Khmer (Cambodia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:386
msgid "kn_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:386
msgid "Kannada (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:388
msgid "kok_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:388
msgid "Konkani (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:390
msgid "ko"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:390
msgid "Korean"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:392
msgid "ko_KR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:392
msgid "Korean (South Korea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:394
msgid "ks_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:394
msgid "Kashmiri (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:396
msgid "ku"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:396
msgid "Kurdish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:398
msgid "ku_TR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:398
msgid "Kurdish (Turkey)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:400
msgid "kw_GB"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:400
msgid "Cornish (United Kingdom)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:402
msgid "ky_KG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:402
msgid "Kirghiz (Kyrgyzstan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:404
msgid "lb_LU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:404
msgid "Luxembourgish (Luxembourg)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:406
msgid "lg_UG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:406
msgid "Ganda (Uganda)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:408
msgid "li_BE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:408
msgid "Limburgan (Belgium)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:410
msgid "li_NL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:410
msgid "Limburgan (Netherlands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:412
msgid "lij_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:412
msgid "Ligurian (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:414
msgid "ln_CD"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:414
msgid "Lingala (Congo)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:416
msgid "lo_LA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:416
msgid "Lao (Laos)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:418
msgid "lt"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:418
msgid "Lithuanian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:420
msgid "lt_LT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:420
msgid "Lithuanian (Lithuania)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:422
msgid "lv"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:422
msgid "Latvian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:424
msgid "lv_LV"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:424
msgid "Latvian (Latvia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:426
msgid "lzh_TW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:426
msgid "Literary Chinese (Taiwan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:428
msgid "mag_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:428
msgid "Magahi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:430
msgid "mai_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:430
msgid "Maithili (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:432
msgid "mg_MG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:432
msgid "Malagasy (Madagascar)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:434
msgid "mh_MH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:434
msgid "Marshallese (Marshall Islands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:436
msgid "mhr_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:436
msgid "Eastern Mari (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:438
msgid "mi_NZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:438
msgid "Maori (New Zealand)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:440
msgid "miq_NI"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:440
msgid "Mískito  (Nicaragua)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:442
msgid "mk"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:442
msgid "Macedonian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:444
msgid "mk_MK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:444
msgid "Macedonian (Macedonia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:446
msgid "ml_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:446
msgid "Malayalam (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:448
msgid "mni_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:448
msgid "Manipuri (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:450
msgid "mn_MN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:450
msgid "Mongolian (Mongolia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:452
msgid "mr_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:452
msgid "Marathi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:454
msgid "ms"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:454
msgid "Malay"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:456
msgid "ms_MY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:456
msgid "Malay (Malaysia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:458
msgid "mt"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:458
msgid "Maltese"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:460
msgid "mt_MT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:460
msgid "Maltese (Malta)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:462
msgid "my_MM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:462
msgid "Burmese (Myanmar)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:464
msgid "myv_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:464
msgid "Erzya  (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:466
msgid "nah_MX"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:466
msgid "Nahuatl languages (Mexico)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:468
msgid "nan_TW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:468
msgid "Min Nan Chinese (Taiwan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:470
msgid "nb"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:470
msgid "Norwegian Bokmål"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:472
msgid "nb_NO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:472
msgid "Norwegian Bokmål (Norway)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:474
msgid "nds_DE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:474
msgid "Low German (Germany)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:476
msgid "nds_NL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:476
msgid "Low German (Netherlands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:478
msgid "ne_NP"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:478
msgid "Nepali (Nepal)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:480
msgid "nhn_MX"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:480
msgid "Central Nahuatl (Mexico)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:482
msgid "niu_NU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:482
msgid "Niuean (Niue)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:484
msgid "niu_NZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:484
msgid "Niuean (New Zealand)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:486
msgid "nl"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:486
msgid "Dutch"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:488
msgid "nl_AW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:488
msgid "Dutch (Aruba)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:490
msgid "nl_BE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:490
msgid "Dutch (Belgium)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:492
msgid "nl_NL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:492
msgid "Dutch (Netherlands)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:494
msgid "nn"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:494
msgid "Norwegian Nynorsk"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:496
msgid "nn_NO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:496
msgid "Norwegian Nynorsk (Norway)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:498
msgid "no"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:498
msgid "Norwegian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:500
msgid "no_NO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:500
msgid "Norwegian (Norway)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:502
msgid "nr_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:502
msgid "South Ndebele (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:504
msgid "nso_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:504
msgid "Pedi (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:506
msgid "oc_FR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:506
msgid "Occitan (France)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:508
msgid "om"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:508
msgid "Oromo"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:510
msgid "om_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:510
msgid "Oromo (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:512
msgid "om_KE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:512
msgid "Oromo (Kenya)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:514
msgid "or_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:514
msgid "Oriya (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:516
msgid "os_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:516
msgid "Ossetian (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:518
msgid "pa_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:518
msgid "Panjabi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:520
msgid "pap"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:520
msgid "Papiamento"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:522
msgid "pap_AN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:522
msgid "Papiamento (Netherlands Antilles)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:524
msgid "pap_AW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:524
msgid "Papiamento (Aruba)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:526
msgid "pap_CW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:526
msgid "Papiamento (Curaçao)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:528
msgid "pa_PK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:528
msgid "Panjabi (Pakistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:530
msgid "pl"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:530
msgid "Polish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:532
msgid "pl_PL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:532
msgid "Polish (Poland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:534
msgid "pr"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:534
msgid "Pirate"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:536
msgid "ps_AF"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:536
msgid "Pushto (Afghanistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:538
msgid "pt"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:538
msgid "Portuguese"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:540
msgid "pt_BR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:540
msgid "Portuguese (Brazil)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:542
msgid "pt_PT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:542
msgid "Portuguese (Portugal)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:544
msgid "quy_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:544
msgid "Ayacucho Quechua (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:546
msgid "quz_PE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:546
msgid "Cusco Quechua (Peru)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:548
msgid "raj_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:548
msgid "Rajasthani (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:550
msgid "ro"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:550
msgid "Romanian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:552
msgid "ro_RO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:552
msgid "Romanian (Romania)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:554
msgid "ru"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:554
msgid "Russian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:556
msgid "ru_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:556
msgid "Russian (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:558
msgid "ru_UA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:558
msgid "Russian (Ukraine)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:560
msgid "rw_RW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:560
msgid "Kinyarwanda (Rwanda)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:562
msgid "sa_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:562
msgid "Sanskrit (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:564
msgid "sat_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:564
msgid "Santali (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:566
msgid "sc_IT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:566
msgid "Sardinian (Italy)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:568
msgid "sco"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:568
msgid "Scots"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:570
msgid "sd_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:570
msgid "Sindhi (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:572
msgid "se_NO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:572
msgid "Northern Sami (Norway)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:574
msgid "sgs_LT"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:574
msgid "Samogitian (Lithuania)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:576
msgid "shs_CA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:576
msgid "Shuswap (Canada)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:578
msgid "sid_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:578
msgid "Sidamo (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:580
msgid "si_LK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:580
msgid "Sinhala (Sri Lanka)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:582
msgid "sk"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:582
msgid "Slovak"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:584
msgid "sk_SK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:584
msgid "Slovak (Slovakia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:586
msgid "sl"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:586
msgid "Slovenian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:588
msgid "so"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:588
msgid "Somali"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:590
msgid "so_DJ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:590
msgid "Somali (Djibouti)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:592
msgid "so_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:592
msgid "Somali (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:594
msgid "so_KE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:594
msgid "Somali (Kenya)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:596
msgid "so_SO"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:596
msgid "Somali (Somalia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:598
msgid "son_ML"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:598
msgid "Songhai languages (Mali)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:600
msgid "sq"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:600
msgid "Albanian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:602
msgid "sq_AL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:602
msgid "Albanian (Albania)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:604
msgid "sq_KV"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:604
msgid "Albanian (Kosovo)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:606
msgid "sq_MK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:606
msgid "Albanian (Macedonia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:608
msgid "sr"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:608
msgid "Serbian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:610
msgid "sr_BA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:610
msgid "Serbian (Bosnia and Herzegovina)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:612
msgid "sr_CS"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:612
msgid "Serbian (Serbia and Montenegro)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:614
msgid "sr_ME"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:614
msgid "Serbian (Montenegro)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:616
msgid "sr_RS"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:616
msgid "Serbian (Serbia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:618
msgid "ss_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:618
msgid "Swati (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:620
msgid "st_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:620
msgid "Southern Sotho (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:622
msgid "sv"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:622
msgid "Swedish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:624
msgid "sv_FI"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:624
msgid "Swedish (Finland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:626
msgid "sv_SE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:626
msgid "Swedish (Sweden)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:628
msgid "sw_KE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:628
msgid "Swahili (Kenya)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:630
msgid "sw_TZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:630
msgid "Swahili (Tanzania)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:632
msgid "szl_PL"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:632
msgid "Silesian (Poland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:634
msgid "ta"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:634
msgid "Tamil"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:636
msgid "ta_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:636
msgid "Tamil (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:638
msgid "ta_LK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:638
msgid "Tamil (Sri Lanka)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:640
msgid "tcy_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:640
msgid "Tulu (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:642
msgid "te_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:642
msgid "Telugu (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:644
msgid "tg_TJ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:644
msgid "Tajik (Tajikistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:646
msgid "the_NP"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:646
msgid "Chitwania Tharu (Nepal)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:648
msgid "th"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:648
msgid "Thai"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:650
msgid "th_TH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:650
msgid "Thai (Thailand)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:652
msgid "th_TH_TH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:652
msgid "Thai (Thailand, TH)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:654
msgid "ti"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:654
msgid "Tigrinya"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:656
msgid "ti_ER"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:656
msgid "Tigrinya (Eritrea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:658
msgid "ti_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:658
msgid "Tigrinya (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:660
msgid "tig_ER"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:660
msgid "Tigre (Eritrea)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:662
msgid "tk_TM"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:662
msgid "Turkmen (Turkmenistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:664
msgid "tl_PH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:664
msgid "Tagalog (Philippines)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:666
msgid "tn_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:666
msgid "Tswana (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:668
msgid "tr"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:668
msgid "Turkish"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:670
msgid "tr_CY"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:670
msgid "Turkish (Cyprus)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:672
msgid "tr_TR"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:672
msgid "Turkish (Turkey)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:674
msgid "ts_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:674
msgid "Tsonga (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:676
msgid "tt_RU"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:676
msgid "Tatar (Russia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:678
msgid "ug_CN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:678
msgid "Uighur (China)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:680
msgid "uk"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:680
msgid "Ukrainian"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:682
msgid "uk_UA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:682
msgid "Ukrainian (Ukraine)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:684
msgid "unm_US"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:684
msgid "Unami (United States)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:686
msgid "ur"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:686
msgid "Urdu"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:688
msgid "ur_IN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:688
msgid "Urdu (India)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:690
msgid "ur_PK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:690
msgid "Urdu (Pakistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:692
msgid "uz"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:692
msgid "Uzbek"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:694
msgid "uz_UZ"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:694
msgid "Uzbek (Uzbekistan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:696
msgid "ve_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:696
msgid "Venda (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:698
msgid "vi"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:698
msgid "Vietnamese"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:700
msgid "vi_VN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:700
msgid "Vietnamese (Vietnam)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:702
msgid "wa_BE"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:702
msgid "Walloon (Belgium)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:704
msgid "wae_CH"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:704
msgid "Walser (Switzerland)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:706
msgid "wal_ET"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:706
msgid "Wolaytta (Ethiopia)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:708
msgid "wo_SN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:708
msgid "Wolof (Senegal)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:710
msgid "xh_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:710
msgid "Xhosa (South Africa)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:712
msgid "yi_US"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:712
msgid "Yiddish (United States)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:714
msgid "yo_NG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:714
msgid "Yoruba (Nigeria)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:716
msgid "yue_HK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:716
msgid "Yue Chinese (Hong Kong)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:718
msgid "zh"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:718
msgid "Chinese"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:720
msgid "zh_CN"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:720
msgid "Chinese (China)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:722
msgid "zh_HK"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:722
msgid "Chinese (Hong Kong)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:724
msgid "zh_SG"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:724
msgid "Chinese (Singapore)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:726
msgid "zh_TW"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:726
msgid "Chinese (Taiwan)"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:728
msgid "zu_ZA"
msgstr ""

#: ../../docs/tutorials/i18n/locales.rst:728
msgid "Zulu (South Africa)"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:4
msgid "GUI skinning"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:7
msgid "Oh, beautiful GUI!"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:9
msgid ""
"This tutorial is about advanced skinning of a user interface. Most games "
"generally don't need this, as they end up just relying on :ref:`Label "
"<class_Label>`, :ref:`TextureRect <class_TextureRect>`, :ref:`TextureButton "
"<class_TextureButton>` and :ref:`TextureProgress <class_TextureProgress>`."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:15
msgid ""
"However, many types of games often need complex user interfaces, like MMOs, "
"traditional RPGs, Simulators, Strategy, etc. These kinds of interface are "
"also common in some games that include editors to create content, or "
"interfaces for network connectivity."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:20
msgid ""
"Godot's user interface uses these kinds of control with the default theme, "
"but they can be skinned to resemble pretty much any kind of user interface."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:25
msgid "Theme"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:27
msgid ""
"The GUI is skinned through the :ref:`Theme <class_Theme>` resource. Theme "
"contains all the information required to change the entire visual styling of "
"all controls. Theme options are named, so it's not obvious which name "
"changes what (especially from code), but several tools are provided. The "
"ultimate place to look at what each theme option is for each control, which "
"will always be more up to date than any documentation, is the file `scene/"
"resources/default_theme/default_theme.cpp <https://github.com/godotengine/"
"godot/blob/master/scene/resources/default_theme/default_theme.cpp>`__. The "
"rest of this document will explain the different tools used to customize the "
"theme."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:38
msgid ""
"A Theme can be applied to any control in the scene. As a result, all "
"children and grand-children controls will use that same theme, too (unless "
"another theme is specified further down the tree). If a value is not found "
"in a theme, it will be searched in themes higher up in the hierarchy, "
"towards the root. If nothing was found, the default theme is used. This "
"system allows for flexible overriding of themes in complex user interfaces."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:47
msgid "Theme options"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:49
msgid "Each kind of option in a theme can be:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:51
msgid ""
"**An integer constant**: A single numerical constant. Generally used to "
"define spacing between components or alignment."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:53
msgid ""
"**A Color**: A single color, with or without transparency. Colors are "
"usually applied to fonts and icons."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:55
msgid ""
"**A Texture**: A single image. Textures are not often used, but when they "
"are, they represent handles to pick or icons in a complex control (such as a "
"file dialog)."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:58
msgid ""
"**A Font**: Every control that uses text can be assigned the fonts used to "
"draw strings."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:60
msgid ""
"**A StyleBox**: Stylebox is a resource that defines how to draw a panel in "
"varying sizes (more information on them later)."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:63
msgid "Every option is associated with:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:65
msgid "A name (the name of the option)"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:66
msgid "A Control (the name of the control)"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:68
msgid "An example usage:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:87
msgid ""
"In the example above, a new theme is created. The \"font_color\" option is "
"changed and then applied to a label. As a result, the label (and all "
"children and grandchildren labels) will use that color."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:91
msgid ""
"It is possible to override those options without using the theme directly, "
"and only for a specific control, by using the override API in :ref:`Control."
"add_color_override() <class_Control_method_add_color_override>`:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:106
msgid ""
"In the inline help of Godot (in the script tab) you can check which theme "
"options are overridable, or check the :ref:`Control <class_Control>` class "
"reference."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:110
msgid "Customizing a control"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:112
msgid ""
"If only a few controls need to be skinned, it is often not necessary to "
"create a new theme. Controls offer their theme options as special kinds of "
"properties. If checked, overriding will take place:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:118
msgid ""
"As can be seen in the image above, theme options have little check boxes. If "
"checked, they can be used to override the value of the theme just for that "
"control."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:123
msgid "Creating a theme"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:125
msgid ""
"The simplest way to create a theme is to edit a theme resource. Create a "
"Theme from the resource menu; the editor will appear immediately. After "
"that, save it (for example, with the name mytheme.theme):"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:131
msgid ""
"This will create an empty theme that can later be loaded and assigned to "
"controls."
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:135
msgid "Example: theming a button"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:137
msgid ""
"Download these assets (:download:`skin_assets.zip <files/skin_assets.zip>`) "
"and add them to your project. Open the theme editor, click on \"Edit Theme\" "
"and select \"Add Class Items\":"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:143
msgid ""
"A menu will appear prompting the type of control to create. Select \"Button"
"\":"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:148
msgid ""
"Immediately, all button theme options will appear in the property editor, "
"where they can be edited:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:153
msgid ""
"From ``Styles``, open the \"Normal\" drop-down menu next to where it "
"probably says \"null\" and create a \"New StyleBoxTexture\", then edit it. A "
"texture stylebox basically contains a texture and the size of the margins "
"that will not stretch when the texture is stretched. This is called \"3x3\" "
"stretching:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:161
msgid ""
"Repeat the steps and add the other assets. There is no hover or disabled "
"image in the example files, so use the same stylebox as in normal. Set the "
"supplied font as the button font and change the font color to black. Soon, "
"your button will look different and retro:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:168
msgid ""
"Save this theme to the .theme file. Go to the 2D editor and create a few "
"buttons:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:173
msgid ""
"Now, go to the root node of the scene and locate the \"theme\" property, "
"replace it with the theme that was just created. It should look like this:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:178
msgid "Congratulations! You have created a reusable GUI Theme!"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:4
msgid "Custom GUI controls"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:7
msgid "So many controls..."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:9
msgid ""
"Yet there are never enough. Creating your own custom controls that act just "
"the way you want them to is an obsession of almost every GUI programmer. "
"Godot provides plenty of them, but they may not work exactly the way you "
"want. Before contacting the developers with a pull-request to support "
"diagonal scrollbars, at least it will be good to know how to create these "
"controls easily from script."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:19
msgid ""
"For drawing, it is recommended to check the :ref:`doc_custom_drawing_in_2d` "
"tutorial. The same applies. Some functions are worth mentioning due to their "
"usefulness when drawing, so they will be detailed next:"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:24
msgid "Checking control size"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:26
msgid ""
"Unlike 2D nodes, \"size\" is important with controls, as it helps to "
"organize them in proper layouts. For this, the :ref:`Control.rect_size "
"<class_Control_property_rect_size>` property is provided. Checking it during "
"``_draw()`` is vital to ensure everything is kept in-bounds."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:33
msgid "Checking focus"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:35
msgid ""
"Some controls (such as buttons or text editors) might provide input focus "
"for keyboard or joypad input. Examples of this are entering text or pressing "
"a button. This is controlled with the :ref:`Control.focus_mode "
"<class_Control_property_focus_mode>` property. When drawing, and if the "
"control supports input focus, it is always desired to show some sort of "
"indicator (highlight, box, etc.) to indicate that this is the currently "
"focused control. To check for this status, the :ref:`Control.has_focus() "
"<class_Control_method_has_focus>` method exists. Example"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:69
msgid "Sizing"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:71
msgid ""
"As mentioned before, size is important to controls. This allows them to lay "
"out properly, when set into grids, containers, or anchored. Controls, most "
"of the time, provide a *minimum size* to help properly lay them out. For "
"example, if controls are placed vertically on top of each other using a :ref:"
"`VBoxContainer <class_VBoxContainer>`, the minimum size will make sure your "
"custom control is not squished by the other controls in the container."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:79
msgid ""
"To provide this callback, just override :ref:`Control.get_minimum_size() "
"<class_Control_method_get_minimum_size>`, for example:"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:96
msgid "Alternatively, set it using a function:"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:112
#: ../../docs/tutorials/viewports/viewports.rst:38
msgid "Input"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:114
msgid ""
"Controls provide a few helpers to make managing input events much easier "
"than regular nodes."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:120
msgid ""
"There are a few tutorials about input before this one, but it's worth "
"mentioning that controls have a special input method that only works when:"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:124
msgid "The mouse pointer is over the control."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:125
msgid ""
"The button was pressed over this control (control always captures input "
"until button is released)"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:127
msgid ""
"Control provides keyboard/joypad focus via :ref:`Control.focus_mode "
"<class_Control_property_focus_mode>`."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:130
msgid ""
"This function is :ref:`Control._gui_input() "
"<class_Control_method__gui_input>`. Simply override it in your control. No "
"processing needs to be set."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:153
msgid ""
"For more information about events themselves, check the :ref:"
"`doc_inputevent` tutorial."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:159
msgid ""
"Controls also have many useful notifications for which no dedicated callback "
"exists, but which can be checked with the _notification callback:"
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:4
msgid "Size and anchors"
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:6
msgid ""
"If a game was always going to be run on the same device and at the same "
"resolution, positioning controls would be a simple matter of setting the "
"position and size of each one of them. Unfortunately, that is rarely the "
"case."
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:11
msgid ""
"Only TVs nowadays have a standard resolution and aspect ratio. Everything "
"else, from computer monitors to tablets, portable consoles and mobile phones "
"have different resolutions and aspect ratios."
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:15
msgid ""
"There are several ways to handle this, but for now, let's just imagine that "
"the screen resolution has changed and the controls need to be re-positioned. "
"Some will need to follow the bottom of the screen, others the top of the "
"screen, or maybe the right or left margins."
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:22
msgid ""
"This is done by editing the *margin* properties of controls. Each control "
"has four margins: left, right, bottom and top. By default, all of them "
"represent a distance in pixels relative to the top-left corner of the parent "
"control or (in case there is no parent control) the viewport."
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:29
msgid ""
"When horizontal (left, right) and/or vertical (top, bottom) anchors are "
"changed to 1, the margin values become relative to the bottom-right corner "
"of the parent control or viewport."
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:35
msgid ""
"Here, the control is set to expand its bottom-right corner with that of the "
"parent, so when re-sizing the parent, the control will always cover it, "
"leaving a 20 pixel margin:"
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:42
#, fuzzy
msgid "Centering a control"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/gui/size_and_anchors.rst:44
msgid ""
"To center a control in its parent, set its anchors to 0.5 and each margin to "
"half of its relevant dimension. For example, the code below shows how a "
"TextureRect can be centered in its parent:"
msgstr ""

#: ../../docs/tutorials/gui/size_and_anchors.rst:63
msgid ""
"Setting each anchor to 0.5 moves the reference point for the margins to the "
"center of its parent. From there, we set negative margins so that the "
"control gets its natural size."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:4
#: ../../docs/development/cpp/core_types.rst:138
msgid "Containers"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:6
msgid ""
":ref:`Anchors <doc_size_and_anchors>` are an efficient way to handle "
"different aspect ratios for basic multiple resolution handling in GUIs,"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:9
msgid "For more complex user interfaces, they can become difficult to use."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:11
msgid ""
"This is often the case of games, such as RPGs, online chats, tycoons or "
"simulations. Another common case where more advanced layout features may be "
"required is in-game tools (or simply just tools)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:14
msgid ""
"All these situations require a more capable OS-like user interface, with "
"advanced layout and formatting. For that, :ref:`Containers "
"<class_container>` are more useful."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:18
msgid "Container layout"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:20
msgid ""
"Containers provide a huge amount of layout power (as an example, the Godot "
"editor user interface is entirely done using them):"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:24
msgid ""
"When a :ref:`Container <class_Container>`-derived node is used, all "
"children :ref:`Control <class_Control>` nodes give up their own positioning "
"ability. This means the *Container* will control their positioning and any "
"attempt to manually alter these nodes will be either ignored or invalidated "
"the next time their parent is resized."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:28
msgid ""
"Likewise, when a *Container* derived node is resized, all its children will "
"be re-positioned according to it, with a behavior based on the type of "
"container used:"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:33
msgid "Example of *HBoxContainer* resizing children buttons."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:35
msgid ""
"The real strength of containers is that they can be nested (as nodes), "
"allowing the creation of very complex layouts that resize effortlessly."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:40
msgid ""
"When adding a node to a container, the way the container treats each child "
"depends mainly on their *size flags*. These flags can be found by inspecting "
"any control that is a child of a *Container*."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:45
msgid ""
"Size flags are independent for vertical and horizontal sizing and not all "
"containers make use of them (but most do):"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:47
msgid ""
"**Fill**: Ensures the control *fills* the designated area within the "
"container. No matter if a control *expands* or not (see below), it will only "
"*fill* the designated area when this is toggled on (it is by default)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:49
msgid ""
"**Expand**: Attempts to use as much space as possible in the parent "
"container (in each axis). Controls that don't expand will be pushed away by "
"those that do. Between expanding controls, the amount of space they take "
"from each other is determined by the *Ratio* (see below)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:52
msgid ""
"**Shrink Center** When expanding (and if not filling), try to remain at the "
"center of the expanded area (by default it remains at the left or top)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:54
msgid ""
"**Ratio** Simple ratio of how much expanded controls take up the available "
"space in relation to each other. A control with \"2\", will take up twice as "
"much available space as one with \"1\"."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:57
msgid ""
"Experimenting with these flags and different containers is recommended to "
"get a better grasp on how they work."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:60
msgid "Container types"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:62
msgid ""
"Godot provides several container types out of the box as they serve "
"different purposes:"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:65
msgid "Box Containers"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:67
msgid ""
"Arrange child controls vertically or horizontally (via :ref:`HBoxContainer "
"<class_HBoxContainer>` and :ref:`VBoxContainer <class_VBoxContainer>`). In "
"the opposite of the designated direction (as in, vertical for an horizontal "
"container), it just expands the children."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:73
msgid ""
"These containers make use of the *Ratio* property for children with the "
"*Expand* flag set."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:76
msgid "Grid Container"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:78
msgid ""
"Arranges child controls in a grid layout (via :ref:`GridContainer "
"<class_GridContainer>`, amount of columns must be specified). Uses both the "
"vertical and horizontal expand flags."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:84
msgid "Margin Container"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:86
msgid ""
"Child controls are expanded towards the bounds of this control (via :ref:"
"`MarginContainer <class_MarginContainer>`). Padding will be added on the "
"margins depending on the theme configuration."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:92
msgid ""
"Again, keep in mind that the margins are a *Theme* value, so they need to be "
"edited from the constants overrides section of each control:"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:98
msgid "Tab Container"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:100
msgid ""
"Allows you to place several child controls stacked on top of each other "
"(via :ref:`TabContainer <class_TabContainer>`), with only the *current* one "
"visible."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:105
msgid ""
"Changing the *current* one is done via tabs located at the top of the "
"container, via clicking:"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:109
msgid ""
"The titles are generated from the node names by default (although they can "
"be overridden via *TabContainer* API)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:111
msgid ""
"Settings such as tab placement and *StyleBox* can be modified in the "
"*TabContainer* theme overrides."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:114
msgid "Split Container"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:116
msgid ""
"Accepts only one or two children controls, then places them side to side "
"with a divisor (via :ref:`HSplitContainer <class_HSplitContainer>` and :ref:"
"`VSplitContainer <class_VSplitContainer>`). Respects both horizontal and "
"vertical flags, as well as *Ratio*."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:122
msgid ""
"The divisor can be dragged around to change the size relation between both "
"children:"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:128
msgid "PanelContainer"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:130
msgid ""
"Simple container that draws a *StyleBox*, then expands children to cover its "
"whole area (via :ref:`PanelContainer <class_PanelContainer>`, respecting the "
"*StyleBox* margins). It respects both the horizontal and vertical size flags."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:136
msgid ""
"This container is useful as top-level, or just to add custom backgrounds to "
"sections of a layout."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:139
msgid "ScrollContainer"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:141
msgid ""
"Accepts a single child node. If this node is bigger than the container, "
"scrollbars will be added to allow panning the node around (via :ref:"
"`ScrollContainer <class_ScrollContainer>`). Both vertical and horizontal "
"size flags are respected, and the behavior can be turned on or off per axis "
"in the properties."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:148
msgid ""
"Mouse wheel and touch drag (when touch is available) are also valid ways to "
"pan the child control around."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:152
msgid ""
"As in the example above, one of the most common ways to use this container "
"is together with a *VBoxContainer* as child."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:156
msgid "ViewportContainer"
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:158
msgid ""
"This is a special control that will only accept a single *Viewport* node as "
"child, and it will display it as if it was an image (via :ref:"
"`ViewportContainer <class_ViewportContainer>`)."
msgstr ""

#: ../../docs/tutorials/gui/gui_containers.rst:162
#, fuzzy
msgid "Creating custom Containers"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/gui/gui_containers.rst:164
msgid ""
"It is possible to easily create a custom container using script. Here is an "
"example of a simple container that fits children to its rect size:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:4
msgid "BBCode in RichTextLabel"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:9
msgid ""
"Label nodes are great for displaying basic text, but they have limits. If "
"you want to change the color of the text, or its alignment, that change "
"affects all of the text in the Label node. You can't have only one part of "
"the text be one color, or only one part of the text be centered. To get "
"around this limitation you would use a :ref:`class_RichTextLabel`."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:15
msgid ""
":ref:`class_RichTextLabel` allows the display of complex text markup in a "
"Control. It has a built-in API for generating the markup, but can also parse "
"a BBCode."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:18
msgid ""
"Note that the BBCode tags can also be used, to some extent, in the :ref:`XML "
"source of the class reference <doc_updating_the_class_reference>`."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:22
msgid "Using BBCode"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:24
msgid ""
"For uniformly formatted text you can write in the \"Text\" property, but if "
"you want to use BBCode markup you should use the \"Text\" property in the "
"\"Bb Code\" section instead (``bbcode_text``). Writing to this property will "
"trigger the parsing of your markup to format the text as requested. Before "
"this happens, you need to toggle the \"Enabled\" checkbox in the \"Bb Code\" "
"section (``bbcode_enabled``)."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:32
msgid ""
"For example, ``BBCode [color=blue]blue[/color]`` would render the word \"blue"
"\" with a blue color."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:37
msgid ""
"You'll notice that after writing in the BBCode \"Text\" property the regular "
"\"Text\" property now has the text without the BBCode. While the text "
"property will be updated by the BBCode property, you can't edit the text "
"property or you'll lose the BBCode markup. All changes to the text must be "
"done in the BBCode parameter."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:44
msgid ""
"For BBCode tags such as ``[b]`` (bold) or ``[i]`` (italics) to work you must "
"set up custom fonts for the RichTextLabel node first."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:48
#: ../../docs/development/cpp/inheritance_class_tree.rst:10
msgid "Reference"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Tag"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "**bold**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "``[b]{text}[/b]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "Makes {text} bold."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:55
msgid "**italics**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:55
msgid "``[i]{text}[/i]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:55
msgid "Makes {text} italics."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:57
msgid "**underline**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:57
msgid "``[u]{text}[/u]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:57
msgid "Makes {text} underline."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:59
msgid "**strikethrough**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:59
msgid "``[s]{text}[/s]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:59
msgid "Makes {text} strikethrough."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:61
msgid "**code**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:61
msgid "``[code]{text}[/code]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:61
msgid "Makes {text} monospace."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:63
msgid "**center**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:63
msgid "``[center]{text}[/center]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:63
msgid "Makes {text} centered."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:65
msgid "**right**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:65
msgid "``[right]{text}[/right]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:65
msgid "Makes {text} right-aligned."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:67
msgid "**fill**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:67
msgid "``[fill]{text}[/fill]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:67
msgid "Makes {text} fill width."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:69
msgid "**indent**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:69
msgid "``[indent]{text}[/indent]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:69
msgid "Increase indent level of {text}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:71
msgid "**url**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:71
msgid "``[url]{url}[/url]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:71
msgid "Show {url} as such."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:73
msgid "**url (ref)**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:73
msgid "``[url=<url>]{text}[/url]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:73
msgid "Makes {text} reference <url>."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:75
msgid "**image**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:75
msgid "``[img]{path}[/img]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:75
msgid "Insert image at resource {path}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:77
#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:79
msgid "**resized image**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:77
msgid "``[img=<width>]{path}[/img]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:77
msgid "Insert image at resource {path} using <width> (keeps ratio)."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:79
msgid "``[img=<width>x<height>]{path}[/img]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:79
msgid "Insert image at resource {path} using <width> & <height>."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:81
msgid "**font**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:81
msgid "``[font=<path>]{text}[/font]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:81
msgid "Use custom font at <path> for {text}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:83
msgid "**color**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:83
msgid "``[color=<code/name>]{text}[/color]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:83
msgid "Change {text} color; use name or # format, such as #ff00ff."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:85
msgid "**table**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:85
msgid "``[table=<number>]{cells}[/table]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:85
msgid "Creates a table with <number> of columns."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:87
msgid "**cell**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:87
msgid "``[cell]{text}[/cell]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:87
msgid "Adds cells with the {text} to the table."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:91
msgid "Built-in color names"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:93
msgid "List of valid color names for the [color=<name>] tag:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:95
msgid "aqua"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:96
msgid "black"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:97
msgid "blue"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:98
msgid "fuchsia"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:99
msgid "gray"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:100
msgid "green"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:101
msgid "lime"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:102
msgid "maroon"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:103
msgid "navy"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:104
msgid "purple"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:105
msgid "red"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:106
msgid "silver"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:107
msgid "teal"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:108
msgid "white"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:109
msgid "yellow"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:112
msgid "Hexadecimal color codes"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:114
msgid ""
"For opaque RGB colors, any valid 6-digit hexadecimal code is supported, e.g. "
"``[color=#ffffff]white[/color]``."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:116
msgid ""
"For transparent RGB colors, any 8-digit hexadecimal code can be used, e.g. "
"``[color=#88ffffff]translucent white[/color]``. In this case, note that the "
"alpha channel is the **first** component of the color code, not the last one."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:120
msgid "Image vertical offset"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:122
msgid "You use a custom font for your image in order to align it vertically."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:124
msgid "Create a ``BitmapFont`` resource"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:125
msgid ""
"Set this bitmap font with a positive value for the ``ascent`` property, "
"that's your height offset"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:126
msgid ""
"Set the BBCode tag this way: ``[font=<font-path>][img]{image-path}[/img][/"
"font]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:129
#, fuzzy
msgid "Animation effects"
msgstr "אנימציות"

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:131
msgid ""
"BBCode can also be used to create different text animation effects. Five "
"customizable effects are provided out of the box, and you can easily create "
"your own."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:135
msgid "Wave"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:139
msgid ""
"Wave makes the text go up and down. Its tag format is ``[wave amp=50 freq=2]"
"[/wave]``. ``amp`` controls how high and low the effect goes, and ``freq`` "
"controls how fast the text goes up and down."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:144
msgid "Tornado"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:148
msgid ""
"Tornao makes the text move around in a circle. Its tag format is ``[tornado "
"radius=5 freq=2][/tornado]``. ``radius`` is the radius of the circle that "
"controls the offset, ``freq`` is how fast the text moves in a circle."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:154
msgid "Shake"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:158
msgid ""
"Shake makes the text shake. Its tag format is ``[shake rate=5 level=10][/"
"shake]``. ``rate`` controls how fast the text shakes, ``level`` controls how "
"far the text is offset from the origin."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:163
msgid "Fade"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:167
msgid ""
"Fade creates a fade effect over the text that is not animated. Its tag "
"format is ``[fade start=4 length=14][/fade]``. ``start`` controls the "
"starting position of the falloff relative to where the fade command is "
"inserted, ``length`` controls over how many characters should the fade out "
"take place."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:174
msgid "Rainbow"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:178
msgid ""
"Rainbow gives the text a rainbow color that changes over time. Its tag "
"format is ``[rainbow freq=0.2 sat=10 val=20][/rainbow]``. ``freq`` is the "
"number of full rainbow cycles per second, ``sat`` is the saturation of the "
"rainbow, ``val`` is the value of the rainbow."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:184
msgid "Custom BBCode tags and text effects"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:186
msgid ""
"You can extend the :ref:`class_RichTextEffect` resource type to create your "
"own custom BBCode tags. You begin by extending the :ref:"
"`class_RichTextEffect` resource type. Add the ``tool`` prefix to your "
"GDScript file if you wish to have these custom effects run within the editor "
"itself. The RichTextLabel does not need to have a script attached, nor does "
"it need to be running in ``tool`` mode."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:192
msgid ""
"There is only one function that you need to extend: "
"``_process_custom_fx(char_fx)``. Optionally, you can also provide a custom "
"BBCode identifier simply by adding a member name ``bbcode``. The code will "
"check the ``bbcode`` property automatically or will use the name of the file "
"to determine what the BBCode tag should be."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:198
msgid "``_process_custom_fx``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:200
msgid ""
"This is where the logic of each effect takes place and is called once per "
"character during the draw phase of text rendering. This passes in a :ref:"
"`class_CharFXTransform` object, which holds a few variables to control how "
"the associated character is rendered:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:204
msgid ""
"``identity`` specifies which custom effect is being processed. You should "
"use that for code flow control."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:206
msgid ""
"``relative_index`` tells you how far into a given custom effect block you "
"are in as an index."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:208
msgid ""
"``absolute_index`` tells you how far into the entire text you are as an "
"index."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:209
msgid ""
"``elapsed_time`` is the total amount of time the text effect has been "
"running."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:210
msgid ""
"``visible`` will tell you whether the character is visible or not and will "
"also allow you to hide a given portion of text."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:212
msgid ""
"``offset`` is an offset position relative to where the given character "
"should render under normal circumstances."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:214
msgid "``color`` is the color of a given character."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:215
msgid ""
"Finally, ``env`` is a :ref:`class_Dictionary` of parameters assigned to a "
"given custom effect. You can use :ref:`get() <class_Dictionary_method_get>` "
"with an optional default value to retrieve each parameter, if specified by "
"the user. For example ``[custom_fx spread=0.5 color=#FFFF00]test[/"
"custom_fx]`` would have a float ``spread`` and Color ``color`` parameters in "
"its ` `env`` Dictionary. See below for more usage examples."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:221
msgid ""
"The last thing to note about this function is that it is necessary to return "
"a boolean ``true`` value to verify that the effect processed correctly. This "
"way, if there's a problem with rendering a given character, it will back out "
"of rendering custom effects entirely until the user fixes whatever error "
"cropped up in their custom effect logic."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:226
msgid "Here are some examples of custom effects:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:229
msgid "Ghost"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:251
msgid "Pulse"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:277
msgid "Matrix"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:311
msgid "This will add a few new BBCode commands, which can be used like so:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:9
msgid ""
"Think of a :ref:`Viewport <class_Viewport>` as a screen onto which the game "
"is projected. In order to see the game, we need to have a surface on which "
"to draw it; that surface is the Root :ref:`Viewport <class_Viewport>`."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:16
msgid ""
":ref:`Viewports <class_Viewport>` can also be added to the scene so that "
"there are multiple surfaces to draw on. When we are drawing to a :ref:"
"`Viewport <class_Viewport>` that is not the Root, we call it a render "
"target. We can access the contents of a render target by accessing its "
"corresponding :ref:`texture <class_ViewportTexture>`. By using a :ref:"
"`Viewport <class_Viewport>` as a render target, we can either render "
"multiple scenes simultaneously or we can render to a :ref:`texture "
"<class_ViewportTexture>` which is applied to an object in the scene, for "
"example a dynamic skybox."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:25
msgid ""
":ref:`Viewports <class_Viewport>` have a variety of use cases, including:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:27
msgid "Rendering 3D objects within a 2D game"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:28
msgid "Rendering 2D elements in a 3D game"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:29
msgid "Rendering dynamic textures"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:30
msgid "Generating procedural textures at runtime"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:31
msgid "Rendering multiple cameras in the same scene"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:33
msgid ""
"What all these use cases have in common is that you are given the ability to "
"draw objects to a texture as if it were another screen and can then choose "
"what to do with the resulting texture."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:40
msgid ""
":ref:`Viewports <class_Viewport>` are also responsible for delivering "
"properly adjusted and scaled input events to all their children nodes. "
"Typically, input is received by the nearest :ref:`Viewport <class_Viewport>` "
"in the tree, but you can set :ref:`Viewports <class_Viewport>` not to "
"receive input by checking 'Disable Input' to 'on'; this will allow the next "
"nearest :ref:`Viewport <class_Viewport>` in the tree to capture the input."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:48
msgid ""
"For more information on how Godot handles input, please read the :ref:`Input "
"Event Tutorial<doc_inputevent>`."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:51
msgid "Listener"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:53
msgid ""
"Godot supports 3D sound (in both 2D and 3D nodes); more on this can be found "
"in the :ref:`Audio Streams Tutorial<doc_audio_streams>`. For this type of "
"sound to be audible, the :ref:`Viewport <class_Viewport>` needs to be "
"enabled as a listener (for 2D or 3D). If you are using a custom :ref:"
"`Viewport <class_Viewport>` to display your :ref:`World <class_World>`, "
"don't forget to enable this!"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:60
msgid "Cameras (2D & 3D)"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:62
msgid ""
"When using a :ref:`Camera <class_Camera>` / :ref:`Camera2D "
"<class_Camera2D>`, cameras will always display on the closest parent :ref:"
"`Viewport <class_Viewport>` (going towards the root). For example, in the "
"following hierarchy:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:69
msgid ""
"CameraA will display on the Root :ref:`Viewport <class_Viewport>` and it "
"will draw MeshA. CameraB will be captured by the :ref:`Viewport "
"<class_Viewport>` Node along with MeshB. Even though MeshB is in the scene "
"hierarchy, it will still not be drawn to the Root :ref:`Viewport "
"<class_Viewport>`. Similarly MeshA will not be visible from the :ref:"
"`Viewport <class_Viewport>` node because :ref:`Viewport <class_Viewport>` "
"nodes only capture nodes below them in the hierarchy."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:75
msgid ""
"There can only be one active camera per :ref:`Viewport <class_Viewport>`, so "
"if there is more than one, make sure that the desired one has the \"current"
"\" property set, or make it the current camera by calling:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:83
msgid ""
"By default, cameras will render all objects in their world. In 3D, cameras "
"can use their :ref:`cull_mask <class_Camera_property_cull_mask>` property "
"combined with the :ref:`VisualInstance's <class_VisualInstance>` :ref:`layer "
"<class_VisualInstance_property_layers>` property to restrict which objects "
"are rendered."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:89
msgid "Scale & stretching"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:91
msgid ""
":ref:`Viewports <class_Viewport>` have a \"size\" property, which represents "
"the size of the :ref:`Viewport <class_Viewport>` in pixels. For :ref:"
"`Viewports <class_Viewport>` which are children of :ref:`ViewportContainers "
"<class_viewportcontainer>`, these values are overridden, but for all others, "
"this sets their resolution."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:95
msgid ""
"It is also possible to scale the 2D content and make the :ref:`Viewport "
"<class_Viewport>` resolution different from the one specified in size, by "
"calling:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:103
msgid ""
"The root :ref:`Viewport <class_Viewport>` uses this for the stretch options "
"in the project settings. For more information on scaling and stretching "
"visit the :ref:`Multiple Resolutions Tutorial <doc_multiple_resolutions>`"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:107
msgid "Worlds"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:109
msgid ""
"For 3D, a :ref:`Viewport <class_Viewport>` will contain a :ref:`World "
"<class_World>`. This is basically the universe that links physics and "
"rendering together. Spatial-based nodes will register using the :ref:`World "
"<class_World>` of the closest :ref:`Viewport <class_Viewport>`. By default, "
"newly created :ref:`Viewports <class_Viewport>` do not contain a :ref:`World "
"<class_World>` but use the same as their parent :ref:`Viewport "
"<class_Viewport>` (the root :ref:`Viewport <class_Viewport>` always contains "
"a :ref:`World <class_World>`, which is the one objects are rendered to by "
"default). A :ref:`World <class_World>` can be set in a :ref:`Viewport "
"<class_Viewport>` using the \"world\" property, and that will separate all "
"children nodes of that :ref:`Viewport <class_Viewport>` from interacting "
"with the parent :ref:`Viewport's <class_Viewport>` :ref:`World "
"<class_World>`. This is especially useful in scenarios where, for example, "
"you might want to show a separate character in 3D imposed over the game "
"(like in StarCraft)."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:121
msgid ""
"As a helper for situations where you want to create :ref:`Viewports "
"<class_Viewport>` that display single objects and don't want to create a :"
"ref:`World <class_World>`, :ref:`Viewport <class_Viewport>` has the option "
"to use its own :ref:`World <class_World>`. This is useful when you want to "
"instance 3D characters or objects in a 2D :ref:`World <class_World2D>`."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:126
msgid ""
"For 2D, each :ref:`Viewport <class_Viewport>` always contains its own :ref:"
"`World2D <class_World2D>`. This suffices in most cases, but in case sharing "
"them may be desired, it is possible to do so by setting the :ref:`Viewport's "
"<class_Viewport>` :ref:`World2D <class_World2D>` manually."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:130
msgid ""
"For an example of how this works, see the demo projects `3D in 2D <https://"
"github.com/godotengine/godot-demo-projects/tree/master/viewport/3d_in_2d>`_ "
"and `2D in 3D <https://github.com/godotengine/godot-demo-projects/tree/"
"master/viewport/2d_in_3d>`_ respectively."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:133
msgid "Capture"
msgstr "לכידה"

#: ../../docs/tutorials/viewports/viewports.rst:135
msgid ""
"It is possible to query a capture of the :ref:`Viewport <class_Viewport>` "
"contents. For the root :ref:`Viewport <class_Viewport>`, this is effectively "
"a screen capture. This is done with the following code:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:152
msgid ""
"But if you use this in ``_ready()`` or from the first frame of the :ref:"
"`Viewport's <class_Viewport>` initialization, you will get an empty texture "
"because there is nothing to get as texture. You can deal with it using (for "
"example):"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:163
msgid "Viewport Container"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:165
msgid ""
"If the :ref:`Viewport <class_Viewport>` is a child of a :ref:"
"`ViewportContainer <class_viewportcontainer>`, it will become active and "
"display anything it has inside. The layout looks like this:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:169
msgid ""
"The :ref:`Viewport <class_Viewport>` will cover the area of its parent :ref:"
"`ViewportContainer <class_viewportcontainer>` completely if :ref:"
"`Stretch<class_viewportcontainer_property_stretch>` is set to ``true`` in :"
"ref:`ViewportContainer <class_viewportcontainer>`. Note: The size of the :"
"ref:`ViewportContainer <class_viewportcontainer>` cannot be smaller than the "
"size of the :ref:`Viewport <class_Viewport>`."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:176
msgid ""
"Due to the fact that the :ref:`Viewport <class_Viewport>` is an entryway "
"into another rendering surface, it exposes a few rendering properties that "
"can be different from the project settings. The first is MSAA; you can "
"choose to use a different level of MSAA for each :ref:`Viewport "
"<class_Viewport>`; the default behavior is DISABLED. You can also set the :"
"ref:`Viewport <class_Viewport>` to use HDR, HDR is very useful for when you "
"want to store values in the texture that are outside the range 0.0 - 1.0."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:181
msgid ""
"If you know how the :ref:`Viewport <class_Viewport>` is going to be used, "
"you can set its Usage to either 3D or 2D. Godot will then restrict how the :"
"ref:`Viewport <class_Viewport>` is drawn to in accordance with your choice; "
"default is 3D. The 2D usage mode is slightly faster and uses less memory "
"compared to the 3D one. It's a good idea to set the :ref:`Viewport "
"<class_Viewport>`'s Usage property to 2D if your viewport doesn't render "
"anything in 3D."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:187
msgid ""
"If you need to render 3D shadows in the viewport, make sure to set the "
"viewport's *Shadow Atlas Size* property to a value higher than 0. Otherwise, "
"shadows won't be rendered. For reference, the Project Settings define it to "
"4096 by default."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:190
msgid ""
"Godot also provides a way of customizing how everything is drawn inside :ref:"
"`Viewports <class_Viewport>` using “Debug Draw”. Debug Draw allows you to "
"specify one of four options for how the :ref:`Viewport <class_Viewport>` "
"will display things drawn inside it. Debug Draw is disabled by default."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:196
msgid "*A scene drawn with Debug Draw disabled*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:198
msgid ""
"The other three options are Unshaded, Overdraw, and Wireframe. Unshaded "
"draws the scene without using lighting information so all the objects appear "
"flatly colored the color of their albedo."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:204
msgid "*The same scene with Debug Draw set to Unshaded*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:206
msgid ""
"Overdraw draws the meshes semi-transparent with an additive blend so you can "
"see how the meshes overlap."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:210
msgid "*The same scene with Debug Draw set to Overdraw*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:212
msgid ""
"Lastly, Wireframe draws the scene using only the edges of triangles in the "
"meshes."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:216
msgid ""
"The effects of the Wireframe mode are only visible in the editor, not while "
"the project is running."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:219
msgid "Render target"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:221
msgid ""
"When rendering to a :ref:`Viewport <class_Viewport>`, whatever is inside "
"will not be visible in the scene editor. To display the contents, you have "
"to draw the :ref:`Viewport's <class_Viewport>` :ref:`ViewportTexture "
"<class_ViewportTexture>` somewhere. This can be requested via code using "
"(for example):"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:231
msgid ""
"Or it can be assigned in the editor by selecting \"New ViewportTexture\""
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:235
msgid ""
"and then selecting the :ref:`Viewport <class_Viewport>` you want to use."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:239
msgid ""
"Every frame, the :ref:`Viewport <class_Viewport>`'s texture is cleared away "
"with the default clear color (or a transparent color if :ref:`Transparent "
"Bg<class_Viewport_property_transparent_bg>` is set to ``true``). This can be "
"changed by setting :ref:`Clear "
"Mode<class_Viewport_property_render_target_clear_mode>` to Never or Next "
"Frame. As the name implies, Never means the texture will never be cleared, "
"while next frame will clear the texture on the next frame and then set "
"itself to Never."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:244
msgid ""
"By default, re-rendering of the :ref:`Viewport <class_Viewport>` happens "
"when the :ref:`Viewport <class_Viewport>`'s :ref:`ViewportTexture "
"<class_ViewportTexture>` has been drawn in a frame. If visible, it will be "
"rendered; otherwise, it will not. This behavior can be changed to manual "
"rendering (once), or always render, no matter if visible or not. This "
"flexibility allows users to render an image once and then use the texture "
"without incurring the cost of rendering every frame."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:252
msgid ""
"Make sure to check the Viewport demos! Viewport folder in the demos archive "
"available to download, or https://github.com/godotengine/godot-demo-projects/"
"tree/master/viewport"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:4
msgid "Multiple resolutions"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:7
msgid "The problem of multiple resolutions"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:9
msgid ""
"Developers often have trouble understanding how to best support multiple "
"resolutions in their games. For desktop and console games, this is more or "
"less straightforward, as most screen aspect ratios are 16:9 and resolutions "
"are standard (720p, 1080p, 1440p, 4K, …)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:14
msgid ""
"For mobile games, at first, it was easy. For many years, the iPhone and iPad "
"used the same resolution. When *Retina* was implemented, they just doubled "
"the pixel density; most developers had to supply assets in default and "
"double resolutions."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:19
msgid ""
"Nowadays, this is no longer the case, as there are plenty of different "
"screen sizes, densities, and aspect ratios. Non-conventional sizes are also "
"becoming increasingly popular, such as ultrawide displays."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:23
msgid ""
"For 3D games, there is not much of a need to support multiple resolutions "
"(from the aesthetic point of view). The 3D geometry will just fill the "
"screen based on the field of view, disregarding the aspect ratio. The main "
"reason one may want to support this, in this case, is for *performance* "
"reasons (running in lower resolution to increase frames per second)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:29
msgid ""
"For 2D and game UIs, this is a different matter, as art needs to be created "
"using specific pixel sizes in software such as Photoshop, GIMP or Krita."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:32
msgid ""
"Since layouts, aspect ratios, resolutions, and pixel densities can change so "
"much, it is no longer possible to design UIs for every specific screen. "
"Another method must be used."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:37
msgid "One size fits all"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:39
msgid ""
"The most common approach is to use a single *base* resolution and then fit "
"it to everything else. This resolution is how most players are expected to "
"play the game (given their hardware). For mobile, Google has useful `stats "
"<https://developer.android.com/about/dashboards>`_ online, and for desktop, "
"Steam `also does <https://store.steampowered.com/hwsurvey/>`_."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:45
msgid ""
"As an example, Steam shows that the most common *primary display resolution* "
"is 1920×1080, so a sensible approach is to develop a game for this "
"resolution, then handle scaling for different sizes and aspect ratios."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:49
msgid "Godot provides several useful tools to do this easily."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:52
msgid "Base size"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:54
msgid ""
"A base size for the window can be specified in the Project Settings under "
"**Display → Window**."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:59
msgid ""
"However, what it does is not completely obvious; the engine will *not* "
"attempt to switch the monitor to this resolution. Rather, think of this "
"setting as the \"design size\", i.e. the size of the area that you work with "
"in the editor. This setting corresponds directly to the size of the blue "
"rectangle in the 2D editor."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:65
msgid ""
"There is often a need to support devices with screen and window sizes that "
"are different from this base size. Godot offers many ways to control how the "
"viewport will be resized and stretched to different screen sizes."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:71
msgid "Resizing"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:73
msgid ""
"There are several types of devices, with several types of screens, which in "
"turn have different pixel density and resolutions. Handling all of them can "
"be a lot of work, so Godot tries to make the developer's life a little "
"easier. The :ref:`Viewport <class_Viewport>` node has several functions to "
"handle resizing, and the root node of the scene tree is always a viewport "
"(scenes loaded are instanced as a child of it, and it can always be accessed "
"by calling ``get_tree().get_root()`` or ``get_node(\"/root\")``)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:82
msgid ""
"In any case, while changing the root Viewport params is probably the most "
"flexible way to deal with the problem, it can be a lot of work, code and "
"guessing, so Godot provides a simple set of parameters in the project "
"settings to handle multiple resolutions."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:88
msgid "Stretch settings"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:90
msgid ""
"Stretch settings are located in the project settings and provide several "
"options:"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:95
msgid "Stretch Mode"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:97
msgid ""
"The **Stretch Mode** setting defines how the base size is stretched to fit "
"the resolution of the window or screen."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:102
msgid ""
"The animations below use a \"base size\" of just 16×9 pixels to demonstrate "
"the effect of different stretch modes. A single sprite, also 16×9 pixels in "
"size, covers the entire viewport, and a diagonal :ref:`Line2D "
"<class_Line2D>` is added on top of it:"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:112
msgid ""
"**Stretch Mode = Disabled** (default): No stretching happens. One unit in "
"the scene corresponds to one pixel on the screen. In this mode, the "
"**Stretch Aspect** setting has no effect."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:116
msgid ""
"This is a good option if you want full control over every screen pixel, and "
"is probably the best option for 3D games."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:121
msgid ""
"**Stretch Mode = 2D**: In this mode, the size specified in display/width and "
"display/height in the project settings is stretched to cover the whole "
"screen (taking the **Stretch Aspect** setting into account). This means that "
"everything is rendered directly at the target resolution. 3D is largely "
"unaffected, while in 2D, there is no longer a 1:1 correspondence between "
"sprite pixels and screen pixels, which may result in scaling artifacts."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:129
msgid ""
"This is a good option if your 2D artwork has a sufficiently high resolution "
"and does not require pixel-perfect rendering. Consider enabling texture "
"filtering and mipmapping on your 2D textures and fonts."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:136
msgid ""
"**Stretch Mode = Viewport**: Viewport scaling means that the size of the "
"root :ref:`Viewport <class_Viewport>` is set precisely to the base size "
"specified in the Project Settings' **Display** section. The scene is "
"rendered to this viewport first. Finally, this viewport is scaled to fit the "
"screen (taking the **Stretch Aspect** setting into account)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:143
msgid ""
"This mode is useful when working with pixel-precise games, or for the sake "
"of rendering to a lower resolution to improve performance."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:149
msgid "Stretch Aspect"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:151
msgid ""
"The second setting is the stretch aspect. Note that this only takes effect "
"if **Stretch Mode** is set to something other than **Disabled**."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:154
msgid ""
"In the animations below, you will notice gray and black areas. The black "
"areas are added by the engine and cannot be drawn into. The gray areas are "
"part of your scene, and can be drawn to. The gray areas correspond to the "
"region outside the blue frame you see in the 2D editor."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:159
msgid ""
"**Stretch Aspect = Ignore**: Ignore the aspect ratio when stretching the "
"screen. This means that the original resolution will be stretched to exactly "
"fill the screen, even if it's wider or narrower. This may result in "
"nonuniform stretching: things looking wider or taller than designed."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:167
msgid ""
"**Stretch Aspect = Keep**: Keep aspect ratio when stretching the screen. "
"This means that the viewport retains its original size regardless of the "
"screen resolution, and black bars will be added to the top/bottom of the "
"screen (\"letterboxing\") or the sides (\"pillarboxing\")."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:173
msgid ""
"This is a good option if you know the aspect ratio of your target devices in "
"advance, or if you don't want to handle different aspect ratios."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:179
msgid ""
"**Stretch Aspect = Keep Width**: Keep aspect ratio when stretching the "
"screen. If the screen is wider than the base size, black bars are added at "
"the left and right (pillarboxing). But if the screen is taller than the base "
"resolution, the viewport will be grown in the vertical direction (and more "
"content will be visible to the bottom). You can also think of this as "
"\"Expand Vertically\"."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:186
msgid ""
"This is usually the best option for creating GUIs or HUDs that scale, so "
"some controls can be anchored to the bottom (:ref:`doc_size_and_anchors`)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:192
msgid ""
"**Stretch Aspect = Keep Height**: Keep aspect ratio when stretching the "
"screen. If the screen is taller than the base size, black bars are added at "
"the top and bottom (letterboxing). But if the screen is wider than the base "
"resolution, the viewport will be grown in the horizontal direction (and more "
"content will be visible to the right). You can also think of this as "
"\"Expand Horizontally\"."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:199
msgid ""
"This is usually the best option for 2D games that scroll horizontally (like "
"runners or platformers)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:204
msgid ""
"**Stretch Aspect = Expand**: Keep aspect ratio when stretching the screen, "
"but keep neither the base width nor height. Depending on the screen aspect "
"ratio, the viewport will either be larger in the horizontal direction (if "
"the screen is wider than the base size) or in the vertical direction (if the "
"screen is taller than the original size)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:214
msgid "Stretch Shrink"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:216
msgid ""
"The **Shrink** setting allows you to add an extra scaling factor on top of "
"what the **Stretch** options above already provide. The default value of 1 "
"means that no scaling occurs."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:220
msgid ""
"If, for example, you set **Shrink** to 4 and leave **Stretch Mode** on "
"**Disabled**, each unit in your scene will correspond to 4×4 pixels on the "
"screen."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:224
msgid ""
"If **Stretch Mode** is set to something other than **Disabled**, the size of "
"the root viewport is scaled down by the **Shrink** factor, and pixels in the "
"output are scaled up by the same amount. This is rarely useful for 2D games, "
"but can be used to increase performance in 3D games by rendering them at a "
"lower resolution."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:231
msgid "From scripts"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:233
msgid ""
"To configure stretching at runtime from a script, use the ``get_tree()."
"set_screen_stretch()`` function (see :ref:`SceneTree.set_screen_stretch() "
"<class_SceneTree_method_set_screen_stretch>`)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:238
msgid "Reducing aliasing on downsampling"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:240
msgid ""
"If the game has a very high base resolution (e.g. 3840×2160), aliasing might "
"appear when downsampling to something considerably lower like 1280×720. "
"Aliasing can be made less visible by shrinking all images by a factor of 2 "
"upon loading. This can be done by calling the method below before the game "
"data is loaded:"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:252
msgid "Handling aspect ratios"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:254
msgid ""
"Once scaling for different resolutions is accounted for, make sure that your "
"*user interface* also scales for different aspect ratios. This can be done "
"using :ref:`anchors <doc_size_and_anchors>` and/or :ref:`containers "
"<doc_gui_containers>`."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:260
msgid "Field of view scaling"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:262
msgid ""
"The 3D Camera node's **Keep Aspect** property defaults to the **Keep "
"Height** scaling mode (also called *Hor+*). This is usually the best value "
"for desktop games and mobile games in landscape mode, as widescreen displays "
"will automatically use a wider field of view."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:267
msgid ""
"However, if your 3D game is intended to be played in portrait mode, it may "
"make more sense to use **Keep Width** instead (also called *Vert-*). This "
"way, smartphones with an aspect ratio taller than 16:9 (e.g. 19:9) will use "
"a *taller* field of view, which is more logical here."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:4
msgid "Using a Viewport as a texture"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:9
msgid ""
"This tutorial will introduce you to using the :ref:`Viewport "
"<class_Viewport>` as a texture that can be applied to 3D objects. In order "
"to do so, it will walk you through the process of making a procedural planet "
"like the one below:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:15
msgid ""
"This tutorial does not cover how to code a dynamic atmosphere like the one "
"this planet has."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:17
msgid ""
"This tutorial assumes you are familiar with how to set up a basic scene "
"including: a :ref:`Camera <class_Camera>`, a :ref:`light source "
"<class_OmniLight>`, a :ref:`Mesh Instance <class_MeshInstance>` with a :ref:"
"`Primitive Mesh <class_PrimitiveMesh>`, and applying a :ref:`SpatialMaterial "
"<class_SpatialMaterial>` to the mesh. The focus will be on using the :ref:"
"`Viewport <class_Viewport>` to dynamically create textures that can be "
"applied to the mesh."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:23
msgid "In this tutorial, we'll cover the following topics:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:25
msgid "How to use a :ref:`Viewport <class_Viewport>` as a render texture"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:26
msgid "Mapping a texture to a sphere with equirectangular mapping"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:27
msgid "Fragment shader techniques for procedural planets"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:28
msgid ""
"Setting a Roughness map from a :ref:`Viewport Texture "
"<class_ViewportTexture>`"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:31
msgid "Setting up the Viewport"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:33
msgid "First, add a :ref:`Viewport <class_Viewport>` to the scene."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:35
msgid ""
"Next, set the size of the :ref:`Viewport <class_Viewport>` to ``(1024, "
"512)``. The :ref:`Viewport <class_Viewport>` can actually be any size so "
"long as the width is double the height. The width needs to be double the "
"height so that the image will accurately map onto the sphere, as we will be "
"using equirectangular projection, but more on that later."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:42
msgid ""
"Next, disable HDR and disable 3D. We don't need HDR because our planet's "
"surface will not be especially bright, so values between ``0`` and ``1`` "
"will be fine. And we will be using a :ref:`ColorRect <class_ColorRect>` to "
"render the surface, so we don't need 3D either."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:46
msgid ""
"Select the Viewport and add a :ref:`ColorRect <class_ColorRect>` as a child."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:48
msgid ""
"Set the anchors \"Right\" and \"Bottom\" to ``1``, then make sure all the "
"margins are set to ``0``. This will ensure that the :ref:`ColorRect "
"<class_ColorRect>` takes up the entire :ref:`Viewport <class_Viewport>`."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:53
msgid ""
"Next, we add a :ref:`Shader Material <class_ShaderMaterial>` to the :ref:"
"`ColorRect <class_ColorRect>` (ColorRect > CanvasItem > Material > Material "
"> ``New ShaderMaterial``)."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:55
msgid ""
"Basic familiarity with shading is recommended for this tutorial. However, "
"even if you are new to shaders, all the code will be provided, so you should "
"have no problem following along."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:58
msgid ""
"ColorRect > CanvasItem > Material > Material > click / Edit > ShaderMaterial "
"> Shader > ``New Shader`` > click / Edit:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:68
msgid "The above code renders a gradient like the one below."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:72
msgid ""
"Now we have the basics of a :ref:`Viewport <class_Viewport>` that we render "
"to and we have a unique image that we can apply to the sphere."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:76
msgid "Applying the texture"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:78
msgid ""
"MeshInstance > GeometryInstance > Geometry > Material Override > ``New "
"SpatialMaterial``:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:80
msgid ""
"Now we go into the :ref:`Mesh Instance <class_MeshInstance>` and add a :ref:"
"`SpatialMaterial <class_SpatialMaterial>` to it. No need for a special :ref:"
"`Shader Material <class_ShaderMaterial>` (although that would be a good idea "
"for more advanced effects, like the atmosphere in the example above)."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:84
msgid ""
"MeshInstance > GeometryInstance > Geometry > Material Override > ``click`` / "
"``Edit``:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:86
msgid ""
"Open the newly created :ref:`SpatialMaterial <class_SpatialMaterial>` and "
"scroll down to the \"Albedo\" section and click beside the \"Texture\" "
"property to add an Albedo Texture. Here we will apply the texture we made. "
"Choose \"New ViewportTexture\""
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:92
msgid ""
"Then, from the menu that pops up, select the Viewport that we rendered to "
"earlier."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:96
msgid ""
"Your sphere should now be colored in with the colors we rendered to the "
"Viewport."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:100
msgid ""
"Notice the ugly seam that forms where the texture wraps around? This is "
"because we are picking a color based on UV coordinates and UV coordinates do "
"not wrap around the texture. This is a classic problem in 2D map projection. "
"Game developers often have a 2-dimensional map they want to project onto a "
"sphere, but when it wraps around, it has large seams. There is an elegant "
"workaround for this problem that we will illustrate in the next section."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:107
msgid "Making the planet texture"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:109
msgid ""
"So now, when we render to our :ref:`Viewport <class_Viewport>`, it appears "
"magically on the sphere. But there is an ugly seam created by our texture "
"coordinates. So how do we get a range of coordinates that wrap around the "
"sphere in a nice way? One solution is to use a function that repeats on the "
"domain of our texture. ``sin`` and ``cos`` are two such functions. Let's "
"apply them to the texture and see what happens."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:120
msgid ""
"Not too bad. If you look around, you can see that the seam has now "
"disappeared, but in its place, we have pinching at the poles. This pinching "
"is due to the way Godot maps textures to spheres in its :ref:"
"`SpatialMaterial <class_SpatialMaterial>`. It uses a projection technique "
"called equirectangular projection, which translates a spherical map onto a "
"2D plane."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:125
msgid ""
"If you are interested in a little extra information on the technique, we "
"will be converting from spherical coordinates into Cartesian coordinates. "
"Spherical coordinates map the longitude and latitude of the sphere, while "
"Cartesian coordinates are, for all intents and purposes, a vector from the "
"center of the sphere to the point."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:130
msgid ""
"For each pixel, we will calculate its 3D position on the sphere. From that, "
"we will use 3D noise to determine a color value. By calculating the noise in "
"3D, we solve the problem of the pinching at the poles. To understand why, "
"picture the noise being calculated across the surface of the sphere instead "
"of across the 2D plane. When you calculate across the surface of the sphere, "
"you never hit an edge, and hence you never create a seam or a pinch point on "
"the pole. The following code converts the ``UVs`` into Cartesian coordinates."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:149
msgid "And if we use ``unit`` as an output ``COLOR`` value, we get:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:153
msgid ""
"Now that we can calculate the 3D position of the surface of the sphere, we "
"can use 3D noise to make the planet. We will be using this noise function "
"directly from a `Shadertoy <https://www.shadertoy.com/view/Xsl3Dl>`_:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:181
msgid ""
"All credit goes to the author, Inigo Quilez. It is published under the "
"``MIT`` licence."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:183
msgid ""
"Now to use ``noise``, add the following to the    ``fragment`` function:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:192
msgid "In order to highlight the texture, we set the material to unshaded."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:194
msgid ""
"You can see now that the noise indeed wraps seamlessly around the sphere. "
"Although this looks nothing like the planet you were promised. So let's move "
"onto something more colorful."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:198
msgid "Coloring the planet"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:200
msgid ""
"Now to make the planet colors. While there are many ways to do this, for "
"now, we will stick with a gradient between water and land."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:203
msgid ""
"To make a gradient in GLSL, we use the ``mix`` function. ``mix`` takes two "
"values to interpolate between and a third argument to choose how much to "
"interpolate between them; in essence, it *mixes* the two values together. In "
"other APIs, this function is often called ``lerp``. However, ``lerp`` is "
"typically reserved for mixing two floats together; ``mix`` can take any "
"values whether it be floats or vector types."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:213
msgid ""
"The first color is blue for the ocean. The second color is a kind of reddish "
"color (because all alien planets need red terrain). And finally, they are "
"mixed together by ``n * 0.5 + 0.5``. ``n`` smoothly varies between ``-1`` "
"and ``1``. So we map it into the ``0-1`` range that ``mix`` expects. Now you "
"can see that the colors change between blue and red."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:220
msgid ""
"That is a little more blurry than we want. Planets typically have a "
"relatively clear separation between land and sea. In order to do that, we "
"will change the last term to ``smoothstep(-0.1, 0.0, n)``. And thus the "
"whole line becomes:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:228
msgid ""
"What ``smoothstep`` does is return ``0`` if the third argument is below the "
"first and ``1`` if the third argument is larger than the second and smoothly "
"blends between ``0`` and ``1`` if the third number is between the first and "
"the second. So in this line, ``smoothstep`` returns ``0`` whenever ``n`` is "
"less than ``-0.1`` and it returns ``1`` whenever ``n`` is above ``0``."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:235
msgid ""
"One more thing to make this a little more planet-y. The land shouldn't be so "
"blobby; let's make the edges a little rougher. A trick that is often used in "
"shaders to make rough looking terrain with noise is to layer levels of noise "
"over one another at various frequencies. We use one layer to make the "
"overall blobby structure of the continents. Then another layer breaks up the "
"edges a bit, and then another, and so on. What we will do is calculate ``n`` "
"with four lines of shader code instead of just one. ``n`` becomes:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:249
msgid "And now the planet looks like:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:253
msgid "And with shading turned back on, it looks like:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:258
msgid "Making an ocean"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:260
msgid ""
"One final thing to make this look more like a planet. The ocean and the land "
"reflect light differently. So we want the ocean to shine a little more than "
"the land. We can do this by passing a fourth value into the ``alpha`` "
"channel of our output ``COLOR`` and using it as a Roughness map."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:268
msgid ""
"This line returns ``0.3`` for water and ``1.0`` for land. This means that "
"the land is going to be quite rough, while the water will be quite smooth."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:271
msgid ""
"And then, in the material, under the \"Metallic\" section, make sure "
"``Metallic`` is set to ``0`` and ``Specular`` is set to ``1``. The reason "
"for this is the water reflects light really well, but isn't metallic. These "
"values are not physically accurate, but they are good enough for this demo."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:275
msgid ""
"Next, under the \"Roughness\" section, set ``Roughness`` to ``1`` and set "
"the roughness texture to a :ref:`Viewport Texture <class_ViewportTexture>` "
"pointing to our planet texture :ref:`Viewport <class_Viewport>`. Finally, "
"set the ``Texture Channel`` to ``Alpha``. This instructs the renderer to use "
"the ``alpha`` channel of our output ``COLOR`` as the ``Roughness`` value."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:282
msgid ""
"You'll notice that very little changes except that the planet is no longer "
"reflecting the sky. This is happening because, by default, when something is "
"rendered with an alpha value, it gets drawn as a transparent object over the "
"background. And since the default background of the :ref:`Viewport "
"<class_Viewport>` is opaque, the ``alpha`` channel of the :ref:`Viewport "
"Texture <class_ViewportTexture>` is ``1``, resulting in the planet texture "
"being drawn with slightly fainter colors and a ``Roughness`` value of ``1`` "
"everywhere. To correct this, we go into the :ref:`Viewport <class_Viewport>` "
"and enable the \"Transparent Bg\" property. Since we are now rendering one "
"transparent object on top of another, we want to enable "
"``blend_premul_alpha``:"
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:295
msgid ""
"This pre-multiplies the colors by the ``alpha`` value and then blends them "
"correctly together. Typically, when blending one transparent color on top of "
"another, even if the background has an ``alpha`` of ``0`` (as it does in "
"this case), you end up with weird color bleed issues. Setting "
"``blend_premul_alpha`` fixes that."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:299
msgid ""
"Now the planet should look like it is reflecting light on the ocean but not "
"the land. If you haven't done so already, add an :ref:`OmniLight "
"<class_OmniLight>` to the scene so you can move it around and see the effect "
"of the reflections on the ocean."
msgstr ""

#: ../../docs/tutorials/viewports/using_viewport_as_texture.rst:305
msgid ""
"And there you have it. A procedural planet generated using a :ref:`Viewport "
"<class_Viewport>`."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:4
msgid "Custom post-processing"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:9
msgid ""
"Godot provides many post-processing effects out of the box, including Bloom, "
"DOF, and SSAO. Sometimes you want to write your own custom effect. Here's "
"how you can do so."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:12
msgid ""
"Post-processing effects are shaders applied to a frame after Godot rendered "
"it. You first want to render your scene into a :ref:`Viewport "
"<class_Viewport>`, then render the ``Viewport`` inside a :ref:"
"`ViewportTexture <class_ViewportTexture>` and show it on the screen."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:16
msgid ""
"The easiest way to implement a custom post-processing shader is to use "
"Godot's built-in ability to read from the screen texture. If you're not "
"familiar with this, you should read the :ref:`Screen Reading Shaders "
"Tutorial <doc_screen-reading_shaders>` first."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:22
msgid ""
"As of the time of writing, Godot does not support rendering to multiple "
"buffers at the same time. Your post-processing shader will not have access "
"to normals or other render passes. You only have access to the rendered "
"frame."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:27
msgid "Single pass post-processing"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:29
msgid ""
"You will need a ``Viewport`` to render your scene to, and a scene to render "
"your ``Viewport`` on the screen. You can use a :ref:`ViewportContainer "
"<class_ViewportContainer>` to display your ``Viewport`` on the entire screen "
"or inside another :ref:`Control <class_Control>` node."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:36
msgid ""
"Rendering using a ``Viewport`` gives you control over how the scene render, "
"including the framerate, and you can use the ``ViewportContainer`` to render "
"3D objects in a 2D scene."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:40
msgid ""
"For this demo, we will use a :ref:`Node2D <class_Node2D>` with a "
"``ViewportContainer`` and finally a ``Viewport``. Your **Scene** tab should "
"look like this:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:45
msgid ""
"Inside the ``Viewport``, you can have whatever you want. This will contain "
"your main scene. For this tutorial, we will use a field of random boxes:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:50
msgid ""
"Add a new :ref:`ShaderMaterial <class_ShaderMaterial>` to the "
"``ViewportContainer``, and assign a new shader resource to it. You can "
"access your rendered ``Viewport`` with the built-in ``TEXTURE`` uniform."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:55
msgid ""
"You can choose not to use a ``ViewportContainer``, but if you do so, you "
"will need to create your own uniform in the shader and pass the ``Viewport`` "
"texture in manually, like so:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:64
msgid "And you can pass the texture into the shader from GDScript like so:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:72
msgid ""
"Copy the following code to your shader. The above code is a single pass edge "
"detection filter, a `Sobel filter <https://en.wikipedia.org/wiki/"
"Sobel_operator>`_."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:94
msgid ""
"The Sobel filter reads pixels in a 9x9 grid around the current pixel and "
"adds them together, using weight. What makes it interesting is that it "
"assigns weights to each pixel; +1 for each of the eight around the center "
"and -8 for the center pixel. The choice of weights is called a \"kernel\". "
"You can use different kernels to create edge detection filters, outlines, "
"and all sorts of effects."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:102
msgid "Multi-pass post-processing"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:104
msgid ""
"Some post-processing effects like blur are resource intensive. If you break "
"them down in multiple passes however, you can make them run a lot faster. In "
"a multipass material, each pass takes the result from the previous pass as "
"an input and processes it."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:108
msgid ""
"To make a multi-pass post-processing shader, you stack ``Viewport`` nodes. "
"In the example above, you rendered the content of one ``Viewport`` object "
"into the root ``Viewport``, through a ``ViewportContainer`` node. You can do "
"the same thing for a multi-pass shader by rendering the content of one "
"``Viewport`` into another and then rendering the last ``Viewport`` into the "
"root ``Viewport``."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:113
msgid "Your scene hierarchy will look something like this:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:117
msgid ""
"Godot will render the bottom ``Viewport`` node first. So if the order of the "
"passes matters for your shaders, make sure that you assign the shader you "
"want to apply first to the lowest ``ViewportContainer`` in the tree."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:123
msgid ""
"You can also render your Viewports separately without nesting them like "
"this. You just need to use two Viewports and to render them one after the "
"other."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:126
msgid ""
"Apart from the node structure, the steps are the same as with the single-"
"pass post-processing shader."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:128
msgid ""
"As an example, you could write a full screen Gaussian blur effect by "
"attaching the following pieces of code to each of the :ref:"
"`ViewportContainers <class_ViewportContainer>`. The order in which you apply "
"the shaders does not matter:"
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:168
msgid ""
"Using the above code, you should end up with a full screen blur effect like "
"below."
msgstr ""

#: ../../docs/tutorials/viewports/custom_postprocessing.rst:172
msgid ""
"For more information on how ``Viewport`` nodes work, see the :ref:`Viewports "
"Tutorial <doc_viewports>`."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/index.rst:2
msgid "Shading reference"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:4
msgid "Shaders"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:9
msgid ""
"Shaders are unique programs that run on the GPU. They are used to specify "
"how to take mesh data (vertex positions, colors, normals, etc.) and draw "
"them to the screen. Shaders do not process information the same way a normal "
"program does because they are optimized for running on the GPU. One "
"consequence of this is that shaders do not retain their data after they run; "
"they output a final color to the screen and then move on. Accordingly, there "
"is no way of accessing the color output from the last run of the shader."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:16
msgid ""
"Godot uses a shader language very similar to GLSL, but with added "
"functionality and slightly less flexibility. The reason for doing this is "
"that Godot integrates built-in functionality to make writing complex shaders "
"substantially easier. Godot wraps the user-written shader code in code of "
"its own. That way, Godot handles a lot of the low-level stuff that the user "
"doesn't need to worry about, and it is able to parse your shader code and "
"use it to affect the rendering pipeline. For more advanced shaders, you can "
"turn this functionality off using a render_mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:23
msgid ""
"This document provides you with some information about shaders, specific to "
"Godot. For a detailed reference of the shading language in Godot see the :"
"ref:`Godot shading language doc<doc_shading_language>`."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:27
msgid "Shader types"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:29
msgid ""
"Instead of supplying a general purpose configuration for all uses (2D, 3D, "
"particles), Godot shaders must specify what they are intended for. Different "
"types support different render modes, built-in variables, and processing "
"functions."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:33
msgid ""
"All shaders need to specify their type in the first line, in the following "
"format:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:41
msgid ":ref:`spatial <doc_spatial_shader>`: For 3D rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:42
msgid ":ref:`canvas_item <doc_canvas_item_shader>`: For 2D rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:43
msgid ":ref:`particles <doc_particle_shader>`: For particle systems."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:45
msgid ""
"For detailed information on each shading type, see the corresponding "
"reference document."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:48
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:12
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:14
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:27
msgid "Render modes"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:50
msgid ""
"Different shader types support different render modes. They are optional "
"and, if specified, must be after the *shader_type*. Render modes are used to "
"alter the way built-in functionality is handled. For example, it is common "
"to use the render mode ``unshaded`` to skip the built-in light processor "
"function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:55
msgid "Render modes are specified underneath the shader type:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:62
msgid ""
"Each shader type has a different list of render modes available. See the "
"document for each shader type for a complete list of render modes."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:66
msgid "Processor functions"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:68
msgid ""
"Depending on the shader type, different processor functions may be "
"optionally overridden. For \"spatial\" and \"canvas_item\", it is possible "
"to override ``vertex``, ``fragment``, and ``light``. For \"particles\", only "
"``vertex`` can be overridden."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:73
msgid "Vertex processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:75
msgid ""
"The ``vertex`` processing function is called once for every vertex in "
"\"spatial\" and \"canvas_item\" shaders. For \"particles\" shaders, it is "
"called once for every particle."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:78
msgid ""
"The ``vertex`` function is used to modify per-vertex information that will "
"be passed on to the fragment function. It can also be used to establish "
"variables that will be sent to the fragment function by using varyings(see "
"other doc)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:82
msgid ""
"By default, Godot will take your vertex information and transform it "
"accordingly to be drawn. If this is undesirable, you can use render modes to "
"transform the data yourself; see the :ref:`Spatial shader doc "
"<doc_spatial_shader>` for an example of this."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:87
msgid "Fragment processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:89
msgid ""
"The ``fragment`` processing function is used to set up the Godot material "
"parameters per pixel. This code runs on every visible pixel the object or "
"primitive draws. It is only available in \"spatial\" and \"canvas_item\" "
"shaders."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:93
msgid ""
"The standard use of the fragment function is to set up material properties "
"that will be used to calculate lighting. For example, you would set values "
"for ``ROUGHNESS``, ``RIM``, or ``TRANSMISSION`` which would tell the light "
"function how the lights respond to that fragment. This makes it possible to "
"control a complex shading pipeline without the user having to write much "
"code. If you don't need this built-in functionality, you can ignore it and "
"write your own light processing function and Godot will optimize it away. "
"For example, if you do not write a value to ``RIM``, Godot will not "
"calculate rim lighting. During compilation, Godot checks to see if ``RIM`` "
"is used; if not, it cuts all the corresponding code out. Therefore, you will "
"not waste calculations on effects that you do not use."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:103
msgid "Light processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:105
msgid ""
"The ``light`` processor runs per pixel too, but also runs for every light "
"that affects the object (and does not run if no lights affect the object). "
"It exists as a function called inside the ``fragment`` processor and "
"typically operates on the material properties setup inside the ``fragment`` "
"function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shaders.rst:110
msgid ""
"The ``light`` processor works differently in 2D than it does in 3D; for a "
"description of how it works in each, see their documentation, :ref:"
"`CanvasItem shaders <doc_canvas_item_shader>` and :ref:`Spatial shaders "
"<doc_spatial_shader>`, respectively."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:4
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:127
msgid "Shading language"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:9
msgid ""
"Godot uses a shading language similar to GLSL ES 3.0. Most datatypes and "
"functions are supported, and the few remaining ones will likely be added "
"over time."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:12
msgid ""
"If you are already familiar with GLSL, the :ref:`Godot Shader Migration "
"Guide<doc_migrating_to_godot_shader_language>` is a resource that will help "
"you transition from regular GLSL to Godot's shading language."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:16
msgid "Data types"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:18
msgid "Most GLSL ES 3.0 datatypes are supported:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:23
msgid "**void**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:23
msgid "Void datatype, useful only for functions that return nothing."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:25
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:547
msgid "**bool**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:25
msgid "Boolean datatype, can only contain ``true`` or ``false``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:27
msgid "**bvec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:27
msgid "Two-component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:29
msgid "**bvec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:29
msgid "Three-component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:31
msgid "**bvec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:31
msgid "Four-component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:33
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:549
msgid "**int**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:33
msgid "Signed scalar integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:35
msgid "**ivec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:35
msgid "Two-component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:37
msgid "**ivec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:37
msgid "Three-component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:39
msgid "**ivec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:39
msgid "Four-component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:41
msgid "**uint**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:41
msgid "Unsigned scalar integer; can't contain negative numbers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:43
msgid "**uvec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:43
msgid "Two-component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:45
msgid "**uvec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:45
msgid "Three-component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:47
msgid "**uvec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:47
msgid "Four-component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:49
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:551
msgid "**float**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:49
msgid "Floating-point scalar."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:51
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:553
msgid "**vec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:51
msgid "Two-component vector of floating-point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:53
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:555
msgid "**vec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:53
msgid "Three-component vector of floating-point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:55
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:524
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:557
msgid "**vec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:55
msgid "Four-component vector of floating-point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:57
msgid "**mat2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:57
msgid "2x2 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:59
msgid "**mat3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:59
msgid "3x3 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:61
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:559
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:561
msgid "**mat4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:61
msgid "4x4 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:63
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:528
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:530
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:532
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:534
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:536
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:538
msgid "**sampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:63
msgid "Sampler type for binding 2D textures, which are read as float."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:65
msgid "**isampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:65
msgid "Sampler type for binding 2D textures, which are read as signed integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:67
msgid "**usampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:67
msgid ""
"Sampler type for binding 2D textures, which are read as unsigned integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:69
msgid "**sampler2DArray**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:69
msgid "Sampler type for binding 2D texture arrays, which are read as float."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:71
msgid "**isampler2DArray**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:71
msgid ""
"Sampler type for binding 2D texture arrays, which are read as signed integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:73
msgid "**usampler2DArray**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:73
msgid ""
"Sampler type for binding 2D texture arrays, which are read as unsigned "
"integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:75
msgid "**sampler3D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:75
msgid "Sampler type for binding 3D textures, which are read as float."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:77
msgid "**isampler3D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:77
msgid "Sampler type for binding 3D textures, which are read as signed integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:79
msgid "**usampler3D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:79
msgid ""
"Sampler type for binding 3D textures, which are read as unsigned integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:81
msgid "**samplerCube**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:81
msgid "Sampler type for binding Cubemaps, which are read as floats."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:87
msgid ""
"Just like GLSL ES 3.0, implicit casting between scalars and vectors of the "
"same size but different type is not allowed. Casting of types of different "
"size is also not allowed. Conversion must be done explicitly via "
"constructors."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:98
msgid ""
"Default integer constants are signed, so casting is always needed to convert "
"to unsigned:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:107
msgid "Members"
msgstr "חברים"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:109
msgid ""
"Individual scalar members of vector types are accessed via the \"x\", \"y\", "
"\"z\" and \"w\" members. Alternatively, using \"r\", \"g\", \"b\" and \"a\" "
"also works and is equivalent. Use whatever fits best for your needs."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:113
msgid ""
"For matrices, use the ``m[row][column]`` indexing syntax to access each "
"scalar, or ``m[idx]`` to access a vector by row index. For example, for "
"accessing the y position of an object in a mat4 you  use ``m[3][1]``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:118
msgid "Constructing"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:120
msgid "Construction of vector types must always pass:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:132
msgid ""
"Construction of matrix types requires vectors of the same dimension as the "
"matrix. You can also build a diagonal matrix using ``matx(float)`` syntax. "
"Accordingly, ``mat4(1.0)`` is an identity matrix."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:142
msgid ""
"Matrices can also be built from a matrix of another dimension. There are two "
"rules : If a larger matrix is constructed from a smaller matrix, the "
"additional rows and columns are set to the values they would have in an "
"identity matrix. If a smaller matrix is constructed from a larger matrix, "
"the top, left submatrix of the larger matrix is used."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:155
msgid "Swizzling"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:157
msgid ""
"It is possible to obtain any combination of components in any order, as long "
"as the result is another vector type (or scalar). This is easier shown than "
"explained:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:174
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:116
msgid "Precision"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:176
msgid ""
"It is possible to add precision modifiers to datatypes; use them for "
"uniforms, variables, arguments and varyings:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:185
msgid ""
"Using lower precision for some operations can speed up the math involved (at "
"the cost of less precision). This is rarely needed in the vertex processor "
"function (where full precision is needed most of the time), but is often "
"useful in the fragment processor."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:189
msgid ""
"Keep in mind that some architectures (mainly mobile) benefit a lot from "
"this, but are also restricted (conversion between precisions has a cost). "
"Please read the relevant documentation on the target architecture to find "
"out more. In all honesty though, mobile drivers are buggy, so, to stay out "
"of trouble, make simple shaders without specifying precision unless you "
"*really* need to."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:197
msgid ""
"Arrays are containers for multiple variables of a similar type. Note: As of "
"Godot 3.2, only local and varying arrays have been implemented."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:201
#, fuzzy
msgid "Local arrays"
msgstr "נקודות ציון מקומיות"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:203
msgid ""
"Local arrays are declared in functions. They can use all of the allowed "
"datatypes, except samplers. The array declaration follows a C-style syntax: "
"``[const] + [precision] + typename + identifier + [array size]``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:212
msgid "They can be initialized at the beginning like:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:224
msgid ""
"You can declare multiple arrays (even with different sizes) in one "
"expression:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:234
msgid "To access an array element, use the indexing syntax:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:244
msgid ""
"Arrays also have a built-in function ``.length()`` (not to be confused with "
"the built-in ``length()`` function). It doesn't accept any parameters and "
"will return the array's size."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:253
msgid ""
"Note: If you use an index below 0 or greater than array size - the shader "
"will crash and break rendering. To prevent this, use ``length()``, ``if``, "
"or ``clamp()`` functions to ensure the index is between 0 and the array's "
"length. Always carefully test and check your code. If you pass a constant "
"expression or a simple number, the editor will check its bounds to prevent "
"this crash."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:258
msgid ""
"Use the ``const`` keyword before the variable declaration to make that "
"variable immutable, which means that it cannot be modified. All basic types, "
"except samplers can be declared as constants. Accessing and using a constant "
"value is slightly faster than using a uniform. Constants must be initialized "
"at their declaration."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:268
msgid ""
"Constants cannot be modified and additionally cannot have hints, but "
"multiple of them (if they have the same type) can be declared in a single "
"expression e.g"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:274
msgid "Similar to variables, arrays can also be declared with ``const``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:284
msgid ""
"Constants can be declared both globally (outside of any function) or locally "
"(inside a function). Global constants are useful when you want to have "
"access to a value throughout your shader that does not need to be modified. "
"Like uniforms, global constants are shared between all shader stages, but "
"they are not accessible outside of the shader."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:296
msgid ""
"Godot shading language supports the same set of operators as GLSL ES 3.0. "
"Below is the list of them in precedence order:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:299
msgid "Precedence"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:299
msgid "Class"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:299
msgid "Operator"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:301
msgid "1 (highest)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:301
msgid "parenthetical grouping"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:301
msgid "**()**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:303
#: ../../docs/tutorials/misc/binary_serialization_api.rst:29
msgid "2"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:303
msgid "unary"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:303
msgid "**+, -, !, ~**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:305
#: ../../docs/tutorials/misc/binary_serialization_api.rst:31
msgid "3"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:305
msgid "multiplicative"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:305
msgid "**/, \\*, %**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:307
#: ../../docs/tutorials/misc/binary_serialization_api.rst:33
#: ../../docs/tutorials/misc/binary_serialization_api.rst:97
#: ../../docs/tutorials/misc/binary_serialization_api.rst:106
#: ../../docs/tutorials/misc/binary_serialization_api.rst:115
#: ../../docs/tutorials/misc/binary_serialization_api.rst:124
#: ../../docs/tutorials/misc/binary_serialization_api.rst:137
#: ../../docs/tutorials/misc/binary_serialization_api.rst:139
#: ../../docs/tutorials/misc/binary_serialization_api.rst:148
#: ../../docs/tutorials/misc/binary_serialization_api.rst:150
#: ../../docs/tutorials/misc/binary_serialization_api.rst:152
#: ../../docs/tutorials/misc/binary_serialization_api.rst:154
#: ../../docs/tutorials/misc/binary_serialization_api.rst:163
#: ../../docs/tutorials/misc/binary_serialization_api.rst:165
#: ../../docs/tutorials/misc/binary_serialization_api.rst:167
#: ../../docs/tutorials/misc/binary_serialization_api.rst:176
#: ../../docs/tutorials/misc/binary_serialization_api.rst:178
#: ../../docs/tutorials/misc/binary_serialization_api.rst:180
#: ../../docs/tutorials/misc/binary_serialization_api.rst:182
#: ../../docs/tutorials/misc/binary_serialization_api.rst:184
#: ../../docs/tutorials/misc/binary_serialization_api.rst:186
#: ../../docs/tutorials/misc/binary_serialization_api.rst:195
#: ../../docs/tutorials/misc/binary_serialization_api.rst:197
#: ../../docs/tutorials/misc/binary_serialization_api.rst:199
#: ../../docs/tutorials/misc/binary_serialization_api.rst:201
#: ../../docs/tutorials/misc/binary_serialization_api.rst:210
#: ../../docs/tutorials/misc/binary_serialization_api.rst:212
#: ../../docs/tutorials/misc/binary_serialization_api.rst:214
#: ../../docs/tutorials/misc/binary_serialization_api.rst:216
#: ../../docs/tutorials/misc/binary_serialization_api.rst:225
#: ../../docs/tutorials/misc/binary_serialization_api.rst:227
#: ../../docs/tutorials/misc/binary_serialization_api.rst:229
#: ../../docs/tutorials/misc/binary_serialization_api.rst:231
#: ../../docs/tutorials/misc/binary_serialization_api.rst:233
#: ../../docs/tutorials/misc/binary_serialization_api.rst:235
#: ../../docs/tutorials/misc/binary_serialization_api.rst:244
#: ../../docs/tutorials/misc/binary_serialization_api.rst:246
#: ../../docs/tutorials/misc/binary_serialization_api.rst:248
#: ../../docs/tutorials/misc/binary_serialization_api.rst:250
#: ../../docs/tutorials/misc/binary_serialization_api.rst:252
#: ../../docs/tutorials/misc/binary_serialization_api.rst:254
#: ../../docs/tutorials/misc/binary_serialization_api.rst:256
#: ../../docs/tutorials/misc/binary_serialization_api.rst:258
#: ../../docs/tutorials/misc/binary_serialization_api.rst:260
#: ../../docs/tutorials/misc/binary_serialization_api.rst:269
#: ../../docs/tutorials/misc/binary_serialization_api.rst:271
#: ../../docs/tutorials/misc/binary_serialization_api.rst:273
#: ../../docs/tutorials/misc/binary_serialization_api.rst:275
#: ../../docs/tutorials/misc/binary_serialization_api.rst:277
#: ../../docs/tutorials/misc/binary_serialization_api.rst:279
#: ../../docs/tutorials/misc/binary_serialization_api.rst:281
#: ../../docs/tutorials/misc/binary_serialization_api.rst:283
#: ../../docs/tutorials/misc/binary_serialization_api.rst:285
#: ../../docs/tutorials/misc/binary_serialization_api.rst:287
#: ../../docs/tutorials/misc/binary_serialization_api.rst:289
#: ../../docs/tutorials/misc/binary_serialization_api.rst:291
#: ../../docs/tutorials/misc/binary_serialization_api.rst:300
#: ../../docs/tutorials/misc/binary_serialization_api.rst:302
#: ../../docs/tutorials/misc/binary_serialization_api.rst:304
#: ../../docs/tutorials/misc/binary_serialization_api.rst:306
#: ../../docs/tutorials/misc/binary_serialization_api.rst:315
#: ../../docs/tutorials/misc/binary_serialization_api.rst:335
#: ../../docs/tutorials/misc/binary_serialization_api.rst:337
#: ../../docs/tutorials/misc/binary_serialization_api.rst:345
#: ../../docs/tutorials/misc/binary_serialization_api.rst:364
#: ../../docs/tutorials/misc/binary_serialization_api.rst:376
#: ../../docs/tutorials/misc/binary_serialization_api.rst:388
#: ../../docs/tutorials/misc/binary_serialization_api.rst:401
#: ../../docs/tutorials/misc/binary_serialization_api.rst:403
#: ../../docs/tutorials/misc/binary_serialization_api.rst:412
#: ../../docs/tutorials/misc/binary_serialization_api.rst:414
#: ../../docs/tutorials/misc/binary_serialization_api.rst:423
#: ../../docs/tutorials/misc/binary_serialization_api.rst:431
#: ../../docs/tutorials/misc/binary_serialization_api.rst:444
#: ../../docs/tutorials/misc/binary_serialization_api.rst:446
#: ../../docs/tutorials/misc/binary_serialization_api.rst:448
#: ../../docs/tutorials/misc/binary_serialization_api.rst:457
#: ../../docs/tutorials/misc/binary_serialization_api.rst:459
#: ../../docs/tutorials/misc/binary_serialization_api.rst:461
#: ../../docs/tutorials/misc/binary_serialization_api.rst:463
#: ../../docs/tutorials/misc/binary_serialization_api.rst:472
#: ../../docs/tutorials/misc/binary_serialization_api.rst:474
#: ../../docs/tutorials/misc/binary_serialization_api.rst:476
#: ../../docs/tutorials/misc/binary_serialization_api.rst:478
#: ../../docs/tutorials/misc/binary_serialization_api.rst:480
msgid "4"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:307
msgid "additive"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:307
msgid "**+, -**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:309
#: ../../docs/tutorials/misc/binary_serialization_api.rst:35
msgid "5"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:309
msgid "bit-wise shift"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:309
msgid "**<<, >>**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:311
#: ../../docs/tutorials/misc/binary_serialization_api.rst:37
msgid "6"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:311
msgid "relational"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:311
msgid "**<, >, <=, >=**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:313
#: ../../docs/tutorials/misc/binary_serialization_api.rst:39
msgid "7"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:313
msgid "equality"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:313
msgid "**==, !=**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:315
#: ../../docs/tutorials/misc/binary_serialization_api.rst:41
#: ../../docs/tutorials/misc/binary_serialization_api.rst:106
#: ../../docs/tutorials/misc/binary_serialization_api.rst:126
#: ../../docs/tutorials/misc/binary_serialization_api.rst:139
#: ../../docs/tutorials/misc/binary_serialization_api.rst:150
#: ../../docs/tutorials/misc/binary_serialization_api.rst:165
#: ../../docs/tutorials/misc/binary_serialization_api.rst:178
#: ../../docs/tutorials/misc/binary_serialization_api.rst:197
#: ../../docs/tutorials/misc/binary_serialization_api.rst:212
#: ../../docs/tutorials/misc/binary_serialization_api.rst:227
#: ../../docs/tutorials/misc/binary_serialization_api.rst:246
#: ../../docs/tutorials/misc/binary_serialization_api.rst:271
#: ../../docs/tutorials/misc/binary_serialization_api.rst:302
#: ../../docs/tutorials/misc/binary_serialization_api.rst:324
#: ../../docs/tutorials/misc/binary_serialization_api.rst:337
msgid "8"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:315
msgid "bit-wise AND"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:315
msgid "**&**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:317
#: ../../docs/tutorials/misc/binary_serialization_api.rst:43
msgid "9"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:317
msgid "bit-wise exclusive OR"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:317
msgid "**^**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:319
#: ../../docs/tutorials/misc/binary_serialization_api.rst:45
msgid "10"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:319
msgid "bit-wise inclusive OR"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:319
msgid "**|**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:321
#: ../../docs/tutorials/misc/binary_serialization_api.rst:47
msgid "11"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:321
msgid "logical AND"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:321
msgid "**&&**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:323
msgid "12 (lowest)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:323
msgid "logical inclusive OR"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:323
msgid "**||**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:327
msgid "Flow control"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:329
msgid "Godot Shading language supports the most common types of flow control:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:369
msgid ""
"Keep in mind that, in modern GPUs, an infinite loop can exist and can freeze "
"your application (including editor). Godot can't protect you from this, so "
"be careful not to make this mistake!"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:378
msgid "Discarding"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:380
msgid ""
"Fragment and light functions can use the **discard** keyword. If used, the "
"fragment is discarded and nothing is written."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:385
msgid ""
"It is possible to define functions in a Godot shader. They use the following "
"syntax:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:400
msgid ""
"You can only use functions that have been defined above (higher in the "
"editor) the function from which you are calling them."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:403
msgid "Function arguments can have special qualifiers:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:405
msgid "**in**: Means the argument is only for reading (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:406
msgid "**out**: Means the argument is only for writing."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:407
msgid "**inout**: Means the argument is fully passed via reference."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:409
msgid "Example below:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:418
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:57
msgid "Varyings"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:420
msgid ""
"To send data from the vertex to the fragment processor function, *varyings* "
"are used. They are set for every primitive vertex in the *vertex processor*, "
"and the value is interpolated for every pixel in the fragment processor."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:437
msgid "Varying can also be an array:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:454
msgid "Interpolation qualifiers"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:456
msgid ""
"Certain values are interpolated during the shading pipeline. You can modify "
"how these interpolations are done by using *interpolation qualifiers*."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:473
msgid "There are two possible interpolation qualifiers:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:476
msgid "Qualifier"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:478
msgid "**flat**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:478
msgid "The value is not interpolated."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:480
msgid "**smooth**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:480
msgid ""
"The value is interpolated in a perspective-correct fashion. This is the "
"default."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:485
#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:192
msgid "Uniforms"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:487
msgid ""
"Passing values to shaders is possible. These are global to the whole shader "
"and are called *uniforms*. When a shader is later assigned to a material, "
"the uniforms will appear as editable parameters in it. Uniforms can't be "
"written from within the shader."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:497
msgid ""
"You can set uniforms in the editor in the material. Or you can set them "
"through GDScript:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:503
msgid ""
"The first argument to ``set_shader_param`` is the name of the uniform in the "
"shader. It must match *exactly* to the name of the uniform in the shader or "
"else it will not be recognized."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:506
msgid ""
"Any GLSL type except for *void* can be a uniform. Additionally, Godot "
"provides optional shader hints to make the compiler understand for what the "
"uniform is used."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:517
msgid ""
"It's important to understand that textures that are supplied as color "
"require hints for proper sRGB->linear conversion (i.e. ``hint_albedo``), as "
"Godot's 3D engine renders in linear color space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:519
msgid "Full list of hints below:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:522
msgid "Hint"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:524
msgid "hint_color"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:524
msgid "Used as color"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:526
msgid "**int, float**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:526
msgid "hint_range(min, max[, step])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:526
msgid "Used as range (with min/max/step)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:528
msgid "hint_albedo"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:528
msgid "Used as albedo color, default white"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:530
msgid "hint_black_albedo"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:530
msgid "Used as albedo color, default black"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:532
msgid "hint_normal"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:532
msgid "Used as normalmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:534
msgid "hint_white"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:534
msgid "As value, default to white."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:536
msgid "hint_black"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:536
msgid "As value, default to black"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:538
msgid "hint_aniso"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:538
msgid "As flowmap, default to right."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:541
msgid ""
"GDScript uses different variable types than GLSL does, so when passing "
"variables from GDScript to shaders, Godot converts the type automatically. "
"Below is a table of the corresponding types:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:545
msgid "GDScript type"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:545
msgid "GLSL type"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:553
msgid "**Vector2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:555
msgid "**Vector3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:557
#, fuzzy
msgid "**Color**"
msgstr "**בשביל העורך:**"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:559
#, fuzzy
msgid "**Transform**"
msgstr "התמרה"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:561
#, fuzzy
msgid "**Transform2D**"
msgstr "התמרה"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:564
msgid ""
"Be careful when setting shader uniforms from GDScript, no error will be "
"thrown if the type does not match. Your shader will just exhibit undefined "
"behavior."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:567
msgid "Uniforms can also be assigned default values:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:577
msgid "Built-in functions"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:579
msgid ""
"A large number of built-in functions are supported, conforming to GLSL ES "
"3.0. When vec_type (float), vec_int_type, vec_uint_type, vec_bool_type "
"nomenclature is used, it can be scalar or vector."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:582
msgid ""
"For a list of the functions that are not available in the GLES2 backend, "
"please see the :ref:`Differences between GLES2 and GLES3 doc "
"<doc_gles2_gles3_differences>`."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:586
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:135
msgid "Function"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:588
msgid "vec_type **radians** (vec_type degrees)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:588
msgid "Convert degrees to radians"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:590
msgid "vec_type **degrees** (vec_type radians)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:590
msgid "Convert radians to degrees"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:592
msgid "vec_type **sin** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:592
msgid "Sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:594
msgid "vec_type **cos** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:594
msgid "Cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:596
msgid "vec_type **tan** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:596
msgid "Tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:598
msgid "vec_type **asin** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:598
msgid "Arcsine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:600
msgid "vec_type **acos** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:600
msgid "Arccosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:602
msgid "vec_type **atan** (vec_type y_over_x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:602
msgid "Arctangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:604
msgid "vec_type **atan** (vec_type y, vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:604
msgid "Arctangent to convert vector to angle"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:606
msgid "vec_type **sinh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:606
msgid "Hyperbolic sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:608
msgid "vec_type **cosh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:608
msgid "Hyperbolic cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:610
msgid "vec_type **tanh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:610
msgid "Hyperbolic tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:612
msgid "vec_type **asinh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:612
msgid "Inverse hyperbolic sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:614
msgid "vec_type **acosh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:614
msgid "Inverse hyperbolic cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:616
msgid "vec_type **atanh** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:616
msgid "Inverse hyperbolic tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:618
msgid "vec_type **pow** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:618
msgid "Power (undefined if ``x`` < 0 or if ``x`` = 0 and ``y`` <= 0)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:620
msgid "vec_type **exp** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:620
msgid "Base-e exponential"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:622
msgid "vec_type **exp2** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:622
msgid "Base-2 exponential"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:624
msgid "vec_type **log** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:624
msgid "Natural logarithm"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:626
msgid "vec_type **log2** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:626
msgid "Base-2 logarithm"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:628
msgid "vec_type **sqrt** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:628
msgid "Square root"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:630
msgid "vec_type **inversesqrt** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:630
msgid "Inverse square root"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:632
msgid "vec_type **abs** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:632
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:634
msgid "Absolute"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:634
msgid "ivec_type **abs** (ivec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:636
msgid "vec_type **sign** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:636
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:638
msgid "Sign"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:638
msgid "ivec_type **sign** (ivec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:640
msgid "vec_type **floor** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:640
msgid "Floor"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:642
msgid "vec_type **round** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:642
msgid "Round"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:644
msgid "vec_type **roundEven** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:644
msgid "Round to the nearest even number"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:646
msgid "vec_type **trunc** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:646
msgid "Truncation"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:648
msgid "vec_type **ceil** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:648
msgid "Ceil"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:650
msgid "vec_type **fract** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:650
msgid "Fractional"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:652
msgid "vec_type **mod** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:652
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:654
msgid "Remainder"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:654
msgid "vec_type **mod** (vec_type x , float y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:656
msgid "vec_type **modf** (vec_type x, out vec_type i)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:656
msgid "Fractional of ``x``, with ``i`` as integer part"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:658
msgid "vec_type  **min** (vec_type a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:658
msgid "Minimum"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:660
msgid "vec_type  **max** (vec_type a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:660
msgid "Maximum"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:662
msgid "vec_type **clamp** (vec_type x, vec_type min, vec_type max)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:662
msgid "Clamp to ``min..max``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:664
msgid "vec_type **mix** (float a, float b, float c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:664
#, fuzzy
msgid "Linear interpolate"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:666
msgid "vec_type **mix** (vec_type a, vec_type b, float c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:666
msgid "Linear interpolate (scalar coefficient)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:668
msgid "vec_type **mix** (vec_type a, vec_type b, vec_type c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:668
msgid "Linear interpolate (vector coefficient)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:670
msgid "vec_type **mix** (vec_type a, vec_type b, bvec_type c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:670
msgid "Linear interpolate (boolean-vector selection)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:672
msgid "vec_type **step** (vec_type a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:672
msgid "``b[i] < a[i] ? 0.0 : 1.0``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:674
msgid "vec_type **step** (float a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:674
msgid "``b[i] < a ? 0.0 : 1.0``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:676
msgid "vec_type **smoothstep** (vec_type a, vec_type b, vec_type c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:676
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:678
#, fuzzy
msgid "Hermite interpolate"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:678
msgid "vec_type **smoothstep** (float a, float b, vec_type c)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:680
msgid "bvec_type **isnan** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:680
msgid "Returns ``true`` if scalar or vector component is ``NaN``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:682
msgid "bvec_type **isinf** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:682
msgid "Returns ``true`` if scalar or vector component is ``INF``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:684
msgid "ivec_type **floatBitsToInt** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:684
msgid "Float->Int bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:686
msgid "uvec_type **floatBitsToUint** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:686
msgid "Float->UInt bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:688
msgid "vec_type **intBitsToFloat** (ivec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:688
msgid "Int->Float bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:690
msgid "vec_type **uintBitsToFloat** (uvec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:690
msgid "UInt->Float bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:692
msgid "float **length** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:692
msgid "Vector length"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:694
msgid "float **distance** (vec_type a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:694
msgid "Distance between vectors i.e ``length(a - b)``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:696
msgid "float **dot** (vec_type a, vec_type b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:698
msgid "vec3 **cross** (vec3 a, vec3 b)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:698
msgid "Cross croduct"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:700
msgid "vec_type **normalize** (vec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:700
msgid "Normalize to unit length"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:702
msgid "vec3 **reflect** (vec3 I, vec3 N)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:702
msgid "Reflect"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:704
msgid "vec3 **refract** (vec3 I, vec3 N, float eta)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:704
msgid "Refract"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:706
msgid "vec_type **faceforward** (vec_type N, vec_type I, vec_type Nref)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:706
msgid "If ``dot(Nref, I)`` < 0, return N, otherwise –N"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:708
msgid "mat_type **matrixCompMult** (mat_type x, mat_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:708
msgid "Matrix component multiplication"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:710
msgid "mat_type **outerProduct** (vec_type column, vec_type row)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:710
msgid "Matrix outer product"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:712
msgid "mat_type **transpose** (mat_type m)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:712
msgid "Transpose matrix"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:714
msgid "float **determinant** (mat_type m)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:714
msgid "Matrix determinant"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:716
msgid "mat_type **inverse** (mat_type m)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:716
msgid "Inverse matrix"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:718
msgid "bvec_type **lessThan** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:718
msgid "Bool vector comparison on < int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:720
msgid "bvec_type **greaterThan** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:720
msgid "Bool vector comparison on > int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:722
msgid "bvec_type **lessThanEqual** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:722
msgid "Bool vector comparison on <= int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:724
msgid "bvec_type **greaterThanEqual** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:724
msgid "Bool vector comparison on >= int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:726
msgid "bvec_type **equal** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:726
msgid "Bool vector comparison on == int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:728
msgid "bvec_type **notEqual** (vec_type x, vec_type y)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:728
msgid "Bool vector comparison on != int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:730
msgid "bool **any** (bvec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:730
msgid "Any component is ``true``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:732
msgid "bool **all** (bvec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:732
msgid "All components are ``true``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:734
msgid "bvec_type **not** (bvec_type x)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:734
msgid "Invert boolean vector"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:736
msgid "ivec2 **textureSize** (sampler2D_type s, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:736
msgid "Get the size of a 2D texture"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:738
msgid "ivec3 **textureSize** (sampler2DArray_type s, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:738
msgid "Get the size of a 2D texture array"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:740
msgid "ivec3 **textureSize** (sampler3D s, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:740
msgid "Get the size of a 3D texture"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:742
msgid "ivec2 **textureSize** (samplerCube s, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:742
msgid "Get the size of a cubemap texture"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:744
msgid "vec4_type **texture** (sampler2D_type s, vec2 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:744
msgid "Perform a 2D texture read"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:746
msgid "vec4_type  **texture** (sampler2DArray_type s, vec3 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:746
msgid "Perform a 2D texture array read"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:748
msgid "vec4_type  **texture** (sampler3D_type s, vec3 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:748
msgid "Perform a 3D texture read"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:750
msgid "vec4 **texture** (samplerCube s, vec3 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:750
msgid "Perform a cubemap texture read"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:752
msgid "vec4_type **textureProj** (sampler2D_type s, vec3 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:752
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:754
msgid "Perform a 2D texture read with projection"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:754
msgid "vec4_type **textureProj** (sampler2D_type s, vec4 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:756
msgid "vec4_type  **textureProj** (sampler3D_type s, vec4 uv [, float bias])"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:756
msgid "Perform a 3D texture read with projection"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:758
msgid "vec4_type **textureLod** (sampler2D_type s, vec2 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:758
msgid "Perform a 2D texture read at custom mipmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:760
msgid "vec4_type **textureLod** (sampler2DArray_type s, vec3 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:760
msgid "Perform a 2D texture array read at custom mipmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:762
msgid "vec4_type **textureLod** (sampler3D_type s, vec3 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:762
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:764
msgid "Perform a 3D texture read at custom mipmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:764
msgid "vec4 **textureLod** (samplerCube s, vec3 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:766
msgid "vec4_type **textureProjLod** (sampler2D_type s, vec3 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:766
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:768
msgid "Perform a 2D texture read with projection/LOD"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:768
msgid "vec4_type **textureProjLod** (sampler2D_type s, vec4 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:770
msgid "vec4_type **textureProjLod** (sampler3D_type s, vec4 uv, float lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:770
msgid "Perform a 3D texture read with projection/LOD"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:772
msgid "vec4_type **texelFetch** (sampler2D_type s, ivec2 uv, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:772
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:774
#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:776
msgid "Fetch a single texel using integer coordinates"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:774
msgid "vec4_type **texelFetch** (sampler2DArray_type s, ivec3 uv, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:776
msgid "vec4_type **texelFetch** (sampler3D_type s, ivec3 uv, int lod)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:778
msgid "vec_type **dFdx** (vec_type p)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:778
msgid "Derivative in ``x`` using local differencing"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:780
msgid "vec_type **dFdy** (vec_type p)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:780
msgid "Derivative in ``y`` using local differencing"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:782
msgid "vec_type **fwidth** (vec_type p)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/shading_language.rst:782
msgid "Sum of absolute derivative in ``x`` and ``y``"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:4
msgid "Spatial shaders"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:6
msgid ""
"Spatial shaders are used for shading 3D objects. They are the most complex "
"type of shader Godot offers. Spatial shaders are highly configurable with "
"different render modes and different rendering options (e.g. Subsurface "
"Scattering, Transmission, Ambient Occlusion, Rim lighting etc). Users can "
"optionally write vertex, fragment, and light processor functions to affect "
"how objects are drawn."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:15
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:17
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:30
msgid "Render mode"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:17
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:19
msgid "**blend_mix**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:17
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:19
msgid "Mix blend mode (alpha is transparency), default."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:19
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:21
msgid "**blend_add**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:19
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:21
msgid "Additive blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:21
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:23
msgid "**blend_sub**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:21
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:23
msgid "Subtractive blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:23
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:25
msgid "**blend_mul**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:23
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:25
msgid "Multiplicative blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:25
msgid "**depth_draw_opaque**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:25
msgid "Only draw depth for opaque geometry (not transparent)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:27
msgid "**depth_draw_always**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:27
msgid "Always draw depth (opaque and transparent)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:29
msgid "**depth_draw_never**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:29
msgid "Never draw depth."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:31
msgid "**depth_draw_alpha_prepass**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:31
msgid "Do opaque depth pre-pass for transparent geometry."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:33
msgid "**depth_test_disable**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:33
msgid "Disable depth testing."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:35
msgid "**cull_front**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:35
msgid "Cull front-faces."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:37
msgid "**cull_back**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:37
msgid "Cull back-faces (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:39
msgid "**cull_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:39
msgid "Culling disabled (double sided)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:41
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:31
msgid "**unshaded**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:41
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:31
msgid "Result is just albedo. No lighting/shading happens in material."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:43
msgid "**diffuse_lambert**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:43
msgid "Lambert shading for diffuse (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:45
msgid "**diffuse_lambert_wrap**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:45
msgid "Lambert wrapping (roughness dependent) for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:47
msgid "**diffuse_oren_nayar**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:47
msgid "Oren Nayar for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:49
msgid "**diffuse_burley**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:49
msgid "Burley (Disney PBS) for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:51
msgid "**diffuse_toon**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:51
msgid "Toon shading for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:53
msgid "**specular_schlick_ggx**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:53
msgid "Schlick-GGX for specular (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:55
msgid "**specular_blinn**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:55
msgid "Blinn for specular (compatibility)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:57
msgid "**specular_phong**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:57
msgid "Phong for specular (compatibility)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:59
msgid "**specular_toon**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:59
msgid "Toon for specular."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:61
msgid "**specular_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:61
msgid "Disable specular."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:63
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:35
msgid "**skip_vertex_transform**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:63
msgid "VERTEX/NORMAL/etc. need to be transformed manually in vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:65
msgid "**world_vertex_coords**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:65
msgid "VERTEX/NORMAL/etc. are modified in world coordinates instead of local."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:67
msgid "**ensure_correct_normals**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:67
msgid "Use when non-uniform scale is applied to mesh."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:69
msgid "**vertex_lighting**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:69
msgid "Use vertex-based lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:71
msgid "**shadows_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:71
msgid "Disable computing shadows in shader."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:73
msgid "**ambient_light_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:73
msgid "Disable contribution from ambient light and radiance map."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:75
msgid "**shadow_to_opacity**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:81
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:39
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:40
#, fuzzy
msgid "Built-ins"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:83
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:41
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:42
msgid ""
"Values marked as \"in\" are read-only. Values marked as \"out\" are for "
"optional writing and will not necessarily contain sensible values. Values "
"marked as \"inout\" provide a sensible default value, and can optionally be "
"written to. Samplers are not subjects of writing and they are not marked."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:89
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:47
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:48
#, fuzzy
msgid "Global built-ins"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:91
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:49
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:50
msgid "Global built-ins are available everywhere, including custom functions."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:94
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:139
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:191
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:309
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:52
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:110
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:161
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:214
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:53
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:65
msgid "Built-in"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:96
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:311
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:54
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:55
msgid "in float **TIME**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:96
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:55
msgid "Global time, in seconds."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:100
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:59
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:59
msgid "Vertex built-ins"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:102
msgid ""
"Vertex data (``VERTEX``, ``NORMAL``, ``TANGENT``, ``BITANGENT``) are "
"presented in local model space. If not written to, these values will not be "
"modified and be passed through as they came."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:106
msgid ""
"They can optionally be presented in world space by using the "
"*world_vertex_coords* render mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:108
msgid ""
"Users can disable the built-in modelview transform (projection will still "
"happen later) and do it manually with the following code:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:122
msgid ""
"Other built-ins, such as UV, UV2 and COLOR, are also passed through to the "
"fragment function if not modified."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:124
msgid ""
"Users can override the modelview and projection transforms using the "
"``POSITION`` built-in. When ``POSITION`` is used, the value from ``VERTEX`` "
"is ignored and projection does not happen. However, the value passed to the "
"fragment shader still comes from ``VERTEX``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:128
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:102
msgid ""
"For instancing, the INSTANCE_CUSTOM variable contains the instance custom "
"data. When using particles, this information is usually:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:131
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:105
msgid "**x**: Rotation angle in radians."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:132
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:106
msgid "**y**: Phase during lifetime (0 to 1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:133
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:107
msgid "**z**: Animation frame."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:135
msgid ""
"This allows you to easily adjust the shader to a particle system using "
"default particles material. When writing a custom particle shader, this "
"value can be used as desired."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:141
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:193
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:313
msgid "in vec2 **VIEWPORT_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:141
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:193
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:313
msgid "Size of viewport (in pixels)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:143
msgid "inout mat4 **WORLD_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:143
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:198
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:320
msgid "Model space to world space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:145
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:200
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:322
msgid "in mat4 **INV_CAMERA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:145
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:200
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:322
msgid "World space to view space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:147
msgid "inout mat4 **PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:147
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:204
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:326
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:116
msgid "View space to clip space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:149
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:202
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:324
msgid "in mat4 **CAMERA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:149
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:202
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:324
msgid "View space to world space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:151
msgid "inout mat4 **MODELVIEW_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:151
msgid "Model space to view space transform (use if possible)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:153
msgid "inout mat4 **INV_PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:153
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:206
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:328
msgid "Clip space to view space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:155
msgid "inout vec3 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:155
msgid "Vertex in local coordinates."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:157
msgid "out vec4  **POSITION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:157
msgid "If written to, overrides final vertex position."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:159
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:214
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:167
msgid "inout vec3 **NORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:159
msgid "Normal in local coordinates."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:161
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:216
msgid "inout vec3 **TANGENT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:161
msgid "Tangent in local coordinates."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:163
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:218
msgid "inout vec3 **BINORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:163
msgid "Binormal in local coordinates."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:165
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:242
msgid "out float **ROUGHNESS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:165
msgid "Roughness for vertex lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:167
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:128
msgid "inout vec2 **UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:167
msgid "UV main channel."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:169
msgid "inout vec2 **UV2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:169
msgid "UV secondary channel."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:171
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:228
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:342
msgid "in bool **OUTPUT_IS_SRGB**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:171
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:228
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:342
msgid ""
"``true`` when calculations happen in sRGB color space (``true`` in GLES2, "
"``false`` in GLES3)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:174
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:130
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:176
#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:67
msgid "inout vec4 **COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:174
msgid "Color from vertices."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:176
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:136
msgid "inout float **POINT_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:176
msgid "Point size for point rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:178
msgid "in int **INSTANCE_ID**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:178
msgid "Instance ID for instancing."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:180
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:118
msgid "in vec4 **INSTANCE_CUSTOM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:180
msgid "Instance custom data (for particles, mostly)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:184
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:140
msgid "Fragment built-ins"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:186
msgid ""
"The default use of a Godot fragment processor function is to set up the "
"material properties of your object and to let the built-in renderer handle "
"the final shading. However, you are not required to use all these "
"properties, and if you don't write to them, Godot will optimize away the "
"corresponding functionality."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:195
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:315
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:163
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:216
msgid "in vec4 **FRAGCOORD**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:195
msgid ""
"Coordinate of pixel center in screen space. ``xy`` specifies  position in "
"window, ``z`` specifies fragment depth if ``DEPTH`` is not used. Origin is "
"lower-left."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:198
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:320
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:112
msgid "in mat4 **WORLD_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:204
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:326
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:116
msgid "in mat4 **PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:206
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:328
msgid "in mat4 **INV_PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:208
msgid "in vec3 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:208
msgid "Vertex that comes from vertex function (default, in view space)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:210
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:336
msgid "in vec3 **VIEW**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:210
msgid "Vector from camera to fragment position (in view space)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:212
msgid "in bool **FRONT_FACING**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:212
msgid "``true`` if current face is front face."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:214
msgid "Normal that comes from vertex function (default, in view space)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:216
msgid "Tangent that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:218
msgid "Binormal that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:220
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:169
msgid "out vec3 **NORMALMAP**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:220
msgid "Set normal here if reading normal from a texture instead of NORMAL."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:222
msgid "out float **NORMALMAP_DEPTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:222
msgid "Depth from variable above. Defaults to 1.0."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:224
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:332
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:174
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:223
msgid "in vec2 **UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:224
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:332
msgid "UV that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:226
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:334
msgid "in vec2 **UV2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:226
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:334
msgid "UV2 that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:230
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:225
msgid "in vec4 **COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:230
msgid "COLOR that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:232
msgid "out vec3 **ALBEDO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:232
msgid "Albedo (default white)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:234
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:349
msgid "out float **ALPHA**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:234
#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:349
msgid ""
"Alpha (0..1); if written to, the material will go to the transparent "
"pipeline."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:236
msgid "out float **ALPHA_SCISSOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:236
msgid "If written to, values below a certain amount of alpha are discarded."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:238
msgid "out float **METALLIC**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:238
msgid "Metallic (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:240
msgid "out float **SPECULAR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:240
msgid ""
"Specular. Defaults to 0.5, best not to modify unless you want to change IOR."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:242
msgid "Roughness (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:244
msgid "out float **RIM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:244
msgid "Rim (0..1). If used, Godot calculates rim lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:246
msgid "out float **RIM_TINT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:246
msgid ""
"Rim Tint, goes from 0 (white) to 1 (albedo). If used, Godot calculates rim "
"lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:248
msgid "out float **CLEARCOAT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:248
msgid "Small added specular blob. If used, Godot calculates Clearcoat."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:250
msgid "out float **CLEARCOAT_GLOSS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:250
msgid "Gloss of Clearcoat. If used, Godot calculates Clearcoat."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:252
msgid "out float **ANISOTROPY**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:252
msgid "For distorting the specular blob according to tangent space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:254
msgid "out vec2 **ANISOTROPY_FLOW**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:254
msgid "Distortion direction, use with flowmaps."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:256
msgid "out float **SSS_STRENGTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:256
msgid ""
"Strength of Subsurface Scattering. If used, Subsurface Scattering will be "
"applied to object."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:258
msgid "out vec3 **TRANSMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:258
msgid ""
"Transmission mask (default 0,0,0). Allows light to pass through object. Only "
"applied if used."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:260
msgid "out vec3 **EMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:260
msgid "Emission color (can go over 1,1,1 for HDR)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:262
msgid "out float **AO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:262
msgid "Strength of Ambient Occlusion. For use with pre-baked AO."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:264
msgid "out float **AO_LIGHT_AFFECT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:264
msgid "How much AO affects lights (0..1; default 0)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:266
msgid "sampler2D **SCREEN_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:266
msgid ""
"Built-in Texture for reading from the screen. Mipmaps contain increasingly "
"blurred copies."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:268
msgid "sampler2D **DEPTH_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:268
msgid ""
"Built-in Texture for reading depth from the screen. Must convert to linear "
"using INV_PROJECTION."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:270
msgid "out float **DEPTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:270
msgid "Custom depth value (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:272
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:191
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:239
msgid "in vec2 **SCREEN_UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:272
msgid "Screen UV coordinate for current pixel."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:274
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:195
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:241
msgid "in vec2 **POINT_COORD**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:274
msgid "Point Coordinate for drawing points with POINT_SIZE."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:278
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:203
#, fuzzy
msgid "Light built-ins"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:280
msgid ""
"Writing light processor functions is completely optional. You can skip the "
"light function by setting render_mode to ``unshaded``. If no light function "
"is written, Godot will use the material properties written to in the "
"fragment function to calculate the lighting for you (subject to the "
"render_mode)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:285
msgid ""
"To write a light function, assign something to ``DIFFUSE_LIGHT`` or "
"``SPECULAR_LIGHT``. Assigning nothing means no light is processed."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:288
msgid ""
"The light function is called for every light in every pixel. It is called "
"within a loop for each light type."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:291
msgid ""
"Below is an example of a custom light function using a Lambertian lighting "
"model:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:299
msgid ""
"If you want the lights to add together, add the light contribution to "
"``DIFFUSE_LIGHT`` using ``+=``, rather than overwriting it."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:303
#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:97
msgid ""
"The ``light()`` function won't be run if the ``vertex_lighting`` render mode "
"is enabled, or if **Rendering > Quality > Shading > Force Vertex Shading** "
"is enabled in the Project Settings. (It's enabled by default on mobile "
"platforms.)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:311
msgid "Elapsed total time in seconds."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:315
msgid ""
"Coordinate of pixel center in screen space. ``xy`` specifies position in "
"window, ``z`` specifies fragment depth if ``DEPTH`` is not used. Origin is "
"lower-left."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:330
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:220
msgid "in vec3 **NORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:330
msgid "Normal vector, in view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:336
msgid "View vector, in view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:338
msgid "in vec3 **LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:338
msgid "Light Vector, in view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:340
msgid "in vec3 **ATTENUATION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:340
msgid "Attenuation based on distance or shadow."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:345
msgid "in vec3 **ALBEDO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:345
msgid "Base albedo."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:347
msgid "in vec3 **LIGHT_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:347
msgid "Color of light multiplied by energy."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:352
msgid "in float **ROUGHNESS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:352
msgid "Roughness."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:354
msgid "in vec3 **TRANSMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:354
msgid "Transmission mask from fragment function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:356
msgid "out vec3 **DIFFUSE_LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:356
msgid "Diffuse light result."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:358
msgid "out vec3 **SPECULAR_LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/spatial_shader.rst:358
msgid "Specular light result."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:4
msgid "CanvasItem shaders"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:6
msgid ""
"CanvasItem shaders are used to draw all 2D elements in Godot. These include "
"all nodes that inherit from CanvasItems, and all GUI elements."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:9
msgid ""
"CanvasItem shaders contain less built-in variables and functionality than "
"Spatial shaders, but they maintain the same basic structure with vertex, "
"fragment, and light processor functions."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:27
msgid "**blend_premul_alpha**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:27
msgid "Pre-multiplied alpha blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:29
msgid "**blend_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:29
msgid "Disable blending, values (including alpha) are written as-is."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:33
msgid "**light_only**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:33
msgid "Only draw on light pass."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:35
msgid "VERTEX/NORMAL/etc need to be transformed manually in vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:54
msgid ""
"Global time, in seconds. It's subject to the rollover setting (which is "
"3,600 -1 hour- by default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:61
msgid ""
"Vertex data (``VERTEX``) is presented in local space (pixel coordinates, "
"relative to the camera). If not written to, these values will not be "
"modified and be passed through as they came."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:64
msgid ""
"The user can disable the built-in modelview transform (projection will still "
"happen later) and do it manually with the following code:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:77
msgid ""
"``WORLD_MATRIX`` is actually a modelview matrix. It takes input in local "
"space and transforms it into view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:80
msgid ""
"In order to get the world space coordinates of a vertex, you have to pass in "
"a custom uniform like so:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:87
msgid "Then, in your vertex shader:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:98
msgid ""
"``world_position`` can then be used in either the vertex or fragment "
"functions."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:100
msgid ""
"Other built-ins, such as UV and COLOR, are also passed through to the "
"fragment function if not modified."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:112
msgid "Image space to view space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:114
msgid "in mat4 **EXTRA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:114
msgid "Extra transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:118
msgid "Instance custom data."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:120
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:197
msgid "in bool **AT_LIGHT_PASS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:120
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:197
msgid "``true`` if this is a light pass."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:122
msgid "inout vec2 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:122
msgid "Vertex, in image space."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:124
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:187
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:235
msgid "in vec2 **TEXTURE_PIXEL_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:124
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:187
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:235
msgid ""
"Normalized pixel size of default 2D texture. For a Sprite with a texture of "
"size 64x32px, **TEXTURE_PIXEL_SIZE** = :code:`vec2(1/64, 1/32)`"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:128
msgid "UV."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:130
msgid "Color from vertex primitive."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:132
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:179
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:229
msgid "in vec4 **MODULATE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:132
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:179
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:229
msgid ""
"Final modulate color. If used, **COLOR** will not be multiplied by modulate "
"automatically after the fragment function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:136
msgid "Point size for point drawing."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:142
msgid ""
"Certain Nodes (for example, :ref:`Sprites <class_Sprite>`) display a texture "
"by default. However, when a custom fragment function is attached to these "
"nodes, the texture lookup needs to be done manually. Godot does not provide "
"the texture color in the ``COLOR`` built-in variable; to read the texture "
"color for such nodes, use:"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:151
msgid ""
"This differs from the behavior of the built-in normal map. If a normal map "
"is attached, Godot uses it by default and assigns its value to the built-in "
"``NORMAL`` variable. If you are using a normal map meant for use in 3D, it "
"will appear inverted. In order to use it in your shader, you must assign it "
"to the ``NORMALMAP`` property. Godot will handle converting it for use in 2D "
"and overwriting ``NORMAL``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:163
#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:216
msgid ""
"Coordinate of pixel center. In screen space. ``xy`` specifies position in "
"window, ``z`` specifies fragment depth if ``DEPTH`` is not used. Origin is "
"lower-left."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:167
msgid "Normal read from **NORMAL_TEXTURE**. Writable."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:169
msgid ""
"Configures normal maps meant for 3D for use in 2D. If used, overwrites "
"**NORMAL**."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:172
msgid "inout float **NORMALMAP_DEPTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:172
msgid "Normalmap depth for scaling."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:174
msgid "UV from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:176
msgid ""
"Color from vertex function and output fragment color. If unused, will be set "
"to **TEXTURE** color."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:183
msgid "in sampler2D **TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:183
msgid "Default 2D texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:185
msgid "in sampler2D **NORMAL_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:185
msgid "Default 2D normal texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:191
msgid "Screen UV for use with **SCREEN_TEXTURE**."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:193
msgid "in vec2 **SCREEN_PIXEL_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:193
msgid "Size of individual pixels. Equal to inverse of resolution."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:195
msgid "Coordinate for drawing points."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:199
msgid "in sampler2D **SCREEN_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:199
msgid "Screen texture, mipmaps contain gaussian blurred versions."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:205
msgid ""
"Light processor functions work differently in 2D than they do in 3D. In "
"CanvasItem shaders, the shader is called once for the object being drawn, "
"and then once for each light touching that object in the scene. Use "
"render_mode ``unshaded`` if you do not want any light passes to occur for "
"that object. Use render_mode ``light_only`` if you only want light passes to "
"occur for that object; this can be useful when you only want the object "
"visible where it is covered by light."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:211
msgid ""
"When the shader is on a light pass, the ``AT_LIGHT_PASS`` variable will be "
"``true``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:220
msgid ""
"Input Normal. Although this value is passed in, **normal calculation still "
"happens outside of this function**."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:223
msgid "UV from vertex function, equivalent to the UV in the fragment function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:225
msgid ""
"Input Color. This is the output of the fragment function (with final "
"modulation applied, if **MODULATE** is not used in any function of the "
"shader)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:233
msgid "sampler2D **TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:233
msgid "Current texture in use for CanvasItem."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:239
msgid "**SCREEN_TEXTURE** Coordinate (for using with screen texture)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:241
msgid "UV for Point Sprite."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:243
msgid "inout vec2 **LIGHT_VEC**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:243
msgid ""
"Vector from light to fragment in local coordinates. It can be modified to "
"alter illumination direction when normal maps are used."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:246
msgid "inout vec2 **SHADOW_VEC**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:246
msgid ""
"Vector from light to fragment in local coordinates. It can be modified to "
"alter shadow computation."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:249
msgid "inout float **LIGHT_HEIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:249
msgid "Height of Light. Only effective when normals are used."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:251
msgid "inout vec4 **LIGHT_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:251
msgid "Color of Light."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:253
msgid "in vec2 **LIGHT_UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:253
msgid "UV for Light texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:255
msgid "out vec4 **SHADOW_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:255
msgid "Shadow Color of Light."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:257
msgid "inout vec4 **LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/canvas_item_shader.rst:257
msgid ""
"Value from the Light texture and output color. Can be modified. If not used, "
"the light function is ignored."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:4
msgid "Particle shaders"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:6
msgid ""
"Particle shaders are a special type of vertex shader that runs before the "
"object is drawn. They are used for calculating material properties such as "
"color, position, and rotation. They are drawn with any regular material for "
"CanvasItem or Spatial, depending on whether they are 2D or 3D."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:11
msgid ""
"Particle shaders are unique because they are not used to draw the object "
"itself; they are used to calculate particle properties, which are then used "
"by the CanvasItem of Spatial shader. They contain only a vertex processor "
"function that outputs multiple properties (see built-ins below)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:16
msgid ""
"Particle shaders use a transform feedback shader, which is a special type of "
"vertex shader that runs on its own. It takes in data in a buffer like a "
"regular vertex shader does, but it also outputs to data buffers instead of "
"outputting to the fragment shader for pixel-processing. Because of this, "
"transform feedback shaders can build on themselves each run, unlike other "
"shaders that discard the data they have calculated once they draw to the "
"frame buffer."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:23
msgid ""
"Particle shaders are only available in the GLES3 backend. If you need "
"particles in GLES2, use :ref:`CPUParticles <class_CPUParticles>`."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:32
msgid "**keep_data**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:32
msgid "Do not clear previous data on restart."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:34
msgid "**disable_force**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:34
msgid "Disable attractor force. (Not currently implemented in 3.1)"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:36
msgid "**disable_velocity**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:36
msgid "Ignore **VELOCITY** value."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:61
msgid ""
"In order to use the ``COLOR`` variable in a SpatialMaterial, set "
"``use_vertex_as_albedo`` to ``true``. In a ShaderMaterial, access it with "
"the ``COLOR`` variable."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:67
msgid ""
"Particle color, can be written to and accessed in mesh's vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:69
msgid "inout vec3 **VELOCITY**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:69
msgid "Particle velocity, can be modified."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:71
msgid "out float **MASS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:71
msgid "Particle mass, use for attractors (not implemented in 3.1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:73
msgid "inout bool **ACTIVE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:73
msgid "``true`` when Particle is active, can be set to ``false``."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:75
msgid "in bool **RESTART**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:75
msgid "``true`` when particle must restart (lifetime cycled)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:77
msgid "inout vec4 **CUSTOM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:77
msgid ""
"Custom particle data. Accessible from shader of mesh as **INSTANCE_CUSTOM**."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:79
msgid "inout mat4 **TRANSFORM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:79
msgid "Particle transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:81
msgid "in float **LIFETIME**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:81
msgid "Particle lifetime."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:83
msgid "in float **DELTA**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:83
msgid "Delta process time."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:85
msgid "in uint **NUMBER**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:85
msgid "Unique number since emission start."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:87
msgid "in int **INDEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:87
msgid "Particle index (from total particles)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:89
msgid "in mat4 **EMISSION_TRANSFORM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:89
msgid "Emitter transform (used for non-local systems)."
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:91
msgid "in uint **RANDOM_SEED**"
msgstr ""

#: ../../docs/tutorials/shading/shading_reference/particle_shader.rst:91
msgid "Random seed used as base for random."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/index.rst:2
msgid "Your first shader"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/index.rst:4
msgid ""
"This tutorial series will walk you through writing your first shader. It is "
"intended for people who have very little prior experience with shaders and "
"want to get started with the basics. This tutorial will not cover advanced "
"topics and it is not comprehensive. For a comprehensive and detailed "
"overview of shaders in Godot see the :ref:`Shading Reference Page <toc-"
"shading-reference>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/index.rst:10
msgid ""
"\"What are shaders\" gives you a high-level overview of what shaders are and "
"how they fit into the rendering pipeline."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/index.rst:13
msgid ""
"The \"your first shader\" tutorials walk you through the process of writing "
"a shader step-by-step."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/index.rst:16
msgid ""
"For a more general introduction into shaders and the OpenGL Shading "
"Language, use `The Book of Shaders <https://thebookofshaders.com>`_."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:4
msgid "What are shaders?"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:9
msgid ""
"So, you have decided to give shaders a try. You have likely heard that they "
"can be used to create interesting effects that run incredibly fast. You have "
"also likely heard that they are terrifying. Both are true."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:13
msgid ""
"Shaders can be used to create a wide range of effects (in fact everything "
"drawn in a modern rendering engine is done with shaders)."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:16
msgid ""
"Writing shaders can also be very difficult for people unfamiliar with them. "
"Godot tries to make writing shaders a little easier by exposing many useful "
"built-in features and handling some of the lower-level initialization work "
"for you. However, GLSL (the OpenGL Shading Language, which Godot uses) is "
"still unintuitive and restricting, especially for users who are used to "
"GDScript."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:22
msgid "But what are they?"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:24
msgid ""
"Shaders are a special kind of program that runs on Graphics Processing Units "
"(GPUs). Most computers have some sort of GPU, either one integrated into "
"their CPU or discrete (meaning it is a separate hardware component, for "
"example, the typical graphics card). GPUs are especially useful for "
"rendering because they are optimized for running thousands of instructions "
"in parallel."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:29
msgid ""
"The output of the shader is typically the colored pixels of the object drawn "
"to the viewport. But some shaders allow for specialized outputs (this is "
"especially true for APIs like Vulkan). Shaders operate inside the shader "
"pipeline. The standard process is the vertex -> fragment shader pipeline. "
"The vertex shader is used to decided where each vertex (point in a 3D model, "
"or corner of a Sprite) goes and the fragment shader decides what color "
"individual pixels receive."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:35
msgid ""
"Suppose you want to update all the pixels in a texture to a given color, on "
"the CPU you would write:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:43
msgid ""
"In a shader you are given access only to the inside of the loop so what you "
"write looks like this:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:52
msgid ""
"You have no control over how this function is called. So you have to design "
"your shaders differently from how you would design programs on the CPU."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:55
msgid ""
"A consequence of the shader pipeline is that you cannot access the results "
"from a previous run of the shader, you cannot access other pixels from the "
"pixel being drawn, and you cannot write outside of the current pixel being "
"drawn. This enables the GPU to execute the shader for different pixels in "
"parallel, as they do not depend on each other. This lack of flexibility is "
"designed to work with the GPU which allows shaders to be incredibly fast."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:62
msgid "What can they do"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:64
msgid "position vertices very fast"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:65
msgid "compute color very fast"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:66
msgid "compute lighting very fast"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:67
msgid "lots and lots of math"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:70
msgid "What can't they do"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:72
msgid "draw outside mesh"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:73
msgid "access other pixels from current pixel (or vertices)"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:74
msgid "store previous iterations"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:75
msgid "update on the fly (they can, but they need to be compiled)"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:78
msgid "Structure of a shader"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:80
msgid ""
"In Godot, shaders are made up of 3 main functions: the ``vertex()`` "
"function, the ``fragment()`` function and the ``light()`` function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:83
msgid ""
"The ``vertex()`` function runs over all the vertices in the mesh and sets "
"their positions as well as some other per-vertex variables."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:86
msgid ""
"The ``fragment()`` function runs for every pixel that is covered by the "
"mesh. It uses the variables from the ``vertex()`` function to run. The "
"variables from the ``vertex()`` function are interpolated between the "
"vertices to provide the values for the ``fragment()`` function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:90
msgid ""
"The ``light()`` function runs for every pixel and for every light. It takes "
"variables from the ``fragment()`` function and from previous runs of itself."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:93
msgid ""
"For more information about how shaders operate specifically in Godot, see "
"the :ref:`Shaders <doc_shaders>` doc."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:103
msgid "Technical overview"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:105
msgid ""
"GPUs are able to render graphics much faster than CPUs for a few reasons, "
"but most notably, because they are able to run calculations massively in "
"parallel. A CPU typically has 4 or 8 cores while a GPU typically has "
"thousands. That means a GPU can do hundreds of tasks at once. GPU architects "
"have exploited this in a way that allows for doing many calculations very "
"quickly, but only when many or all cores are doing the same calculation at "
"once, but with different data."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:111
msgid ""
"That is where shaders come in. The GPU will call the shader a bunch of times "
"simultaneously, and then operate on different bits of data (vertices, or "
"pixels). These bunches of data are often called wavefronts. A shader will "
"run the same for every thread in the wavefront. For example, if a given GPU "
"can handle 100 threads per wavefront, a wavefront will run on a 10×10 block "
"of pixels together. It will continue to run for all pixels in that wavefront "
"until they are complete. Accordingly, if you have one pixel slower than the "
"rest (due to excessive branching), the entire block will be slowed down, "
"resulting in massively slower render times."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/what_are_shaders.rst:119
msgid ""
"This is different from CPU-based operations. On a CPU, if you can speed up "
"even one pixel, the entire rendering time will decrease. On a GPU, you have "
"to speed up the entire wavefront to speed up rendering."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:4
#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:51
msgid "Your first CanvasItem shader"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:9
msgid ""
"Shaders are special programs that execute on the GPU and are used for "
"rendering graphics. All modern rendering is done with shaders. For a more "
"detailed description of what shaders are please see :ref:`What are shaders "
"<doc_what_are_shaders>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:13
msgid ""
"This tutorial will focus on the practical aspects of writing shader programs "
"by walking you through the process of writing a shader with both vertex and "
"fragment functions. This tutorial targets absolute beginners to shaders."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:17
msgid ""
"If you have experience writing shaders and are just looking for an overview "
"of how shaders work in Godot, see the :ref:`Shading Reference <toc-shading-"
"reference>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:23
msgid ""
":ref:`CanvasItem <doc_canvas_item_shader>` shaders are used to draw all 2D "
"objects in Godot, while :ref:`Spatial <doc_spatial_shader>` shaders are used "
"to draw all 3D objects."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:26
msgid ""
"In order to use a shader it must be attached inside a :ref:`Material "
"<class_material>` which must be attached to an object. Materials are a type "
"of :ref:`Resource <doc_resources>`. To draw multiple objects with the same "
"material, the material must be attached to each object."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:30
msgid ""
"All objects derived from a :ref:`CanvasItem <class_canvasitem>` have a "
"material property. This includes all :ref:`GUI elements <class_Control>`, :"
"ref:`Sprites <class_sprite>`, :ref:`TileMaps <class_tilemap>`, :ref:"
"`MeshInstance2Ds <class_meshinstance2d>` etc. They also have an option to "
"inherit their parent's material. This can be useful if you have a large "
"number of nodes that you want to use the same material."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:36
msgid ""
"To begin, create a Sprite node. You can use any CanvasItem, but for this "
"tutorial we will use a Sprite."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:39
msgid ""
"In the Inspector, click beside \"Texture\" where it says \"[empty]\" and "
"select \"Load\", then select \"Icon.png\". For new projects, this is the "
"Godot icon. You should now see the icon in the viewport."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:42
msgid ""
"Next, look down in the Inspector, under the CanvasItem section, click beside "
"\"Material\" and select \"New ShaderMaterial\". This creates a new Material "
"resource. Click on the sphere that appears. Godot currently doesn't know "
"whether you are writing a CanvasItem Shader or a Spatial Shader and it "
"previews the output of spatial shaders. So what you are seeing is the output "
"of the default Spatial Shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:47
msgid ""
"Click beside \"Shader\" and select \"New Shader\". Finally, click on the new "
"shader resource and the shader editor will open. You are now ready to begin "
"writing your first shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:53
msgid ""
"In Godot, all shaders start with a line specifying what type of shader they "
"are. It uses the following format:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:60
msgid ""
"Because we are writing a CanvasItem shader, we specify ``canvas_item`` in "
"the first line. All our code will go beneath this declaration."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:63
msgid ""
"This line tells the engine which built-in variables and functionality to "
"supply you with."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:65
msgid ""
"In Godot you can override three functions to control how the shader "
"operates; ``vertex``, ``fragment``, and ``light``. This tutorial will walk "
"you through writing a shader with both vertex and fragment functions. Light "
"functions are significantly more complex than vertex and fragment functions "
"and so will not be covered here."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:70
msgid "Your first fragment function"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:72
msgid ""
"The fragment function runs for every pixel in a Sprite and determines what "
"color that pixel should be."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:74
msgid ""
"They are restricted to the pixels covered by the Sprite, that means you "
"cannot use one to, for example, create an outline around a Sprite."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:77
msgid ""
"The most basic fragment function does nothing except assign a single color "
"to every pixel."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:79
msgid ""
"We do so by writing a ``vec4`` to the built-in variable ``COLOR``. ``vec4`` "
"is shorthand for constructing a vector with 4 numbers. For more information "
"about vectors see the :ref:`Vector math tutorial <doc_vector_math>` "
"``COLOR`` is both an input variable to the fragment function and the final "
"output from it."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:91
msgid ""
"Congratulations! You're done. You have successfully written your first "
"shader in Godot."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:93
msgid "Now let's make things more complex."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:95
msgid ""
"There are many inputs to the fragment function that you can use for "
"calculating ``COLOR``. ``UV`` is one of them. UV coordinates are specified "
"in your Sprite (without you knowing it!) and they tell the shader where to "
"read from textures for each part of the mesh."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:99
msgid ""
"In the fragment function you can only read from ``UV``, but you can use it "
"in other functions or to assign values to ``COLOR`` directly."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:102
msgid "``UV`` varies between 0-1 from left-right and from top-bottom."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:115
msgid "Using ``TEXTURE`` built-in"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:117
msgid ""
"When you want to adjust a color in a Sprite you cannot just adjust the color "
"from the texture manually like in the code below."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:127
msgid ""
"The default fragment function reads from a texture and displays it. When you "
"overwrite the default fragment function, you lose that functionality, so you "
"have to implement it yourself. You read from textures using the ``texture`` "
"function. Certain nodes, like Sprites, have a dedicated texture variable "
"that can be accessed in the shader using ``TEXTURE``. Use it together with "
"``UV`` and ``texture`` to draw the Sprite."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:142
msgid "Uniform input"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:144
msgid ""
"Uniform input is used to pass data into a shader that will be the same "
"across the entire shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:146
msgid ""
"You can use uniforms by defining them at the top of your shader like so:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:152
msgid ""
"For more information about usage see the :ref:`Shading Language doc "
"<doc_shading_language>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:154
msgid "Add a uniform to change the amount of blue in our Sprite."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:165
msgid ""
"Now you can change the amount of blue in the Sprite from the editor. Look "
"back at the Inspector under where you created your shader. You should see a "
"section called \"Shader Param\". Unfold that section and you will see the "
"uniform you just declared. If you change the value in the editor, it will "
"overwrite the default value you provided in the shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:171
msgid "Interacting with shaders from code"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:173
msgid ""
"You can change uniforms from code using the function ``set_shader_param()`` "
"which is called on the node's material resource. With a Sprite node, the "
"following code can be used to set the ``blue`` uniform."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:181
msgid ""
"Note that the name of the uniform is a string. The string must match exactly "
"with how it is written in the shader, including spelling and case."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:185
msgid "Your first vertex function"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:187
msgid "Now that we have a fragment function, let's write a vertex function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:189
msgid ""
"Use the vertex function to calculate where on the screen each vertex should "
"end up."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:191
msgid ""
"The most important variable in the vertex function is ``VERTEX``. Initially, "
"it specifies the vertex coordinates in your model, but you also write to it "
"to determine where to actually draw those vertices. ``VERTEX`` is a ``vec2`` "
"that is initially presented in local-space (i.e. not relative to the camera, "
"viewport, or parent nodes)."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:196
msgid "You can offset the vertices by directly adding to ``VERTEX``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:204
msgid ""
"Combined with the ``TIME`` built-in variable, this can be used for simple "
"animation."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:216
msgid ""
"At their core, shaders do what you have seen so far, they compute ``VERTEX`` "
"and ``COLOR``. It is up to you to dream up more complex mathematical "
"strategies for assigning values to those variables."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_canvasitem_shader.rst:219
msgid ""
"For inspiration, take a look at some of the more advanced shader tutorials, "
"and look at other sites like `Shadertoy <https://www.shadertoy.com/results?"
"query=&sort=popular&from=10&num=4>`_ and `The Book of Shaders <https://"
"thebookofshaders.com>`_."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:4
msgid "Your first Spatial shader"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:6
msgid ""
"You have decided to start writing your own custom Spatial shader. Maybe you "
"saw a cool trick online that was done with shaders, or you have found that "
"the :ref:`SpatialMaterial <class_SpatialMaterial>` isn't quite meeting your "
"needs. Either way, you have decided to write your own and now you need "
"figure out where to start."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:11
msgid ""
"This tutorial will explain how to write a Spatial shader and will cover more "
"topics than the :ref:`CanvasItem <doc_your_first_canvasitem_shader>` "
"tutorial."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:14
msgid ""
"Spatial shaders have more built-in functionality than CanvasItem shaders. "
"The expectation with spatial shaders is that Godot has already provided the "
"functionality for common use cases and all the user needs to do in the "
"shader is set the proper parameters. This is especially true for a PBR "
"(physically based rendering) workflow."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:19
msgid ""
"This is a two-part tutorial. In this first part we are going to go through "
"how to make a simple terrain using vertex displacement from a heightmap in "
"the vertex function. In the :ref:`second part "
"<doc_your_second_spatial_shader>` we are going to take the concepts from "
"this tutorial and walk through how to set up custom materials in a fragment "
"shader by writing an ocean water shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:24
msgid ""
"This tutorial assumes some basic shader knowledge such as types (``vec2``, "
"``float``, ``sampler2D``), and functions. If you are uncomfortable with "
"these concepts it is best to get a gentle introduction from `The Book of "
"Shaders <https://thebookofshaders.com>`_ before completing this tutorial."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:30
msgid "Where to assign my material"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:32
msgid ""
"In 3D, objects are drawn using :ref:`Meshes <class_Mesh>`. Meshes are a "
"resource type that store geometry (the shape of your object) and materials "
"(the color and how the object reacts to light) in units called \"surfaces\". "
"A Mesh can have multiple surfaces, or just one. Typically, you would import "
"a mesh from another program (e.g. Blender). But Godot also has a few :ref:"
"`PrimitiveMeshes <class_primitivemesh>` that allow you to add basic geometry "
"to a scene without importing Meshes."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:38
msgid ""
"There are multiple node types that you can use to draw a mesh. The main one "
"is :ref:`MeshInstance <class_meshinstance>`, but you can also use :ref:"
"`Particles <class_particles>`, :ref:`MultiMeshes <class_MultiMesh>` (with a :"
"ref:`MultiMeshInstance <class_multimeshinstance>`), or others."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:42
msgid ""
"Typically, a material is associated with a given surface in a mesh, but some "
"nodes, like MeshInstance, allow you to override the material for a specific "
"surface, or for all surfaces."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:45
msgid ""
"If you set a material on the surface or mesh itself, then all MeshInstances "
"that share that mesh will share that material. However, if you want to reuse "
"the same mesh across multiple mesh instances, but have different materials "
"for each instance then you should set the material on the Meshinstance."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:49
msgid ""
"For this tutorial we will set our material on the mesh itself rather than "
"taking advantage of the MeshInstance's ability to override materials."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:55
msgid "Add a new :ref:`MeshInstance <class_meshinstance>` node to your scene."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:57
msgid ""
"In the inspector tab beside \"Mesh\" click \"[empty]\" and select \"New "
"PlaneMesh\". Then click on the image of a plane that appears."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:60
msgid "This adds a :ref:`PlaneMesh <class_planemesh>` to our scene."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:62
msgid ""
"Then, in the viewport, click in the upper left corner on the button that "
"says \"Perspective\". A menu will appear. In the middle of the menu are "
"options for how to display the scene. Select 'Display Wireframe'."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:66
msgid "This will allow you to see the triangles making up the plane."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:70
msgid "Now set ``Subdivide Width`` and ``Subdivide Depth`` to ``32``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:74
msgid ""
"You can see that there are now many more triangles in the :ref:"
"`Mesh<class_MeshInstance>`. This will give us more vertices to work with and "
"thus allow us to add more detail."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:79
msgid ""
":ref:`PrimitiveMeshes <class_primitivemesh>`, like PlaneMesh, only have one "
"surface, so instead of an array of materials there is only one. Click beside "
"\"Material\" where it says \"[empty]\" and select \"New ShaderMaterial\". "
"Then click the sphere that appears."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:83
msgid ""
"Now click beside \"Shader\" where it says \"[empty]\" and select \"New Shader"
"\"."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:85
msgid ""
"The shader editor should now pop up and you are ready to begin writing your "
"first Spatial shader!"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:88
msgid "Shader magic"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:92
msgid ""
"Notice how there is already error? This is because the shader editor reloads "
"shaders on the fly. The first thing Godot shaders need is a declaration of "
"what type of shader they are. We set the variable ``shader_type`` to "
"``spatial`` because this is a spatial shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:100
msgid ""
"Next we will define the ``vertex()`` function. The ``vertex()`` function "
"determines where the vertices of your :ref:`Mesh<class_MeshInstance>` appear "
"in the final scene. We will be using it to offset the height of each vertex "
"and make our flat plane appear like a little terrain."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:104
msgid "We define the vertex shader like so:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:112
msgid ""
"With nothing in the ``vertex()`` function, Godot will use its default vertex "
"shader. We can easily start to make changes by adding a single line:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:121
msgid "Adding this line, you should get an image like the one below."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:125
msgid ""
"Okay, let's unpack this. The ``y`` value of the ``VERTEX`` is being "
"increased. And we are passing the ``x`` and ``z`` components of the "
"``VERTEX`` as arguments to ``cos`` and ``sin``; that gives us a wave-like "
"appearance across the ``x`` and ``z`` axes."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:129
msgid ""
"What we want to achieve is the look of little hills; after all. ``cos`` and "
"``sin`` already look kind of like hills. We do so by scaling the inputs to "
"the ``cos`` and ``sin`` functions."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:140
msgid ""
"This looks better, but it is still too spiky and repetitive, let's make it a "
"little more interesting."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:143
msgid "Noise heightmap"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:145
msgid ""
"Noise is a very popular tool for faking the look of terrain. Think of it as "
"similar to the cosine function where you have repeating hills except, with "
"noise, each hill has a different height."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:148
msgid ""
"Godot provides the :ref:`NoiseTexture <class_noisetexture>` resource for "
"generating a noise texture that can be accessed from a shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:151
msgid ""
"To access a texture in a shader add the following code near the top of your "
"shader, outside the ``vertex()`` function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:158
msgid ""
"This will allow you to send a noise texture to the shader. Now look in the "
"inspecter under your material. You should see a section called \"Shader "
"Params\". If you open it up, you'll see a section called \"noise\"."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:161
msgid ""
"Click beside it where it says \"[empty]\" and select \"New NoiseTexture\". "
"Then in your NoiseTexture click beside where it says \"Noise\" and select "
"\"New OpenSimplexNoise\"."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:164
msgid ""
":ref:`OpenSimplexNoise <class_opensimplexnoise>` is used by the NoiseTexture "
"to generate a heightmap."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:166
msgid "Once you set it up and should look like this."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:170
msgid ""
"Now, access the noise texture using the ``texture()`` function. "
"``texture()`` takes a texture as the first argument and a ``vec2`` for the "
"position on the texture as the second argument. We use the ``x`` and ``z`` "
"channels of ``VERTEX`` to determine where on the texture to look up. "
"``texture()`` returns a ``vec4`` of the ``r, g, b, a`` channels at the "
"position. Since the noise texture is grayscale, all of the values are the "
"same, so we can use any one of the channels as the height. In this case "
"we'll use the ``r``, or ``x`` channel."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:181
msgid ""
"Note: ``xyzw`` is the same as ``rgba`` in GLSL, so instead of ``texture()."
"x`` above, we could use ``texture().r``. See the `OpenGL documentation "
"<https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Vectors>`_ for more "
"details."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:184
msgid "Using this code you can see the texture creates random looking hills."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:188
msgid ""
"Right now it is too spiky, we want to soften the hills a bit. To do that, we "
"will use a uniform. You already used a uniform above to pass in the noise "
"texture, now let's learn how they work."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:194
msgid ""
"Uniform variables allow you to pass data from the game into the shader. They "
"are very useful for controlling shader effects. Uniforms can be almost any "
"datatype that can be used in the shader. To use a uniform, you declare it in "
"your :ref:`Shader<class_Shader>` using the keyword ``uniform``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:199
msgid "Let's make a uniform that changes the height of the terrain."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:206
msgid ""
"Godot lets you initialize a uniform with a value; here, ``height_scale`` is "
"set to ``0.5``. You can set uniforms from GDScript by calling the function "
"``set_shader_param()`` on the material corresponding to the shader. The "
"value passed from GDScript takes precedence over the value used to "
"initialize it in the shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:216
msgid ""
"Changing uniforms in Spatial-based nodes is different from CanvasItem-based "
"nodes. Here, we set the material inside the PlaneMesh resource. In other "
"mesh resources you may need to first access the material by calling "
"``surface_get_material()``. While in the MeshInstance you would access the "
"material using ``get_surface_material()`` or ``material_override``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:222
msgid ""
"Remember that the string passed into ``set_shader_param()`` must match the "
"name of the uniform variable in the :ref:`Shader<class_Shader>`. You can use "
"the uniform variable anywhere inside your :ref:`Shader<class_Shader>`. Here, "
"we will use it to set the height value instead of arbitrarily multiplying by "
"``0.5``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:231
msgid "Now it looks  much better."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:235
msgid ""
"Using uniforms, we can even change the value every frame to animate the "
"height of the terrain. Combined with :ref:`Tweens <class_Tween>`, this can "
"be especially useful for simple animations."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:239
msgid "Interacting with light"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:241
msgid ""
"First, turn wireframe off. To do so, click in the upper-left of the Viewport "
"again, where it says \"Perspective\", and select \"Display Normal\"."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:246
msgid ""
"Note how the mesh color goes flat. This is because the lighting on it is "
"flat. Let's add a light!"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:248
msgid "First, we will add an :ref:`OmniLight<class_OmniLight>` to the scene."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:252
msgid ""
"You can see the light affecting the terrain, but it looks odd. The problem "
"is the light is affecting the terrain as if it were a flat plane. This is "
"because the light shader uses the normals from the :ref:`Mesh <class_mesh>` "
"to calculate light."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:256
msgid ""
"The normals are stored in the Mesh, but we are changing the shape of the "
"Mesh in the shader, so the normals are no longer correct. To fix this, we "
"can recalculate the normals in the shader or use a normal texture that "
"corresponds to our noise. Godot makes both easy for us."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:260
msgid ""
"You can calculate the new normal manually in the vertex function and then "
"just set ``NORMAL``. With ``NORMAL`` set, Godot will do all the difficult "
"lighting calculations for us. We will cover this method in the next part of "
"this tutorial, for now we will read normals from a texture."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:264
msgid ""
"Instead we will rely on the NoiseTexture again to calculate normals for us. "
"We do that by passing in a second noise texture."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:271
msgid ""
"Set this second uniform texture to another NoiseTexture with another "
"OpenSimplexNoise. But this time, check off \"As Normalmap\"."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:276
msgid ""
"Now, because this is a normalmap and not a per-vertex normal, we are going "
"to assign it in the ``fragment()`` function. The ``fragment()`` function "
"will be explained in more detail in the next part of this tutorial."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:284
msgid ""
"When we have normals that correspond to a specific vertex we set ``NORMAL``, "
"but if you have a normalmap that comes from a texture, set the normal using "
"``NORMALMAP``. This way Godot will handle the wrapping the texture around "
"the mesh automatically."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:288
msgid ""
"Lastly, in order to ensure that we are reading from the same places on the "
"noise texture and the normalmap texture, we are going to pass the ``VERTEX."
"xz`` position from the ``vertex()`` function to the ``fragment()`` function. "
"We do that with varyings."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:292
msgid ""
"Above the ``vertex()`` define a ``vec2`` called ``vertex_position``. And "
"inside the ``vertex()`` function assign ``VERTEX.xz`` to ``vertex_position``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:304
msgid ""
"And now we can access ``vertex_position`` from the ``fragment()`` function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:312
msgid ""
"With the normals in place the light now reacts to the height of the mesh "
"dynamically."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:316
msgid ""
"We can even drag the light around and the lighting will update automatically."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:320
msgid ""
"Here is the full code for this tutorial. You can see it is not very long as "
"Godot handles most of the difficult stuff for you."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_first_spatial_shader.rst:343
msgid ""
"That is everything for this part. Hopefully, you now understand the basics "
"of vertex shaders in Godot. In the next part of this tutorial we will write "
"a fragment function to accompany this vertex function and we will cover a "
"more advanced technique to turn this terrain into an ocean of moving waves."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:4
msgid "Your first Spatial shader: part 2"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:6
msgid ""
"From a high-level, what Godot does is give the user a bunch of parameters "
"that can be optionally set (``AO``, ``SSS_Strength``, ``RIM``, etc.). These "
"parameters correspond to different complex effects (Ambient Occlusion, "
"SubSurface Scattering, Rim Lighting, etc.). When not written to, the code is "
"thrown out before it is compiled and so the shader does not incur the cost "
"of the extra feature. This makes it easy for users to have complex PBR-"
"correct shading, without writing complex shaders. Of course, Godot also "
"allows you to ignore all these parameters and write a fully customized "
"shader."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:13
msgid ""
"For a full list of these parameters see the :ref:`spatial shader "
"<doc_spatial_shader>` reference doc."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:15
msgid ""
"A difference between the vertex function and a fragment function is that the "
"vertex function runs per vertex and sets properties such as ``VERTEX`` "
"(position) and ``NORMAL``, while the fragment shader runs per pixel and, "
"most importantly, sets the ``ALBEDO`` color of the :ref:"
"`Mesh<class_MeshInstance>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:20
msgid "Your first spatial fragment function"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:22
msgid ""
"As mentioned in the previous part of this tutorial. The standard use of the "
"fragment function in Godot is to set up different material properties and "
"let Godot handle the rest. In order to provide even more flexibility, Godot "
"also provides things called render modes. Render modes are set at the top of "
"the shader, directly below ``shader_type``, and they specify what sort of "
"functionality you want the built-in aspects of the shader to have."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:28
msgid ""
"For example, if you do not want to have lights affect an object, set the "
"render mode to ``unshaded``:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:35
msgid ""
"You can also stack multiple render modes together. For example, if you want "
"to use toon shading instead of more-realistic PBR shading, set the diffuse "
"mode and specular mode to toon:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:42
msgid ""
"This model of built-in functionality allows you to write complex custom "
"shaders by changing only a few parameters."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:45
msgid ""
"For a full list of render modes see the :ref:`Spatial shader reference "
"<doc_spatial_shader>`."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:47
msgid ""
"In this part of the tutorial, we will walk through how to take the bumpy "
"terrain from the previous part and turn it into an ocean."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:50
msgid ""
"First let's set the color of the water. We do that by setting ``ALBEDO``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:52
msgid "``ALBEDO`` is a ``vec3`` that contains the color of the object."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:54
msgid "Let's set it to a nice shade of blue."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:64
msgid ""
"We set it to a very dark shade of blue because most of the blueness of the "
"water will come from reflections from the sky."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:67
msgid ""
"The PBR model that Godot uses relies on two main parameters: ``METALLIC`` "
"and ``ROUGHNESS``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:69
msgid ""
"``ROUGHNESS`` specifies how smooth/rough the surface of a material is. A low "
"``ROUGHNESS`` will make a material appear like a shiny plastic, while a high "
"roughness makes the material appear more solid in color."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:73
msgid ""
"``METALLIC`` specifies how much like a metal the object is. It is better set "
"close to ``0`` or ``1``. Think of ``METALLIC`` as changing the balance "
"between the reflection and the ``ALBEDO`` color. A high ``METALLIC`` almost "
"ignores ``ALBEDO`` altogether, and looks like a mirror of the sky. While a "
"low ``METALLIC`` has a more equal representation of sky color and ``ALBEDO`` "
"color."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:78
msgid ""
"``ROUGHNESS`` increases from ``0`` to ``1`` from left to right while "
"``METALLIC`` increase from ``0`` to ``1`` from top to bottom."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:83
msgid ""
"``METALLIC`` should be close to ``0`` or ``1`` for proper PBR shading. Only "
"set it between them for blending between materials."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:86
msgid ""
"Water is not a metal, so we will set its ``METALLIC`` property to ``0.0``. "
"Water is also highly reflective, so we will set its ``ROUGHNESS`` property "
"to be quite low as well."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:99
msgid ""
"Now we have a smooth plastic looking surface. It is time to think about some "
"particular properties of water that we want to emulate. There are two main "
"ones that will take this from a weird plastic surface to nice stylized "
"water. The first is specular reflections. Specular reflections are those "
"bright spots you see from where the sun reflects directly into your eye. The "
"second is fresnel reflectance. Fresnel reflectance is the property of "
"objects to become more reflective at shallow angles. It is the reason why "
"you can see into water below you, but farther away it reflects the sky."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:106
msgid ""
"In order to increase the specular reflections, we will do two things. First, "
"we will change the render mode for specular to toon because the toon render "
"mode has larger specular highlights."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:115
msgid ""
"Second we will add rim lighting. Rim lighting increases the effect of light "
"at glancing angles. Usually it is used to emulate the way light passes "
"through fabric on the edges of an object, but we will use it here to help "
"achieve a nice watery effect."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:131
msgid ""
"In order to add fresnal reflectance, we will compute a fresnel term in our "
"fragment shader. Here, we aren't going to use a real fresnel term for "
"performance reasons. Instead, we'll approximate it using the dot product of "
"the ``NORMAL`` and ``VIEW`` vectors. The ``NORMAL`` vector points away from "
"the mesh's surface, while the ``VIEW`` vector is the direction between your "
"eye and that point on the surface. The dot product between them is a handy "
"way to tell when you are looking at the surface head-on or at a glancing "
"angle."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:143
msgid ""
"And mix it into both ``ROUGHNESS`` and ``ALBEDO``. This is the benefit of "
"ShaderMaterials over SpatialMaterials. With SpatialMaterials, we could set "
"these properties with a texture, or to a flat number. But with shaders we "
"can set them based on any mathematical function that we can dream up."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:160
msgid ""
"And now, with only 5 lines of code, you can have complex looking water. Now "
"that we have lighting, this water is looking too bright. Let's darken it. "
"This is done easily by decreasing the values of the ``vec3`` we pass into "
"``ALBEDO``. Let's set them to ``vec3(0.01, 0.03, 0.05)``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:168
msgid "Animating with ``TIME``"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:170
msgid ""
"Going back to the vertex function, we can animate the waves using the built-"
"in variable ``TIME``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:172
msgid ""
"``TIME`` is a built-in variable that is accessible from the vertex and "
"fragment functions."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:175
msgid ""
"In the last tutorial we calculated height by reading from a heightmap. For "
"this tutorial, we will do the same. Put the heightmap code in a function "
"called ``height()``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:184
msgid ""
"In order to use ``TIME`` in the ``height()`` function, we need to pass it in."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:191
msgid "And make sure to correctly pass it in inside the vertex function."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:201
msgid ""
"Instead of using a normalmap to calculate normals. We are going to compute "
"them manually in the ``vertex()`` function. To do so use the following line "
"of code."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:208
msgid ""
"We need to compute ``NORMAL`` manually because in the next section we will "
"be using math to create complex-looking waves."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:211
msgid ""
"Now, we are going to make the ``height()`` function a little more "
"complicated by offsetting ``position`` by the cosine of ``TIME``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:221
msgid ""
"This results in waves that move slowly, but not in a very natural way. The "
"next section will dig deeper into using shaders to create more complex "
"effects, in this case realistic waves, by adding a few more mathematical "
"functions."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:226
msgid "Advanced effects: waves"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:228
msgid ""
"What makes shaders so powerful is that you can achieve complex effects by "
"using math. To illustrate this, we are going to take our waves to the next "
"level by modifying the ``height()`` function and by introducing a new "
"function called ``wave()``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:232
msgid ""
"``wave()`` has one parameter, ``position``, which is the same as it is in "
"``height()``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:234
msgid ""
"We are going to call ``wave()`` multiple times in ``height()`` in order to "
"fake the way waves look."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:244
msgid "At first this looks complicated. So let's go through it line-by-line."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:250
msgid ""
"Offset the position by the ``noise`` texture. This will make the waves "
"curve, so they won't be straight lines completely aligned with the grid."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:257
msgid ""
"Define a wave-like function using ``sin()`` and ``position``. Normally "
"``sin()`` waves are very round. We use ``abs()`` to absolute to give them a "
"sharp ridge and constrain them to the 0-1 range. And then we subtract it "
"from ``1.0`` to put the peak on top."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:265
msgid ""
"Multiply the x-directional wave by the y-directional wave and raise it to a "
"power to sharpen the peaks. Then subtract that from ``1.0`` so that the "
"ridges become peaks and raise that to a power to sharpen the ridges."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:269
msgid ""
"We can now replace the contents of our ``height()`` function with ``wave()``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:277
msgid "Using this you get:"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:281
msgid ""
"The shape of the sin wave is too obvious. So let's spread the waves out a "
"bit. We do this by scaling ``position``."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:289
msgid "Now it looks much better."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:293
msgid ""
"We can do even better if we layer multiple waves on top of each other at "
"varying frequencies and amplitudes. What this means is that we are going to "
"scale position for each one to make the waves thinner or wider (frequency). "
"And we are going to multiply the output of the wave to make them shorter or "
"taller (amplitude)."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:298
msgid ""
"Here is an example for how you could layer the four waves to achieve nicer "
"looking waves."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:310
msgid ""
"Note that we add time to two and subtract it from the other two. This makes "
"the waves move in different directions creating a complex effect. Also note "
"that the amplitudes (the number the result is multiplied by) all add up to "
"``1.0``. This keeps the wave in the 0-1 range."
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:314
msgid ""
"With this code you should end up with more complex looking waves and all you "
"had to do was add a bit of math!"
msgstr ""

#: ../../docs/tutorials/shading/your_first_shader/your_second_spatial_shader.rst:319
msgid ""
"For more information about Spatial shaders read the :ref:`Shading Language "
"<doc_shading_language>` doc and the :ref:`Spatial Shaders "
"<doc_spatial_shader>` doc. Also look at more advanced tutorials in the :ref:"
"`Shading section <toc-learn-features-shading>` and the :ref:`3D <toc-learn-"
"features-3d>` sections."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:4
msgid "Shader materials"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:9
msgid ""
"For the most common cases, Godot provides ready to use materials for most "
"types of shaders, such as :ref:`SpatialMaterial <class_SpatialMaterial>`, :"
"ref:`CanvasItemMaterial <class_CanvasItemMaterial>` and :ref:"
"`ParticlesMaterial <class_ParticlesMaterial>`. They are flexible "
"implementations that cover most use cases."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:14
msgid ""
"Shader materials allow writing a custom shader directly, for maximum "
"flexibility. Examples of this are:"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:17
msgid "Create procedural textures."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:18
msgid "Create complex texture blending effects."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:19
msgid "Create animated materials, or materials that change over time."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:20
msgid "Create refractive effects or other advanced effects."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:21
msgid "Create special lighting shaders for more exotic materials."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:22
msgid "Animate vertices, like tree leaves or grass."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:23
msgid "Create custom particle code."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:26
msgid ""
"Godot provides built in functionality to make frequent operations easier. "
"Additionally, Godot's shader editor will detect errors as you type, so you "
"can see your edited shaders in real-time. It is also possible to edit "
"shaders using a visual, node-based graph editor."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:32
msgid "Creating a ShaderMaterial"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:34
msgid ""
"Create a new ShaderMaterial in some object of your choice. Go to the "
"\"Material\" property and create a ShaderMaterial."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:39
msgid ""
"Next, click on the shader material to see its properties. From here you can "
"create a shader or visual shader. Regular shaders use code to set their "
"properties while a visual shader uses a node based workflow."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:43
msgid ""
"If you need to you can convert a visual shader to a text shader. However you "
"can't convert a text shader to a visual shader."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:46
msgid "Choose one of them and you can start editing your shader."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:50
msgid ""
"If you create a regular shader click on it and the shader editor will open."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:54
msgid ""
"If you create a visual shader the visual shader editor will open "
"automatically."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:58
msgid ""
"In the visual shader editor you can click a button and see what your visual "
"shader looks like as shader code. This can be useful if you're trying to "
"replicate a text shader as nodes, or it can be used as a preview for "
"converting your visual shader to a text shader."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:67
msgid "To learn more about visual shaders, read :ref:`doc_visual_shaders`."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:70
msgid "Converting to ShaderMaterial"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:72
msgid ""
"It is possible to convert from SpatialMaterial, CanvasItemMaterial and "
"ParticlesMaterial to ShaderMaterial. To do so, go to the material properties "
"and select the convert option."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:80
msgid ""
"Using the convert option will turn the SpatialMaterial into a ShaderMaterial "
"with a text shader, not a visual shader."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:4
#, fuzzy
msgid "VisualShaders"
msgstr "Android"

#: ../../docs/tutorials/shading/visual_shaders.rst:6
msgid ""
"Just as VisualScript is an alternative for users that prefer a graphical "
"approach to coding, VisualShaders are the visual alternative for creating "
"shaders."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:10
msgid ""
"As shaders are inherently linked to visuals, the graph-based approach with "
"previews of textures, materials, etc. offers a lot of additional convenience "
"compared to purely script-based shaders. On the other hand, VisualShaders do "
"not expose all features of the shader script and using both in parallel "
"might be necessary for specific effects."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:18
msgid ""
"If you are not familiar with shaders, start by reading :ref:"
"`doc_what_are_shaders`."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:22
#, fuzzy
msgid "Creating a VisualShader"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/shading/visual_shaders.rst:24
msgid ""
"VisualShaders can be created in any :ref:`class_ShaderMaterial`. To begin "
"using VisualShaders, create a new ``ShaderMaterial`` in an object of your "
"choice."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:29
msgid ""
"Then assign a :ref:`class_VisualShader` resource to the ``Shader`` property."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:33
msgid ""
"Click on the new ``VisualShader`` resource and the Visual Shader Editor will "
"open automatically. The layout of the Visual Shader Editor comprises two "
"parts: the upper toolbar and the graph itself."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:39
msgid "From left to right in the toolbar:"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:41
msgid ""
"The ``Add Node`` button displays a popup menu to let you add nodes to the "
"shader graph."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:43
msgid ""
"The drop-down menu is the shader type: Vertex, Fragment and Light. Like for "
"script shaders, it defines what built-in nodes will be available."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:45
msgid ""
"The following buttons and number input control the zooming level, grid "
"snapping and distance between grid lines (in pixels)."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:47
msgid ""
"The last icon shows the generated shader code corresponding to your graph."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:51
msgid ""
"Although VisualShaders do not require coding, they share the same logic with "
"script shaders. It is advised to learn the basics of both to have a good "
"understanding of the shading pipeline."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:55
msgid ""
"The visual shader graph is converted to a script shader behind the scene, "
"and you can see this code by pressing the last button in the toolbar. This "
"can be convenient to understand what a given node does and how to reproduce "
"it in scripts."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:61
msgid "Using the Visual Shader Editor"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:63
msgid ""
"By default, every new ``VisualShader`` will have an output node. Every node "
"connection ends at one of the output node's sockets. A node is the basic "
"unit to create your shader. To add a new node, click on the ``Add Node`` "
"button on the upper left corner or right click on any empty location in the "
"graph, and a menu will pop up."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:71
msgid "This popup has the following properties:"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:73
msgid ""
"If you right-click on the graph, this menu will be called at the cursor "
"position and the created node, in that case, will also be placed under that "
"position; otherwise, it will be created at the graph's center."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:76
msgid ""
"It can be resized horizontally and vertically allowing more content to be "
"shown. Size transform and tree content position are saved between the calls, "
"so if you suddenly closed the popup you can easily restore its previous "
"state."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:79
msgid ""
"The ``Expand All`` and ``Collapse All`` options in the drop-down option menu "
"can be used to easily list the available nodes."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:81
msgid "You can also drag and drop nodes from the popup onto the graph."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:83
msgid ""
"While the popup has nodes sorted in categories, it can seem overwhelming at "
"first. Try to add some of the nodes, plug them in the output socket and "
"observe what happens."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:87
msgid ""
"When connecting any ``scalar`` output to a ``vector`` input, all components "
"of the vector will take the value of the scalar."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:90
msgid ""
"When connecting any ``vector`` output to a ``scalar`` input, the value of "
"the scalar will be the average of the vector's components."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:94
#, fuzzy
msgid "Visual Shader nodes"
msgstr "Android"

#: ../../docs/tutorials/shading/visual_shaders.rst:96
msgid ""
"Below are some special nodes that are worth knowing about. The list is not "
"exhaustive and might be expanded with more nodes and examples."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:100
msgid "Expression node"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:102
msgid ""
"The ``Expression`` node allows you to write Godot Shading Language (GLSL-"
"like) expressions inside your visual shaders. The node has buttons to add "
"any amount of required input and output ports and can be resized. You can "
"also set up the name and type of each port. The expression you have entered "
"will apply immediately to the material (once the focus leaves the expression "
"text box). Any parsing or compilation errors will be printed to the Output "
"tab. The outputs are initialized to their zero value by default. The node is "
"located under the Special tab and can be used in all shader modes."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:113
msgid ""
"The possibilities of this node are almost limitless – you can write complex "
"procedures, and use all the power of text-based shaders, such as loops, the "
"``discard`` keyword, extended types, etc. For example:"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:120
msgid "Fresnel node"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:122
msgid ""
"The ``Fresnel`` node is designed to accept normal and view vectors and "
"produces a scalar which is the saturated dot product between them. "
"Additionally, you can setup the inversion and the power of equation. The "
"``Fresnel`` node is great for adding a rim-like lighting effect to objects."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:130
msgid "Boolean node"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:132
msgid ""
"The ``Boolean`` node can be converted to ``Scalar`` or ``Vector`` to "
"represent ``0`` or ``1`` and ``(0, 0, 0)`` or ``(1, 1, 1)`` respectively. "
"This property can be used to enable or disable some effect parts with one "
"click."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:139
msgid "If node"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:141
msgid ""
"The ``If`` node allows you to setup a vector which will be returned the "
"result of the comparison between ``a`` and ``b``. There are three vectors "
"which can be returned: ``a == b`` (in that case the tolerance parameter is "
"provided as a comparison threshold – by default it is equal to the minimal "
"value, i.e. ``0.00001``), ``a > b`` and ``a < b``."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:150
msgid "Switch node"
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:152
msgid ""
"The ``Switch`` node returns a vector if the boolean condition is ``true`` or "
"``false``. ``Boolean`` was introduced above. If you convert a vector to a "
"true boolean, all components of the vector should be above zero."
msgstr ""

#: ../../docs/tutorials/shading/visual_shaders.rst:160
msgid ""
"The ``Switch`` node is only available on the GLES3 backed. If you are "
"targeting GLES2 devices, you cannot use ``switch`` statements."
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:4
msgid "Intro to shaders: 2D and 3D water"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:8
msgid ""
"In this hands-on video series, you will create your first water shaders in "
"2D and in 3D. If you're new to shaders, you should start 2D, because you "
"need some basic understanding of the shading language, vertex and fragment "
"shaders, to build upon. 3D adds quite a bit of complexity when it comes to "
"writing shader programs, as you will see in the third video."
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:15
msgid "Watch the tutorials"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:19
msgid ""
"You can watch the `full playlist on YouTube <https://www.youtube.com/watch?"
"v=xoyk_A0RSpI&list=PLhqJJNjsQ7KHqNMYmTwtsYTeTrqrRP_fP>`__. Here are the "
"individual videos:"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:21
msgid ""
"`Intro to Shader Programming <https://www.youtube.com/watch?v=xoyk_A0RSpI>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:22
msgid ""
"`Animated Water and UV Coordinates <https://www.youtube.com/watch?"
"v=U91nqeUe1qQ>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:24
msgid "`Water in 3D <https://www.youtube.com/watch?v=vm9Sdvhq6ho>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:25
msgid ""
"`Texture-based Deformation <https://www.youtube.com/watch?v=Pg79tztNZeA>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:27
msgid ""
"`Merging the Two Waves Together <https://www.youtube.com/watch?"
"v=aC5Yzx7tS74>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:29
msgid ""
"`Functions in ShaderScript <https://www.youtube.com/watch?v=1eNWPbfph1E>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:31
msgid ""
"`Water Shadow and Masking <https://www.youtube.com/watch?v=Xqv7C9mVhak>`__"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:35
msgid "Download the source code"
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:37
msgid ""
"Download the intro to shaders project here to follow along: :download:"
"`2d_water_shader.zip <files/2d_water_shader.zip>`."
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:40
msgid ""
"It comes with a `start` folder to follow along with the 2D tutorials, and an "
"`end` folder that contains the final code."
msgstr ""

#: ../../docs/tutorials/shading/intro_to_shaders_water_workshop.rst:43
msgid ""
"You will find the 3D water project on `this GitHub repository <https://"
"github.com/BastiaanOlij/shader_tutorial>`_. We didn't include it here, as it "
"is a little heavy."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:4
msgid "Screen-reading shaders"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:9
msgid ""
"Very often, it is desired to make a shader that reads from the same screen "
"to which it's writing. 3D APIs, such as OpenGL or DirectX, make this very "
"difficult because of internal hardware limitations. GPUs are extremely "
"parallel, so reading and writing causes all sorts of cache and coherency "
"problems. As a result, not even the most modern hardware supports this "
"properly."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:16
msgid ""
"The workaround is to make a copy of the screen, or a part of the screen, to "
"a back-buffer and then read from it while drawing. Godot provides a few "
"tools that make this process easy!"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:21
msgid "SCREEN_TEXTURE built-in texture"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:23
msgid ""
"Godot :ref:`doc_shading_language` has a special texture, ``SCREEN_TEXTURE`` "
"(and ``DEPTH_TEXTURE`` for depth, in the case of 3D). It takes as argument "
"the UV of the screen and returns a vec3 RGB with the color. A special built-"
"in varying: SCREEN_UV can be used to obtain the UV for the current fragment. "
"As a result, this simple canvas_item fragment shader:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:34
msgid "results in an invisible object, because it just shows what lies behind."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:36
msgid ""
"The reason why textureLod must be used is because, when Godot copies back a "
"chunk of the screen, it also does an efficient separatable gaussian blur to "
"its mipmaps."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:39
msgid ""
"This allows for not only reading from the screen, but reading from it with "
"different amounts of blur at no cost."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:44
msgid ""
"Mipmaps are not generated in GLES2 due to poor performance and compatibility "
"with older devices."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:48
msgid "SCREEN_TEXTURE example"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:50
msgid ""
"``SCREEN_TEXTURE`` can be used for many things. There is a special demo for "
"*Screen Space Shaders*, that you can download to see and learn. One example "
"is a simple shader to adjust brightness, contrast and saturation:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:74
msgid "Behind the scenes"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:76
msgid ""
"While this seems magical, it's not. In 2D, the ``SCREEN_TEXTURE`` built-in, "
"when first found in a node that is about to be drawn, does a full-screen "
"copy to a back-buffer. Subsequent nodes that use it in shaders will not have "
"the screen copied for them, because this ends up being inefficient. In 3D, "
"the screen is copied after the opaque geometry pass, but before the "
"transparent geometry pass, so transparent objects will not be captured in "
"the ``SCREEN_TEXTURE``."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:84
msgid ""
"As a result, in 2D, if shaders that use ``SCREEN_TEXTURE`` overlap, the "
"second one will not use the result of the first one, resulting in unexpected "
"visuals:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:90
msgid ""
"In the above image, the second sphere (top right) is using the same source "
"for ``SCREEN_TEXTURE`` as the first one below, so the first one \"disappears"
"\", or is not visible."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:94
msgid ""
"In 2D, this can be corrected via the :ref:`BackBufferCopy "
"<class_BackBufferCopy>` node, which can be instantiated between both "
"spheres. BackBufferCopy can work by either specifying a screen region or the "
"whole screen:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:100
msgid "With correct back-buffer copying, the two spheres blend correctly:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:104
msgid ""
"In 3D, there is less flexibility to solve this particular issue because the "
"``SCREEN_TEXTURE`` is only captured once. Be careful when using "
"``SCREEN_TEXTURE`` in 3D as it won't capture transparent objects and may "
"capture some opaque objects that are in front of the object."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:109
msgid ""
"You can reproduce the back-buffer logic in 3D by creating a :ref:`Viewport "
"<class_Viewport>` with a camera in the same position as your object, and "
"then use the :ref:`Viewport's <class_Viewport>` texture instead of "
"``SCREEN_TEXTURE``."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:114
msgid "Back-buffer logic"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:116
msgid ""
"So, to make it clearer, here's how the backbuffer copying logic works in "
"Godot:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:119
msgid ""
"If a node uses the ``SCREEN_TEXTURE``, the entire screen is copied to the "
"back buffer before drawing that node. This only happens the first time; "
"subsequent nodes do not trigger this."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:122
msgid ""
"If a BackBufferCopy node was processed before the situation in the point "
"above (even if ``SCREEN_TEXTURE`` was not used), the behavior described in "
"the point above does not happen. In other words, automatic copying of the "
"entire screen only happens if ``SCREEN_TEXTURE`` is used in a node for the "
"first time and no BackBufferCopy node (not disabled) was found before in "
"tree-order."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:128
msgid ""
"BackBufferCopy can copy either the entire screen or a region. If set to only "
"a region (not the whole screen) and your shader uses pixels not in the "
"region copied, the result of that read is undefined (most likely garbage "
"from previous frames). In other words, it's possible to use BackBufferCopy "
"to copy back a region of the screen and then use ``SCREEN_TEXTURE`` on a "
"different region. Avoid this behavior!"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:137
msgid "DEPTH_TEXTURE"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:139
msgid ""
"For 3D Shaders, it's also possible to access the screen depth buffer. For "
"this, the ``DEPTH_TEXTURE`` built-in is used. This texture is not linear; it "
"must be converted via the inverse projection matrix."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:143
msgid ""
"The following code retrieves the 3D position below the pixel being drawn:"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:4
msgid "Migrating to Godot's shading language"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:9
msgid ""
"This document explains the differences between Godot's shading language and "
"GLSL and gives practical advice on how to migrate shaders from other "
"sources, such as Shadertoy and The Book of Shaders, into Godot shaders."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:13
msgid ""
"For detailed information on Godot's shading language, please refer to the :"
"ref:`Shading Language <doc_shading_language>` reference."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:17
msgid "GLSL"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:19
msgid ""
"Godot uses a shading language based on GLSL with the addition of a few "
"quality-of-life features. Accordingly, most features available in GLSL are "
"available in Godot's shading language."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:23
msgid "Shader programs"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:25
msgid ""
"In GLSL, each shader uses a separate program. You have one program for the "
"vertex shader and one for the fragment shader. In Godot, you have a single "
"shader that contains a ``vertex`` and/or a ``fragment`` function. If you "
"only choose to write one, Godot will supply the other."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:29
msgid ""
"Godot allows uniform variables and functions to be shared by defining the "
"fragment and vertex shaders in one file. In GLSL, the vertex and fragment "
"programs cannot share variables except when varyings are used."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:34
msgid "Vertex attributes"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:36
msgid ""
"In GLSL, you can pass in per-vertex information using attributes and have "
"the flexibility to pass in as much or as little as you want. In Godot, you "
"have a set number of input attributes, including ``VERTEX`` (position), "
"``COLOR``, ``UV``, ``UV2``, ``NORMAL``. For a complete list, see the :ref:"
"`Shading language reference <doc_shading_language>`."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:42
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:98
msgid "gl_Position"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:44
msgid ""
"``gl_Position`` receives the final position of a vertex specified in the "
"vertex shader. It is specified by the user in clip space. Typically, in "
"GLSL, the model space vertex position is passed in using a vertex attribute "
"called ``position`` and you handle the conversion from model space to clip "
"space manually."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:49
msgid ""
"In Godot, ``VERTEX`` specifies the vertex position in model space at the "
"beginning of the ``vertex`` function. Godot also handles the final "
"conversion to clip space after the user-defined ``vertex`` function is run. "
"If you want to skip the conversion from model to view space, you can set the "
"``render_mode`` to ``skip_vertex_transform``. If you want to skip all "
"transforms, set ``render_mode`` to ``skip_vertex_transform`` and set the "
"``PROJECTION_MATRIX`` to ``mat4(1.0)`` in order to nullify the final "
"transform from view space to clip space."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:59
msgid ""
"Varyings are a type of variable that can be passed from the vertex shader to "
"the fragment shader. In modern GLSL (3.0 and up), varyings are defined with "
"the ``in`` and ``out`` keywords. A variable going out of the vertex shader "
"is defined with ``out`` in the vertex shader and ``in`` inside the fragment "
"shader."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:64
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:206
msgid "Main"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:66
msgid ""
"In GLSL, each shader program looks like a self-contained C-style program. "
"Accordingly, the main entry point is ``main``. If you are copying a vertex "
"shader, rename ``main`` to ``vertex`` and if you are copying a fragment "
"shader, rename ``main`` to ``fragment``."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:73
msgid ""
"Godot currently does not support constants. You can fake the functionality "
"by using a uniform initialized to the value, but you will not benefit from "
"the increased speed from using a constant."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:77
msgid "Macros"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:79
msgid ""
"In keeping with its similarity to C, GLSL lets you use macros. Commonly "
"``#define`` is used to define constants or small functions. There is no "
"straightforward way to translate defines to Godot's shading language. If it "
"is a function that is defined, then replace with a function, and if it is a "
"constant, then replace with a uniform. For other macros (``#if``, "
"``#ifdef``, etc.), there is no equivalent because they run during the pre-"
"processing stage of compilation."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:88
msgid ""
"GLSL has many built-in variables that are hard-coded. These variables are "
"not uniforms, so they are not editable from the main program."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:92
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:158
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:218
msgid "Variable"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:92
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:158
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:218
msgid "Equivalent"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:94
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:220
msgid "gl_FragColor"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:94
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:160
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:220
msgid "out vec4"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:94
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:160
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:220
msgid "COLOR"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:94
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:160
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:220
msgid "Output color for each pixel."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:96
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:222
msgid "gl_FragCoord"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:96
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:98
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:174
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:176
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:222
msgid "vec4"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:96
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:222
msgid "FRAGCOORD"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:96
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:162
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:222
msgid "For full screen quads. For smaller quads, use UV."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:98
msgid "VERTEX"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:98
msgid "Position of Vertex, output from Vertex Shader."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:100
msgid "gl_PointSize"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:100
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:166
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:168
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:170
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:172
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:226
#: ../../docs/tutorials/misc/binary_serialization_api.rst:31
msgid "float"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:100
msgid "POINT_SIZE"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:100
msgid "Size of Point primitive."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:102
msgid "gl_PointCoord"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:102
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:162
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:224
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:228
msgid "vec2"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:102
msgid "POINT_COORD"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:102
msgid "Position on point when drawing Point primitives."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:104
msgid "gl_FrontFacing"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:104
#: ../../docs/tutorials/misc/binary_serialization_api.rst:27
msgid "bool"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:104
msgid "FRONT_FACING"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:104
msgid "True if front face of primitive."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:110
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:184
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:232
msgid "Coordinates"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:112
msgid ""
"``gl_FragCoord`` in GLSL and ``FRAGCOORD`` in the Godot shading language use "
"the same coordinate system. If using UV in Godot, the y-coordinate will be "
"flipped upside down."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:118
msgid ""
"In GLSL, you can define the precision of a given type (float or int) at the "
"top of the shader with the ``precision`` keyword. In Godot, you can set the "
"precision of individual variables as you need by placing precision "
"qualifiers ``lowp``, ``mediump``, and ``highp`` before the type when "
"defining the variable. For more information, see the :ref:`Shading Language "
"<doc_shading_language>` reference."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:124
msgid "Shadertoy"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:126
msgid ""
"`Shadertoy <https://www.shadertoy.com/results?"
"query=&sort=popular&from=10&num=4>`_ is a website that makes it easy to "
"write fragment shaders and create `pure magic <https://www.shadertoy.com/"
"view/4tjGRh>`_."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:129
msgid ""
"Shadertoy does not give the user full control over the shader. It handles "
"all the input and uniforms and only lets the user write the fragment shader."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:133
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:200
msgid "Types"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:135
msgid ""
"Shadertoy uses the webgl spec, so it runs a slightly different version of "
"GLSL. However, it still has the regular types, including `Constants`_ and "
"macros."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:139
msgid "mainImage"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:141
msgid ""
"The main point of entry to a Shadertoy shader is the ``mainImage`` function. "
"``mainImage`` has two parameters, ``fragColor`` and ``fragCoord``, which "
"correspond to ``COLOR`` and ``FRAGCOORD`` in Godot, respectively. These "
"parameters are handled automatically in Godot, so you do not need to include "
"them as parameters yourself. Anything in the ``mainImage`` function should "
"be copied into the ``fragment`` function when porting to Godot."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:150
msgid ""
"In order to make writing fragment shaders straightforward and easy, "
"Shadertoy handles passing a lot of helpful information from the main program "
"into the fragment shader for you. A few of these have no equivalents in "
"Godot because Godot has chosen not to make them available by default. This "
"is okay because Godot gives you the ability to make your own uniforms. For "
"variables whose equivalents are listed as \"Provide with Uniform\", users "
"are responsible for creating that uniform themselves. The description gives "
"the reader a hint about what they can pass in as a substitute."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:160
msgid "fragColor"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:162
msgid "fragCoord"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:162
msgid "FRAGCOORD.xy"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:164
msgid "iResolution"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:164
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:178
msgid "vec3"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:164
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:224
msgid "1.0 / SCREEN_PIXEL_SIZE"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:164
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:224
msgid "Can also pass in manually."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:166
msgid "iTime"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:166
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:226
msgid "TIME"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:166
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:226
msgid "Time since shader started."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:168
msgid "iTimeDelta"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:168
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:170
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:172
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:174
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:176
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:228
msgid "Provide with Uniform"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:168
msgid "Time to render previous frame."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:170
msgid "iFrame"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:170
msgid "Frame number."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:172
msgid "iChannelTime[4]"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:172
msgid "Time since that particular texture started."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:174
msgid "iMouse"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:174
#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:228
msgid "Mouse position in pixel coordinates."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:176
msgid "iDate"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:176
msgid "Current date, expressed in seconds."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:178
msgid "iChannelResolution[4]"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:178
msgid "1.0 / TEXTURE_PIXEL_SIZE"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:178
msgid "Resolution of particular texture."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:180
msgid "iChanneli"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:180
msgid "Sampler2D"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:180
msgid "TEXTURE"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:180
msgid "Godot provides only one built-in; user can make more."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:186
msgid ""
"``fragCoord`` behaves the same as ``gl_FragCoord`` in :ref:`GLSL "
"<glsl_coordinates>` and ``FRAGCOORD`` in Godot."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:190
msgid "The Book of Shaders"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:192
msgid ""
"Similar to Shadertoy, `The Book of Shaders <https://thebookofshaders.com>`_ "
"provides access to a fragment shader in the web browser, with which the user "
"may interact. The user is restricted to writing fragment shader code with a "
"set list of uniforms passed in and with no ability to add additional "
"uniforms."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:196
msgid ""
"For further help on porting shaders to various frameworks generally, The "
"Book of Shaders provides a `page <https://thebookofshaders.com/04>`_ on "
"running shaders in various frameworks."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:202
msgid ""
"The Book of Shaders uses the webgl spec, so it runs a slightly different "
"version of GLSL. However, it still has the regular types, including "
"`Constants`_ and macros."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:208
msgid ""
"The entry point for a Book of Shaders fragment shader is ``main``, just like "
"in GLSL. Everything written in a Book of Shaders ``main`` function should be "
"copied into Godot's ``fragment`` function."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:214
msgid ""
"The Book of Shaders sticks closer to plain GLSL than Shadertoy does. It also "
"implements fewer uniforms than Shadertoy."
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:224
msgid "u_resolution"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:226
msgid "u_time"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:228
msgid "u_mouse"
msgstr ""

#: ../../docs/tutorials/shading/migrating_to_godot_shader_language.rst:234
msgid ""
"The Book of Shaders uses the same coordinate system as :ref:`GLSL "
"<glsl_coordinates>`."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:4
msgid "Godot shader language style guide"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:6
msgid ""
"This style guide lists conventions to write elegant shaders. The goal is to "
"encourage writing clean, readable code and promote consistency across "
"projects, discussions, and tutorials. Hopefully, this will also support the "
"development of auto-formatting tools."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:11
msgid ""
"Since the Godot shader language is close to C-style languages and GLSL, this "
"guide is inspired by Godot's own GLSL formatting. You can view an example of "
"a GLSL file in Godot's source code `here <https://github.com/godotengine/"
"godot/blob/master/drivers/gles2/shaders/copy.glsl>`__."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:23
msgid ""
"Godot's built-in shader editor uses a lot of these conventions by default. "
"Let it help you."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:26
msgid "Here is a complete shader example based on these guidelines:"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:63
msgid ""
"Each indent level should be one tab greater than the block containing it."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:104
msgid ""
"For a general indentation rule, follow `the \"1TBS Style\" <https://en."
"wikipedia.org/wiki/Indentation_style#Variant:_1TBS_(OTBS)>`_ which "
"recommends placing the brace associated with a control statement on the same "
"line. Always use braces for statements, even if they only span one line. "
"This makes them easier to refactor and avoids mistakes when adding more "
"lines to an ``if`` statement or similar."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:134
msgid "Surround function definitions with one (and only one) blank line:"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:146
msgid ""
"Use one (and only one) blank line inside functions to separate logical "
"sections."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:153
msgid ""
"If you can, try to keep lines under 80 characters. This helps to read the "
"code on small displays and with two shaders opened side-by-side in an "
"external text editor. For example, when looking at a differential revision."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:160
msgid "Never combine multiple statements on a single line."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:208
msgid ""
"Don't use multiline comment syntax if your comment can fit on a single line:"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:216
msgid ""
"In the shader editor, to make the selected code a comment (or uncomment it), "
"press :kbd:`Ctrl + K`. This feature adds or removes ``//`` at the start of "
"the selected lines."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:223
msgid ""
"Always use one space around operators and after commas. Also, avoid "
"extraneous spaces in function calls."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:250
msgid "Floating-point numbers"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:252
msgid ""
"Always specify at least one digit for both the integer and fractional part. "
"This makes it easier to distinguish floating-point numbers from integers, as "
"well as distinguishing numbers greater than 1 from those lower than 1."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:273
msgid "Accessing vector members"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:275
msgid ""
"Use ``r``, ``g``, ``b``, and ``a`` when accessing a vector's members if it "
"contains a color. If the vector contains anything else than a color, use "
"``x``, ``y``, ``z``, and ``w``. This allows those reading your code to "
"better understand what the underlying data represents."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:323
msgid "We suggest to organize shader code this way:"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:344
msgid "This code order follows two rules of thumb:"
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:346
msgid "Metadata and properties first, followed by methods."
msgstr ""

#: ../../docs/tutorials/shading/godot_shader_language_style_guide.rst:347
msgid ""
"\"Public\" comes before \"private\". In a shader language's context, \"public"
"\" refers to what's easily adjustable by the user (uniforms)."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:4
msgid "Advanced post-processing"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:9
msgid ""
"This tutorial describes an advanced method for post-processing in Godot. In "
"particular, it will explain how to write a post-processing shader that uses "
"the depth buffer. You should already be familiar with post-processing "
"generally and, in particular, with the methods outlined in the :ref:`custom "
"post-processing tutorial <doc_custom_postprocessing>`."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:14
msgid ""
"In the previous post-processing tutorial, we rendered the scene to a :ref:"
"`Viewport <class_Viewport>` and then rendered the Viewport in a :ref:"
"`ViewportContainer <class_ViewportContainer>` to the main scene. One "
"limitation of this method is that we could not access the depth buffer "
"because the depth buffer is only available in spatial shaders and Viewports "
"do not maintain depth information."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:21
msgid "Full screen quad"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:23
msgid ""
"In the :ref:`custom post-processing tutorial <doc_custom_postprocessing>`, "
"we covered how to use a Viewport to make custom post-processing effects. "
"There are two main drawbacks of using a Viewport:"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:27
msgid "The depth buffer cannot be accessed"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:28
msgid "The effect of the post-processing shader is not visible in the editor"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:30
msgid ""
"To get around the limitation on using the depth buffer, use a :ref:"
"`MeshInstance <class_MeshInstance>` with a :ref:`QuadMesh <class_QuadMesh>` "
"primitive. This allows us to use a spatial shader and to access the depth "
"texture of the scene. Next, use a vertex shader to make the quad cover the "
"screen at all times so that the post-processing effect will be applied at "
"all times, including in the editor."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:36
msgid ""
"First, create a new MeshInstance and set its mesh to a QuadMesh. This "
"creates a quad centered at position ``(0, 0, 0)`` with a width and height of "
"``1``. Set the width and height to ``2``. Right now, the quad occupies a "
"position in world space at the origin; however, we want it to move with the "
"camera so that it always covers the entire screen. To do this, we will "
"bypass the coordinate transforms that translate the vertex positions through "
"the difference coordinate spaces and treat the vertices as if they were "
"already in clip space."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:44
msgid ""
"The vertex shader expects coordinates to be output in clip space, which are "
"coordinates ranging from ``-1`` at the left and bottom of the screen to "
"``1`` at the top and right of the screen. This is why the QuadMesh needs to "
"have height and width of ``2``. Godot handles the transform from model to "
"view space to clip space behind the scenes, so we need to nullify the "
"effects of Godot's transformations. We do this by setting the ``POSITION`` "
"built-in to our desired position. ``POSITION`` bypasses the built-in "
"transformations and sets the vertex position directly."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:60
msgid ""
"Even with this vertex shader, the quad keeps disappearing. This is due to "
"frustum culling, which is done on the CPU. Frustum culling uses the camera "
"matrix and the AABBs of Meshes to determine if the Mesh will be visible "
"*before* passing it to the GPU. The CPU has no knowledge of what we are "
"doing with the vertices, so it assumes the coordinates specified refer to "
"world positions, not clip space positions, which results in Godot culling "
"the quad when we turn away from the center of the scene. In order to keep "
"the quad from being culled, there are a few options:"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:68
msgid ""
"Add the QuadMesh as a child to the camera, so the camera is always pointed "
"at it"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:69
msgid ""
"Set the Geometry property ``extra_cull_margin`` as large as possible in the "
"QuadMesh"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:71
msgid ""
"The second option ensures that the quad is visible in the editor, while the "
"first option guarantees that it will still be visible even if the camera "
"moves outside the cull margin. You can also use both options."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:76
msgid "Depth texture"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:78
msgid ""
"To read from the depth texture, perform a texture lookup using ``texture()`` "
"and the uniform variable ``DEPTH_TEXTURE``."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:85
msgid ""
"Similar to accessing the screen texture, accessing the depth texture is only "
"possible when reading from the current viewport. The depth texture cannot be "
"accessed from another viewport to which you have rendered."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:89
msgid ""
"The values returned by ``DEPTH_TEXTURE`` are between ``0`` and ``1`` and are "
"nonlinear. When displaying depth directly from the ``DEPTH_TEXTURE``, "
"everything will look almost white unless it is very close. This is because "
"the depth buffer stores objects closer to the camera using more bits than "
"those further, so most of the detail in depth buffer is found close to the "
"camera. In order to make the depth value align with world or model "
"coordinates, we need to linearize the value. When we apply the projection "
"matrix to the vertex position, the z value is made nonlinear, so to "
"linearize it, we multiply it by the inverse of the projection matrix, which "
"in Godot, is accessible with the variable ``INV_PROJECTION_MATRIX``."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:99
msgid ""
"Firstly, take the screen space coordinates and transform them into "
"normalized device coordinates (NDC). NDC run from ``-1`` to ``1``, similar "
"to clip space coordinates. Reconstruct the NDC using ``SCREEN_UV`` for the "
"``x`` and ``y`` axis, and the depth value for ``z``."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:111
msgid ""
"Convert NDC to view space by multiplying the NDC by "
"``INV_PROJECTION_MATRIX``. Recall that view space gives positions relative "
"to the camera, so the ``z`` value will give us the distance to the point."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:124
msgid ""
"Because the camera is facing the negative ``z`` direction, the position will "
"have a negative ``z`` value. In order to get a usable depth value, we have "
"to negate ``view.z``."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:127
msgid ""
"The world position can be constructed from the depth buffer using the "
"following code. Note that the ``CAMERA_MATRIX`` is needed to transform the "
"position from view space into world space, so it needs to be passed to the "
"fragment shader with a varying."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:146
#, fuzzy
msgid "An optimization"
msgstr "אנימציות"

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:148
msgid ""
"You can benefit from using a single large triangle rather than using a full "
"screen quad. The reason for this is explained `here <https://michaldrobot."
"com/2014/04/01/gcn-execution-patterns-in-full-screen-passes>`_. However, the "
"benefit is quite small and only beneficial when running especially complex "
"fragment shaders."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:153
msgid ""
"Set the Mesh in the MeshInstance to an :ref:`ArrayMesh <class_ArrayMesh>`. "
"An ArrayMesh is a tool that allows you to easily construct a Mesh from "
"Arrays for vertices, normals, colors, etc."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:157
msgid "Now, attach a script to the MeshInstance and use the following code:"
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:179
msgid ""
"The triangle is specified in normalized device coordinates. Recall, NDC run "
"from ``-1`` to ``1`` in both the ``x`` and ``y`` directions. This makes the "
"screen ``2`` units wide and ``2`` units tall. In order to cover the entire "
"screen with a single triangle, use a triangle that is ``4`` units wide and "
"``4`` units tall, double its height and width."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:185
msgid ""
"Assign the same vertex shader from above and everything should look exactly "
"the same."
msgstr ""

#: ../../docs/tutorials/shading/advanced_postprocessing.rst:187
msgid ""
"The one drawback to using an ArrayMesh over using a QuadMesh is that the "
"ArrayMesh is not visible in the editor because the triangle is not "
"constructed until the scene is run. To get around that, construct a single "
"triangle Mesh in a modelling program and use that in the MeshInstance "
"instead."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:4
msgid "High-level multiplayer"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:7
msgid "High-level vs low-level API"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:9
msgid ""
"The following explains the differences of high- and low-level networking in "
"Godot as well as some fundamentals. If you want to jump in head-first and "
"add networking to your first nodes, skip to `Initializing the network`_ "
"below. But make sure to read the rest later on!"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:11
msgid ""
"Godot always supported standard low-level networking via UDP, TCP and some "
"higher level protocols such as SSL and HTTP. These protocols are flexible "
"and can be used for almost anything. However, using them to synchronize game "
"state manually can be a large amount of work. Sometimes that work can't be "
"avoided or is worth it, for example when working with a custom server "
"implementation on the backend. But in most cases, it's worthwhile to "
"consider Godot's high-level networking API, which sacrifices some of the "
"fine-grained control of low-level networking for greater ease of use."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:14
msgid "This is due to the inherent limitations of the low-level protocols:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:16
msgid ""
"TCP ensures packets will always arrive reliably and in order, but latency is "
"generally higher due to error correction. It's also quite a complex protocol "
"because it understands what a \"connection\" is, and optimizes for goals "
"that often don't suit applications like multiplayer games. Packets are "
"buffered to be sent in larger batches, trading less per-packet overhead for "
"higher latency. This can be useful for things like HTTP, but generally not "
"for games. Some of this can be configured and disabled (e.g. by disabling "
"\"Nagle's algorithm\" for the TCP connection)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:18
msgid ""
"UDP is a simpler protocol, which only sends packets (and has no concept of a "
"\"connection\"). No error correction makes it pretty quick (low latency), "
"but packets may be lost along the way or received in the wrong order. Added "
"to that, the MTU (maximum packet size) for UDP is generally low (only a few "
"hundred bytes), so transmitting larger packets means splitting them, "
"reorganizing them and retrying if a part fails."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:23
msgid ""
"In general, TCP can be thought of as reliable, ordered, and slow; UDP as "
"unreliable, unordered and fast. Because of the large difference in "
"performance, it often makes sense to re-build the parts of TCP wanted for "
"games (optional reliability and packet order), while avoiding the unwanted "
"parts (congestion/traffic control features, Nagle's algorithm, etc). Due to "
"this, most game engines come with such an implementation, and Godot is no "
"exception."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:26
msgid ""
"In summary, you can use the low-level networking API for maximum control and "
"implement everything on top of bare network protocols or use the high-level "
"API based on :ref:`SceneTree <class_SceneTree>` that does most of the heavy "
"lifting behind the scenes in a generally optimized way."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:28
msgid ""
"Most of Godot's supported platforms offer all or most of the mentioned high- "
"and low-level networking features. As networking is always largely hardware "
"and operating system dependent, however, some features may change or not be "
"available on some target platforms. Most notably, the HTML5 platform "
"currently only offers WebSocket support and lacks some of the higher level "
"features as well as raw access to low-level protocols like TCP and UDP."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:34
msgid ""
"More about TCP/IP, UDP, and networking: https://gafferongames.com/post/"
"udp_vs_tcp/"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:37
msgid ""
"Gaffer On Games has a lot of useful articles about networking in Games "
"(`here <https://gafferongames.com/categories/game-networking/>`__), "
"including the comprehensive `introduction to networking models in games "
"<https://gafferongames.com/post/"
"what_every_programmer_needs_to_know_about_game_networking/>`__."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:41
msgid ""
"If you want to use your low-level networking library of choice instead of "
"Godot's built-in networking, see here for an example: https://github.com/"
"PerduGames/gdnet3"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:45
msgid ""
"Adding networking to your game comes with some responsibility. It can make "
"your application vulnerable if done wrong and may lead to cheats or "
"exploits. It may even allow an attacker to compromise the machines your "
"application runs on and use your servers to send spam, attack others or "
"steal your users data if they play your game."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:50
msgid ""
"This is always the case when networking is involved and has nothing to do "
"with Godot. You can of course experiment, but when you release a networked "
"application, always take care of any possible security concerns."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:55
msgid "Mid level abstraction"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:57
msgid ""
"Before going into how we would like to synchronize a game across the "
"network, it can be helpful to understand how the base network API for "
"synchronization works."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:59
msgid ""
"Godot uses a mid-level object :ref:`NetworkedMultiplayerPeer "
"<class_NetworkedMultiplayerPeer>`. This object is not meant to be created "
"directly, but is designed so that several C++ implementations can provide it."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:62
msgid ""
"This object extends from :ref:`PacketPeer <class_PacketPeer>`, so it "
"inherits all the useful methods for serializing, sending and receiving data. "
"On top of that, it adds methods to set a peer, transfer mode, etc. It also "
"includes signals that will let you know when peers connect or disconnect."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:64
msgid ""
"This class interface can abstract most types of network layers, topologies "
"and libraries. By default, Godot provides an implementation based on ENet (:"
"ref:`NetworkedMultiplayerEnet <class_NetworkedMultiplayerENet>`), one based "
"on WebRTC (:ref:`WebRTCMultiplayer <class_WebRTCMultiplayer>`), and one "
"based on WebSocket (:ref:`WebSocketMultiplayerPeer "
"<class_WebSocketMultiplayerPeer>`), but this could be used to implement "
"mobile APIs (for ad hoc WiFi, Bluetooth) or custom device/console-specific "
"networking APIs."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:70
msgid ""
"For most common cases, using this object directly is discouraged, as Godot "
"provides even higher level networking facilities. Yet it is made available "
"in case a game has specific needs for a lower level API."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:74
msgid "Initializing the network"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:76
msgid ""
"The object that controls networking in Godot is the same one that controls "
"everything tree-related: :ref:`SceneTree <class_SceneTree>`."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:78
msgid ""
"To initialize high-level networking, the SceneTree must be provided a "
"NetworkedMultiplayerPeer object."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:80
msgid ""
"To create that object, it first has to be initialized as a server or client."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:82
msgid ""
"Initializing as a server, listening on the given port, with a given maximum "
"number of peers:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:90
msgid "Initializing as a client, connecting to a given IP and port:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:98
msgid "Get the previously set network peer:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:104
msgid "Checking whether the tree is initialized as a server or client:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:110
msgid "Terminating the networking feature:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:116
msgid ""
"(Although it may make sense to send a message first to let the other peers "
"know you're going away instead of letting the connection close or timeout, "
"depending on your game.)"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:119
msgid "Managing connections"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:121
msgid ""
"Some games accept connections at any time, others during the lobby phase. "
"Godot can be requested to no longer accept connections at any point (see "
"``set_refuse_new_network_connections(bool)`` and related methods on :ref:"
"`SceneTree <class_SceneTree>`). To manage who connects, Godot provides the "
"following signals in SceneTree:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:124
msgid "Server and Clients:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:126
msgid "``network_peer_connected(int id)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:127
msgid "``network_peer_disconnected(int id)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:129
msgid ""
"The above signals are called on every peer connected to the server "
"(including on the server) when a new peer connects or disconnects. Clients "
"will connect with a unique ID greater than 1, while network peer ID 1 is "
"always the server. Anything below 1 should be handled as invalid. You can "
"retrieve the ID for the local system via :ref:`SceneTree."
"get_network_unique_id() <class_SceneTree_method_get_network_unique_id>`. "
"These IDs will be useful mostly for lobby management and should generally be "
"stored, as they identify connected peers and thus players. You can also use "
"IDs to send messages only to certain peers."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:135
msgid "Clients:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:137
msgid "``connected_to_server``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:138
msgid "``connection_failed``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:139
msgid "``server_disconnected``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:141
msgid ""
"Again, all these functions are mainly useful for lobby management or for "
"adding/removing players on the fly. For these tasks, the server clearly has "
"to work as a server and you have to perform tasks manually such as sending a "
"newly connected player information about other already connected players (e."
"g. their names, stats, etc)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:145
msgid ""
"Lobbies can be implemented any way you want, but the most common way is to "
"use a node with the same name across scenes in all peers. Generally, an "
"autoloaded node/singleton is a great fit for this, to always have access to, "
"e.g. \"/root/lobby\"."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:149
msgid "RPC"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:151
msgid ""
"To communicate between peers, the easiest way is to use RPCs (remote "
"procedure calls). This is implemented as a set of functions in :ref:`Node "
"<class_Node>`:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:154
msgid "``rpc(\"function_name\", <optional_args>)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:155
msgid "``rpc_id(<peer_id>,\"function_name\", <optional_args>)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:156
msgid "``rpc_unreliable(\"function_name\", <optional_args>)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:157
msgid "``rpc_unreliable_id(<peer_id>, \"function_name\", <optional_args>)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:159
msgid "Synchronizing member variables is also possible:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:161
msgid "``rset(\"variable\", value)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:162
msgid "``rset_id(<peer_id>, \"variable\", value)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:163
msgid "``rset_unreliable(\"variable\", value)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:164
msgid "``rset_unreliable_id(<peer_id>, \"variable\", value)``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:166
msgid "Functions can be called in two fashions:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:168
msgid ""
"Reliable: the function call will arrive no matter what, but may take longer "
"because it will be re-transmitted in case of failure."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:169
msgid ""
"Unreliable: if the function call does not arrive, it will not be re-"
"transmitted; but if it arrives, it will do it quickly."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:171
msgid ""
"In most cases, reliable is desired. Unreliable is mostly useful when "
"synchronizing object positions (sync must happen constantly, and if a packet "
"is lost, it's not that bad because a new one will eventually arrive and it "
"would likely be outdated because the object moved further in the meantime, "
"even if it was resent reliably)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:174
msgid ""
"There is also the ``get_rpc_sender_id`` function in ``SceneTree``, which can "
"be used to check which peer (or peer ID) sent an RPC."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:177
msgid "Back to lobby"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:179
msgid ""
"Let's get back to the lobby. Imagine that each player that connects to the "
"server will tell everyone about it."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:225
msgid ""
"You might have already noticed something different, which is the usage of "
"the ``remote`` keyword on the ``register_player`` function:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:231
msgid ""
"This keyword has two main uses. The first is to let Godot know that this "
"function can be called from RPC. If no keywords are added, Godot will block "
"any attempts to call functions for security. This makes security work a lot "
"easier (so a client can't call a function to delete a file on another "
"client's system)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:235
msgid ""
"The second use is to specify how the function will be called via RPC. There "
"are four different keywords:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:237
msgid "``remote``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:238
msgid "``remotesync``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:239
msgid "``master``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:240
msgid "``puppet``"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:242
msgid ""
"The ``remote`` keyword means that the ``rpc()`` call will go via network and "
"execute remotely."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:244
msgid ""
"The ``remotesync`` keyword means that the ``rpc()`` call will go via network "
"and execute remotely, but will also execute locally (do a normal function "
"call)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:246
msgid ""
"The others will be explained further down. Note that you could also use the "
"``get_rpc_sender_id`` function on ``SceneTree`` to check which peer actually "
"made the RPC call to ``register_player``."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:249
msgid ""
"With this, lobby management should be more or less explained. Once you have "
"your game going, you will most likely want to add some extra security to "
"make sure clients don't do anything funny (just validate the info they send "
"from time to time, or before game start). For the sake of simplicity and "
"because each game will share different information, this is not shown here."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:254
msgid "Starting the game"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:256
msgid ""
"Once enough players have gathered in the lobby, the server should probably "
"start the game. This is nothing special in itself, but we'll explain a few "
"nice tricks that can be done at this point to make your life much easier."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:260
msgid "Player scenes"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:262
msgid ""
"In most games, each player will likely have its own scene. Remember that "
"this is a multiplayer game, so in every peer you need to instance **one "
"scene for each player connected to it**. For a 4 player game, each peer "
"needs to instance 4 player nodes."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:265
msgid ""
"So, how to name such nodes? In Godot, nodes need to have a unique name. It "
"must also be relatively easy for a player to tell which node represents each "
"player ID."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:268
msgid ""
"The solution is to simply name the *root nodes of the instanced player "
"scenes as their network ID*. This way, they will be the same in every peer "
"and RPC will work great! Here is an example:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:297
msgid ""
"Depending on when you execute pre_configure_game(), you may need to change "
"any calls to ``add_child()`` to be deferred via ``call_deferred()``, as the "
"SceneTree is locked while the scene is being created (e.g. when ``_ready()`` "
"is being called)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:301
msgid "Synchronizing game start"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:303
msgid ""
"Setting up players might take different amounts of time for every peer due "
"to lag, different hardware, or other reasons. To make sure the game will "
"actually start when everyone is ready, pausing the game until all players "
"are ready can be useful:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:312
msgid ""
"When the server gets the OK from all the peers, it can tell them to start, "
"as for example:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:333
msgid "Synchronizing the game"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:335
msgid ""
"In most games, the goal of multiplayer networking is that the game runs "
"synchronized on all the peers playing it. Besides supplying an RPC and "
"remote member variable set implementation, Godot adds the concept of network "
"masters."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:339
msgid "Network master"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:341
msgid ""
"The network master of a node is the peer that has the ultimate authority "
"over it."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:343
msgid ""
"When not explicitly set, the network master is inherited from the parent "
"node, which if not changed, is always going to be the server (ID 1). Thus "
"the server has authority over all nodes by default."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:345
msgid ""
"The network master can be set with the function :ref:`Node."
"set_network_master(id, recursive) <class_Node_method_set_network_master>` "
"(recursive is ``true`` by default and means the network master is "
"recursively set on all child nodes of the node as well)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:348
msgid ""
"Checking that a specific node instance on a peer is the network master for "
"this node for all connected peers is done by calling :ref:`Node."
"is_network_master() <class_Node_method_is_network_master>`. This will return "
"``true`` when executed on the server and ``false`` on all client peers."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:350
msgid ""
"If you have paid attention to the previous example, it's possible you "
"noticed that each peer was set to have network master authority for their "
"own player (Node) instead of the server:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:370
msgid ""
"Each time this piece of code is executed on each peer, the peer makes itself "
"master on the node it controls, and all other nodes remain as puppets with "
"the server being their network master."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:372
msgid ""
"To clarify, here is an example of how this looks in the `bomber demo "
"<https://github.com/godotengine/godot-demo-projects/tree/master/networking/"
"multiplayer_bomber>`_:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:379
msgid "Master and puppet keywords"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:383
msgid ""
"The real advantage of this model is when used with the ``master``/``puppet`` "
"keywords in GDScript (or their equivalent in C# and Visual Script). "
"Similarly to the ``remote`` keyword, functions can also be tagged with them:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:386
msgid "Example bomb code:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:394
msgid "Example player code:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:408
msgid ""
"In the above example, a bomb explodes somewhere (likely managed by whoever "
"is master). The bomb knows the bodies in the area, so it checks them and "
"checks that they contain an ``exploded`` function."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:411
msgid ""
"If they do, the bomb calls ``exploded`` on it. However, the ``exploded`` "
"method in the player has a ``master`` keyword. This means that only the "
"player who is master for that instance will actually get the function."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:414
msgid ""
"This instance, then, calls the ``stun`` method in the same instances of that "
"same player (but in different peers), and only those which are set as "
"puppet, making the player look stunned in all the peers (as well as the "
"current, master one)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:417
msgid ""
"Note that you could also send the ``stun()`` message only to a specific "
"player by using ``rpc_id(<id>, \"exploded\", bomb_owner)``. This may not "
"make much sense for an area-of-effect case like the bomb, but in other "
"cases, like single target damage."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:427
msgid ""
"Once you've made a multiplayer game, you may want to export it to run it on "
"a dedicated server with no GPU available. See :ref:"
"`doc_exporting_for_dedicated_servers` for more information."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:433
msgid ""
"The code samples on this page aren't designed to run on a dedicated server. "
"You'll have to modify them so the server isn't considered to be a player. "
"You'll also have to modify the game starting mechanism so that the first "
"player who joins can start the game."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:4
msgid "Making HTTP requests"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:6
msgid ""
"The :ref:`HTTPRequest <class_HTTPRequest>` node is the easiest way to make "
"HTTP requests in Godot. It is backed by the more low-level :ref:`HTTPClient "
"<class_HTTPClient>`, for which a tutorial is available :ref:`here "
"<doc_http_client_class>`."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:9
msgid ""
"For the sake of this example, we will create a simple UI with a button, that "
"when pressed will start the HTTP request to the specified URL."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:12
msgid "Preparing scene"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:14
msgid ""
"Create a new empty scene, add a CanvasLayer as the root node and add a "
"script to it. Then add two child nodes to it: a Button and an HTTPRequest "
"node. You will need to connect the following signals to the CanvasLayer "
"script:"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:16
msgid "Button.pressed: When the button is pressed, we will start the request."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:17
msgid ""
"HTTPRequest.request_completed: When the request is completed, we will get "
"the requested data as an argument."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:24
msgid ""
"Below is all the code we need to make it work. The URL points to an online "
"API mocker; it returns a pre-defined JSON string, which we will then parse "
"to get access to the data."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:40
msgid ""
"With this, you should see ``(hello:world)`` printed on the console; hello "
"being a key, and world being a value, both of them strings."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:42
msgid ""
"For more information on parsing JSON, see the class references for :ref:"
"`JSON <class_JSON>` and :ref:`JSONParseResult <class_JSONParseResult>`."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:44
msgid ""
"Note that you may want to check whether the ``result`` equals "
"``RESULT_SUCCESS`` and whether a JSON parsing error occurred, see the JSON "
"class reference and :ref:`HTTPRequest <class_HTTPRequest>` for more."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:46
msgid ""
"Of course, you can also set custom HTTP headers. These are given as a string "
"array, with each string containing a header in the format ``\"header: value"
"\"``. For example, to set a custom user agent (the HTTP ``user-agent`` "
"header) you could use the following:"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:53
msgid ""
"Please note that, for SSL/TLS encryption and thus HTTPS URLs to work, you "
"may need to take some steps as described :ref:`here <doc_ssl_certificates>`."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:55
msgid ""
"Also, when calling APIs using authorization, be aware that someone might "
"analyse and decompile your released application and thus may gain access to "
"any embedded authorization information like tokens, usernames or passwords. "
"That means it is usually not a good idea to embed things such as database "
"access credentials inside your game. Avoid providing information useful to "
"an attacker whenever possible."
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:59
msgid "Sending data to server"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:61
msgid ""
"Until now, we have limited ourselves to requesting data from a server. But "
"what if you need to send data to the server? Here is a common way of doing "
"it:"
msgstr ""

#: ../../docs/tutorials/networking/http_request_class.rst:72
msgid ""
"Keep in mind that you have to wait for a request to finish before sending "
"another one. Making multiple request at once requires you to have one node "
"per request. A common strategy is to create and delete HTTPRequest nodes at "
"runtime as necessary."
msgstr ""

#: ../../docs/tutorials/networking/http_client_class.rst:4
msgid "HTTP client class"
msgstr ""

#: ../../docs/tutorials/networking/http_client_class.rst:6
msgid ""
":ref:`HTTPClient <class_HTTPClient>` provides low-level access to HTTP "
"communication. For a higher-level interface, you may want to take a look at :"
"ref:`HTTPRequest <class_HTTPRequest>` first, which has a tutorial available :"
"ref:`here <doc_http_request_class>`."
msgstr ""

#: ../../docs/tutorials/networking/http_client_class.rst:10
msgid ""
"Here's an example of using the :ref:`HTTPClient <class_HTTPClient>` class. "
"It's just a script, so it can be run by executing:"
msgstr ""

#: ../../docs/tutorials/networking/http_client_class.rst:17
msgid "It will connect and fetch a website."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:4
msgid "SSL certificates"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:9
msgid ""
"It is often desired to use SSL connections for communications to avoid \"man "
"in the middle\" attacks. Godot has a connection wrapper, :ref:`StreamPeerSSL "
"<class_StreamPeerSSL>`, which can take a regular connection and add security "
"around it. The :ref:`HTTPClient <class_HTTPClient>` class also supports "
"HTTPS by using this same wrapper."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:16
msgid ""
"Godot includes SSL certificates from Mozilla, but you can provide your own "
"with a .crt file in the project settings:"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:21
msgid ""
"This file should contain any number of public certificates in `PEM format "
"<https://en.wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail>`__."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:24
msgid ""
"Of course, remember to add .crt as filter so the exporter recognizes this "
"when exporting your project."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:29
msgid "There are two ways to obtain certificates:"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:32
msgid "Approach 1: self signed cert"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:34
msgid ""
"The first approach is the simplest: generate a private and public key pair "
"and add the public key (in PEM format) to the .crt file. The private key "
"should go to your server."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:38
msgid ""
"OpenSSL has `some documentation <https://raw.githubusercontent.com/openssl/"
"openssl/master/doc/HOWTO/keys.txt>`__ about this. This approach also **does "
"not require domain validation** nor requires you to spend a considerable "
"amount of money in purchasing certificates from a CA."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:45
msgid "Approach 2: CA cert"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:47
msgid ""
"The second approach consists of using a certificate authority (CA) such as "
"Verisign, Geotrust, etc. This is a more cumbersome process, but it's more "
"\"official\" and ensures your identity is clearly represented."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:52
msgid ""
"Unless you are working with large companies or corporations, or need to "
"connect to someone else's servers (i.e., connecting to Google or some other "
"REST API provider via HTTPS), this method is not as useful."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:56
msgid ""
"Also, when using a CA issued cert, **you must enable domain validation**, to "
"ensure the domain you are connecting to is the one intended, otherwise any "
"website can issue any certificate in the same CA and it will work."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:61
msgid ""
"If you are using Linux, you can use the supplied certs file, generally "
"located in:"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:68
msgid ""
"This file allows HTTPS connections to virtually any website (i.e., Google, "
"Microsoft, etc.)."
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:71
msgid ""
"Or pick any of the more specific certificates there if you are connecting to "
"a specific one."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:4
#: ../../docs/tutorials/networking/webrtc.rst:14
msgid "WebSocket"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:7
msgid "HTML5 and WebSocket"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:9
msgid ""
"The WebSocket protocol was standardized in 2011 with the original goal of "
"allowing browsers to create stable and bidirectional connections with a "
"server. Before that, browsers used to only support HTTPRequests, which is "
"not well-suited for bidirectional communication."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:12
msgid ""
"The protocol is quite simple, message based, and a very powerful tool to "
"send push notifications to browsers, and has been used to implement chats, "
"turn-based games, etc. It still uses a TCP connection, which is good for "
"reliability but not for latency, so not good for real-time applications like "
"VoIP and fast-paced games (see :ref:`WebRTC <doc_webrtc>` for those use "
"cases)."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:14
msgid ""
"Due to its simplicity, its wide compatibility, and being easier to use than "
"a raw TCP connection, WebSocket soon started to spread outside the browsers, "
"in native applications as a mean to communicate with network servers."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:16
msgid "Godot supports WebSocket in both native and HTML5 exports."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:19
msgid "Using WebSocket in Godot"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:21
msgid ""
"WebSocket is implemented in Godot via three main classes :ref:"
"`WebSocketClient <class_WebSocketClient>`, :ref:`WebSocketServer "
"<class_WebSocketServer>`, and :ref:`WebSocketPeer <class_WebSocketPeer>`. "
"The WebSocket implementation is compatible with the High Level Multiplayer. "
"See section on :ref:`high-level multiplayer <doc_high_level_multiplayer>` "
"for more details."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:24
msgid "Minimal client example"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:26
msgid ""
"This example will show you how to create a WebSocket connection to a remote "
"server, and how to send and receive data."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:79
#: ../../docs/tutorials/networking/webrtc.rst:91
msgid "This will print:"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:87
msgid "Minimal server example"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:89
msgid ""
"This example will show you how to create a WebSocket server that listen for "
"remote connections, and how to send and receive data."
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:145
msgid "This will print (when a client connects) something similar to this:"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:153
msgid "Advanced chat demo"
msgstr ""

#: ../../docs/tutorials/networking/websocket.rst:155
msgid ""
"A more advanced chat demo which optionally uses the multiplayer mid-level "
"abstraction and a high level multiplayer demo are available in the `godot "
"demo projects <https://github.com/godotengine/godot-demo-projects>`_ under "
"`networking/websocket_chat` and `networking/websocket_multiplayer`."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:4
#: ../../docs/tutorials/networking/webrtc.rst:21
msgid "WebRTC"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:7
msgid "HTML5, WebSocket, WebRTC"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:9
msgid ""
"One of Godot's great features is its ability to export to the HTML5/"
"WebAssembly platform, allowing your game to run directly in the browser when "
"a user visit your webpage."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:11
msgid ""
"This is a great opportunity for both demos and full games, but used to come "
"with some limitations. In the area of networking, browsers used to support "
"only HTTPRequests until recently, when first WebSocket and then WebRTC were "
"proposed as standards."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:16
msgid ""
"When the WebSocket protocol was standardized in December 2011, it allowed "
"browsers to create stable and bidirectional connections to a WebSocket "
"server. The protocol is quite simple, but a very powerful tool to send push "
"notifications to browsers, and has been used to implement chats, turn-based "
"games, etc."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:18
msgid ""
"WebSockets, though, still use a TCP connection, which is good for "
"reliability but not for latency, so not good for real-time applications like "
"VoIP and fast-paced games."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:23
msgid ""
"For this reason, since 2010, Google started working on a new technology "
"called WebRTC, which later on, in 2017, became a W3C candidate "
"recommendation. WebRTC is a much more complex set of specifications, and "
"relies on many other technologies behind the scenes (ICE, DTLS, SDP) to "
"provide fast, real-time, and secure communication between two peers."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:25
msgid ""
"The idea is to find the fastest route between the two peers and establish "
"whenever possible a direct communication (i.e. try to avoid a relaying "
"server)."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:27
msgid ""
"However, this comes at a price, which is that some media information must be "
"exchanged between the two peers before the communication can start (in the "
"form of Session Description Protocol - SDP strings). This usually takes the "
"form of a so-called WebRTC Signaling Server."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:31
msgid ""
"Peers connect to a signaling server (for example a WebSocket server) and "
"send their media information. The server then relays this information to "
"other peers, allowing them to establish the desired direct communication. "
"Once this step is done, peers can disconnect from the signaling server and "
"keep the direct Peer-to-Peer (P2P) connection open."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:34
msgid "Using WebRTC in Godot"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:36
msgid ""
"WebRTC is implemented in Godot via two main classes :ref:"
"`WebRTCPeerConnection <class_WebRTCPeerConnection>` and :ref:"
"`WebRTCDataChannel <class_WebRTCDataChannel>`, plus the multiplayer API "
"implementation :ref:`WebRTCMultiplayer <class_WebRTCMultiplayer>`. See "
"section on :ref:`high-level multiplayer <doc_high_level_multiplayer>` for "
"more details."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:38
msgid ""
"These classes are available automatically in HTML5, but **require an "
"external GDNative plugin on native (non-HTML5) platforms**. Check out the "
"`webrtc-native plugin repository <https://github.com/godotengine/webrtc-"
"native>`__ for instructions and to get the latest `release <https://github."
"com/godotengine/webrtc-native/releases>`__."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:41
msgid "Minimal connection example"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:43
msgid ""
"This example will show you how to create a WebRTC connection between two "
"peers in the same application. This is not very useful in real life, but "
"will give you a good overview of how a WebRTC connection is set up."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:99
msgid "Local signaling example"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:101
msgid ""
"This example expands on the previous one, separating the peers in two "
"different scenes, and using a :ref:`singleton <doc_singletons_autoload>` as "
"a signaling server."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:141
msgid "And now for the local signaling server:"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:143
msgid ""
"This local signaling server is supposed to be used as a :ref:`singleton "
"<doc_singletons_autoload>` to connect two peers in the same scene."
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:177
msgid "Then you can use it like this:"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:198
msgid "This will print something similar to this:"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:206
msgid "Remote signaling with WebSocket"
msgstr ""

#: ../../docs/tutorials/networking/webrtc.rst:208
msgid ""
"A more advanced demo using WebSocket for signaling peers and :ref:"
"`WebRTCMultiplayer <class_WebRTCMultiplayer>` is available in the `godot "
"demo projects <https://github.com/godotengine/godot-demo-projects>`_ under "
"`networking/webrtc_signaling`."
msgstr ""

#: ../../docs/tutorials/assetlib/index.rst:2
msgid "Asset Library"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:4
msgid "About the Asset Library"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:6
msgid ""
"The Godot Asset Library, otherwise known as the AssetLib, is a repository of "
"user-submitted Godot addons, scripts, tools and other resources, "
"collectively referred to as assets. They're available to all Godot users for "
"download directly from within the engine, but it can also be accessed at "
"Godot's `official website <https://godotengine.org/asset-library/asset>`_."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:11
msgid ""
"On the surface, the Asset Library might look and function similar to asset "
"stores available for other engines, such as Unity's Asset Store, or Unreal "
"Engine's Marketplace, where you can submit both freely-available assets, as "
"well as paid, commercial ones. In addition, often times such assets are "
"distributed under non-free, proprietary licenses, limiting what you can do "
"with them."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:17
msgid ""
"The Asset Library is different - all assets are distributed free of charge, "
"and under a host of open-source licenses (such as the MIT license, the GPL, "
"and the Boost Software License). This makes the AssetLib more similar to the "
"software repositories of a Linux distribution."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:21
msgid ""
"This set of pages will cover how to use the AssetLib (both from inside "
"Godot, and on the website), how you can submit your own assets, and what the "
"guidelines for submission are."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:24
msgid ""
"Please note that the AssetLib is relatively young - it may have various pain "
"points, bugs and usability issues. As with all Godot projects, the code "
"repository is available on `GitHub <https://github.com/godotengine/godot-"
"asset-library>`_, where you can submit pull requests and issues, so please "
"do not hesitate to visit it!"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:29
msgid "Types of assets"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:31
msgid ""
"Be aware that there are, broadly, two different types of assets you can post."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:33
msgid ""
"Assets labeled as \"Templates\", \"Projects\", or \"Demos\" appear under the "
"\"Templates\" tab in the Godot project manager. These assets are standalone "
"Godot projects that can run by themselves."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:37
msgid ""
"Other assets show up inside of the Godot editor under the \"AssetLib\" main "
"screen tab, next to \"2D\", \"3D\", and \"Script\". These assets are meant "
"to be downloaded and placed into an existing Godot project."
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:45
msgid "Can paid assets be uploaded to the asset library?"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:47
msgid ""
"Not to the official one, though in the future, there might be other asset "
"libraries which allow it. That said, you are allowed to monetize and sell "
"Godot assets outside the Asset Library."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:4
msgid "Using the AssetLib"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:7
msgid "On the website"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:12
msgid ""
"As mentioned before, you can access the web frontend of the AssetLib on "
"`Godot's official website <https://godotengine.org/asset-library/asset>`_, "
"and this is what it looks like when you first visit it:"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:18
msgid ""
"At the top, you see the **header**, which takes you to various other parts "
"of the AssetLib - at the moment, it's empty, as we are not logged in."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:22
msgid "Searching"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:24
msgid ""
"In the center is the **search bar + settings** section, and the **assets** "
"section below it - this lets you filter out certain kinds of assets based on "
"a host of criteria. These include the asset **category** (such as 2D tools, "
"scripts and demos), **engine version** they are intended for, **sorting "
"order** (by update date, by name, etc.) and **support level**."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:30
msgid ""
"While most other filter settings should be fairly self-explanatory, it's "
"worth going over what \"support level\" means in the Asset Library. "
"Currently there are three support levels, and each asset can belong to only "
"one."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:34
msgid ""
"**Official** assets are created and maintained by the official Godot Engine "
"developers. Currently, these include the official engine demos, which "
"showcase how various areas of the engine work."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:38
msgid ""
"**Community** assets are submitted and maintained by the members of the "
"Godot community."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:41
msgid ""
"**Testing** assets are works-in-progress, and may contain bugs and usability "
"issues. They are not recommended for use in serious projects, but you are "
"encouraged to download, test them, and submit issues to the original authors."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:45
msgid ""
"You can mix and match any of the search filters and criteria, and upon "
"clicking the Search button, receive the list of all assets in the Library "
"that match them."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:50
msgid ""
"Note that the search results are not updated in real-time, so you will have "
"to re-submit the search query each time you change the query settings."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:54
msgid "Breakdown of an asset"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:56
msgid ""
"Now let's take a look at what an asset's page looks like and what it "
"contains."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:60
msgid "Asset's thumbnail/icon."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:61
msgid "Asset's name."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:62
msgid "Current version number of the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:63
msgid "Asset's category, Godot version, and support status."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:64
msgid "Asset's original author/submitter."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:65
msgid "The license the asset is distributed under."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:66
msgid "The date of the asset's latest edit/update."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:67
msgid "A textual description of the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:68
msgid "Links related to the asset (download link, file list, issue tracker)."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:69
msgid "Images and videos showcasing the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:72
msgid "Registering and logging in"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:74
msgid ""
"In order to upload assets to the AssetLib, you need to be logged in, and to "
"do that, you need a registered user account. In the future, this may also "
"give you access to other features, such as commenting on or rating the "
"existing assets. You do *not* need to be logged in to browse and download "
"the assets."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:79
msgid "The login/registration page can be accessed from the AssetLib header."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:83
msgid ""
"From here, you can register your account, which requires a valid email "
"address, a username, and a (preferably strong) password."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:88
msgid "Then, you can use your username and password to log in."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:92
msgid ""
"This will change the look of the AssetLib header. Now you get access to a "
"handful of new functions:"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:95
msgid ""
"The feed, which shows a list of status updates on your submitted assets (and "
"possibly more in the future)."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:96
msgid "A list of your uploaded assets."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:97
msgid "The ability to submit new assets."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:99
msgid "|image6|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:101
msgid ""
"You can learn how to submit assets to the Library, and what the asset "
"submission guidelines are, in the next part of this tutorial, :ref:"
"`doc_uploading_to_assetlib`."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:105
msgid "In the editor"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:107
msgid ""
"You can also access the AssetLib directly from Godot. It is available from "
"two places - in the Project Manager's Templates tab, and inside of a "
"project, from the workspaces list."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:111
msgid "|image7|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:113
msgid "|image14|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:115
msgid ""
"Click on it, and Godot will fetch info about the assets from the AssetLib. "
"Once it's finished, you will see a window similar to what the AssetLib "
"website looks like, with some differences:"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:119
msgid "|image8|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:121
msgid ""
"Similarly to the web version of the AssetLib, here you can search for assets "
"by category, name, and sort them by factors such as name or edit date."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:124
msgid ""
"Notably, you can only fetch assets for the current version of Godot you are "
"running. Projects, Demos and Templates can be downloaded from from the "
"Project Manager view of the AssetLib. Addons (tools, scripts, materials "
"etc.) can be downloaded from the in-project AssetLib and added to the "
"current project. In addition, unlike when using the web frontend, the search "
"results are updated in real-time (you do not have to press Search after "
"every change to your search query for the changes to take place)."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:132
msgid ""
"In the future, you will be able to choose a different AssetLib provider to "
"fetch assets from (using the Site dropdown menu), however currently only the "
"official `Godot website <https://godotengine.org>`_ version of the AssetLib "
"is supported, as well as the version that may be running on your local "
"machine's web server (the localhost option)."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:138
msgid "When you click on an asset, you will see more information about it."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:140
msgid "|image9|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:142
msgid ""
"If you click on the Install button, Godot will fetch an archive of the "
"asset, and will track download progress of it at the bottom of the editor "
"window. If the download fails, you can retry it using the Retry button."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:146
msgid "|image10|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:148
msgid ""
"When it finishes, you can proceed to install it using the Install button. "
"This will bring up the Package Installer window."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:151
msgid "|image11|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:153
msgid ""
"Here you can see a list of all the files that will be installed. You can "
"tick off any of the files that you do not wish to install, and Godot will "
"also inform you about any problems with files that it cannot install. These "
"files will be shown in red, and hovering over them will show you a message "
"stating why it cannot be installed."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:159
msgid "|image12|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:161
msgid ""
"Once you are done, you can press the Install button, which will unzip all "
"the files in the archive, and import any assets contained therein, such as "
"images or 3D models. Once this is done, you should see a message stating "
"that the Package installation is complete."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:166
msgid "|image13|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:168
msgid ""
"You may also use the Import button to import asset archives obtained "
"elsewhere (such as downloading them directly from the AssetLib web "
"frontend), which will take you through the same package installation "
"procedure as with the assets downloaded directly via Godot that we just "
"covered."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:4
msgid "Submitting to the Asset Library"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:9
msgid ""
"This tutorial aims to serve as a guide on how you can submit your own assets "
"to the Godot Asset Library and share them with the Godot community."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:12
msgid ""
"As mentioned in the :ref:`doc_using_assetlib` document, in order to be able "
"to submit assets to the AssetLib, you need to have a registered account, and "
"be logged in."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:17
msgid "Submission guidelines"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:19
msgid ""
"Before submitting your asset, please ensure it follows all of the "
"requirements, and also consider following the recommendations."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:25
msgid ""
"Generally speaking, most assets people submit to the asset library are "
"accepted. However, in order for your asset to be accepted, there are a few "
"requirements your asset needs to meet to be approved."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:29
msgid ""
"The asset must work. If the asset doesn't run or otherwise doesn't work in "
"the specified Godot version, then it will be rejected."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:32
msgid ""
"The asset must have a proper **.gitignore** file. It's important to keep "
"redundant data out of the repository. `Here's a template. <https://github."
"com/github/gitignore/blob/master/Godot.gitignore>`_"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:36
msgid ""
"No submodules, or any submodules must be non-essential. GitHub does not "
"include submodules in the downloaded ZIP file, so if the asset needs the "
"contents of the submodule, your asset won't work."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:40
msgid ""
"The license needs to be correct. The license listed on the asset library "
"must match the license in the repository."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:43
msgid ""
"Use proper English for the name and description of your asset. This includes "
"using correct capitalization, and using full sentences in the description."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:47
msgid ""
"The icon link must be a direct link. For icons hosted on GitHub, the link "
"must start with \"raw.githubusercontent.com\", not \"github.com\"."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:51
msgid "Recommendations"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:53
msgid ""
"These things are not required for your asset to be approved, but if you "
"follow these recommendations, you can help make the asset library a better "
"place for all users."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:57
msgid ""
"Fix or suppress all script warnings. The warning system is there to help "
"identify issues with your code, but people using your asset don't need to "
"see them."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:61
msgid ""
"Make your code conform to the official style guides. Having a consistent "
"style helps other people read your code, and it also helps if other people "
"wish to contribute to your asset. See: the :ref:`doc_gdscript_styleguide` or "
"the :ref:`doc_c_sharp_styleguide`."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:66
msgid ""
"If your asset is a library for working with other files, consider including "
"example files in the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:69
msgid ""
"The icon should be a square, its aspect ratio should be 1:1. It should also "
"ideally have a minimum resolution of 64x64 pixels."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:72
msgid ""
"While the asset library allows more than just GitHub, consider hosting your "
"asset's source code on GitHub. Other services may not work reliably, and a "
"lack of familiarity can be a barrier to contributors."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:77
msgid "Submitting"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:79
msgid ""
"Once you are logged in, you will be able to head over to the \"Submit Assets"
"\" page of the AssetLib, which will look like this:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:84
msgid ""
"While it may look like a lot (and there is more as you scroll down), each "
"field is described in terms of what you should put in. We will nonetheless "
"go over what is required in the submission form here as well."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:89
msgid "**Asset Name**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:89
msgid ""
"The name of your asset. Should be a unique, descriptive title of what your "
"asset is."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:95
msgid "**Category**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:92
msgid ""
"The category that your asset belongs to, and will be shown in search "
"results. The category is split into **Addons** and **Projects**. In-editor, "
"assets of the Project type (Templates, Demos, Projects) only show up when "
"viewing the AssetLib from the Project Manager, while assets of the Addon "
"type will only be visible from inside a project."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:101
msgid "**Godot version**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:98
msgid ""
"The version of the engine that the asset works with. Currently, it's not "
"possible to have a single asset entry contain downloads for multiple engine "
"versions, so you may need to re-submit the asset multiple times, with an "
"entry for each Godot version it supports. This is particularly important "
"when dealing with major versions of the engine, such as Godot 2.x and Godot "
"3.x."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:108
msgid "**Version**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:104
msgid ""
"The version number of the asset. While you are free to choose and use any "
"versioning scheme that you like, you may want to look into something such as "
"`SemVer <https://semver.org>`_ if you want your asset's versioning scheme to "
"be clear and consistent. Note that there is also an internal version number, "
"incremented every time the asset download URL is changed or updated."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:113
msgid "**Repository host**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:111
msgid ""
"Assets uploaded to the AssetLib are not hosted on it directly. Instead, they "
"point to repositories hosted on third-party Git providers, such as GitHub, "
"GitLab or Bitbucket. This is where you choose which provider your asset "
"uses, so the site can compute the final download link."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:116
msgid "**Repository URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:116
msgid ""
"The URL to your asset's files/webpage. This will vary based on your choice "
"of provider, but it should look similar to `https://github.com/<user>/"
"<project>`."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:121
msgid "**Issues URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:119
msgid ""
"The URL to your asset's issue tracker. Again, this will differ from "
"repository host to repository host, but will likely look similar to `https://"
"github.com/<user>/<project>/issues`. You may leave this field empty if you "
"use your provider's issue tracker, and it's part of the same repository."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:125
msgid "**Download Commit**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:124
msgid ""
"The commit of the asset. For example, "
"`b1d3172f89b86e52465a74f63a74ac84c491d3e1`. The site computes the actual "
"download URL from this."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:129
msgid "**Icon URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:128
msgid ""
"The URL to your asset's icon (which will be used as a thumbnail in the "
"AssetLib search results and on the asset's page). Should be an image in "
"either the PNG or JPG format."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:134
msgid "**License**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:132
msgid ""
"The license under which you are distributing the asset. The list includes a "
"variety of free and open-source software licenses, such as GPL (v2 and v3), "
"MIT, BSD and Boost Software License. You can visit `OpenSource.org <https://"
"opensource.org>`_ for a detailed description of each of the listed licenses."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:140
msgid "**Description**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:137
msgid ""
"Finally, you can use the Description field for a textual overview of your "
"asset, its features and behavior, a changelog, et cetera. In the future, "
"formatting with Markdown will be supported, but currently, your only option "
"is plain text."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:142
msgid ""
"You may also include up to three video and/or image previews, which will be "
"shown at the bottom of the asset page. Use the \"Enable\" checkbox on each "
"of the preview submission boxes to enable them."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:146
msgid "**Type**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:147
msgid "Either an image, or a video."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:148
msgid "**Image/YouTube URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:149
msgid "Either a link to the image, or to a video, hosted on YouTube."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:153
msgid "**Thumbnail URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:151
msgid ""
"A URL to an image that will be used as a thumbnail for the preview. This "
"option will be removed eventually, and thumbnails will be automatically "
"computed instead."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:155
msgid ""
"Once you are done, hit Submit. Your asset will be entered into the pending "
"queue, which you can visit on the AssetLib `here <https://godotengine.org/"
"asset-library/asset/edit?&asset=-1>`_ . The approval process is manual and "
"may take up to a few days for your addon to be accepted (or rejected), so "
"please be patient! You will be informed when your asset is reviewed. If it "
"was rejected, you will be told why that may have been, and you will be able "
"to submit it again with the appropriate changes. You may have some luck "
"accelerating the approval process by messaging the moderators/assetlib "
"reviewers on IRC (the ``#godotengine-atelier`` channel on Freenode), or the "
"official Discord server."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:4
msgid "AR/VR primer"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:6
msgid ""
"This tutorial gives you a springboard into the world of AR and VR in the "
"Godot game engine."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:8
msgid ""
"A new architecture was introduced in Godot 3 called the AR/VR Server. On top "
"of this architecture, specific implementations are available as interfaces, "
"most of which are plugins based on GDNative. This tutorial focuses purely on "
"the core elements abstracted by the core architecture. This architecture has "
"enough features for you to create an entire VR experience that can then be "
"deployed for various interfaces. However, each platform often has some "
"unique features that are impossible to abstract. Such features will be "
"documented on the relevant interfaces and fall outside of the scope of this "
"primer."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:12
msgid "AR/VR server"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:14
msgid ""
"When Godot starts, each available interface will make itself known to the AR/"
"VR server. GDNative interfaces are setup as singletons; as long as they are "
"added to the list of GDNative singletons in your project, they will make "
"themselves known to the server."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:16
msgid ""
"You can use the function :ref:`get_interfaces() "
"<class_ARVRServer_method_get_interfaces>` to return a list of available "
"interfaces, but for this tutorial, we're going to use the :ref:`native "
"mobile VR interface <class_MobileVRInterface>` in our examples. This "
"interface is a straightforward implementation that uses the 3DOF sensors on "
"your phone for orientation and outputs a stereoscopic image to the screen. "
"It is also available in the Godot core and outputs to screen on desktop, "
"which makes it ideal for prototyping or a tutorial such as this one."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:18
msgid "To enable an interface, you execute the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:35
msgid ""
"This code finds the interface we wish to use, initializes it and, if that is "
"successful, binds the main viewport to the interface. This last step gives "
"some control over the viewport to the interface, which automatically enables "
"things like stereoscopic rendering on the viewport."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:37
msgid ""
"For our mobile VR interface, and any interface where the main input is "
"directly displayed on screen, the main viewport needs to be the viewport "
"where :ref:`arvr<class_Viewport_property_arvr>` is set to ``true``. But for "
"interfaces that render on an externally attached device, you can use a "
"secondary viewport. In the latter case, a viewport that shows its output on "
"screen will show an undistorted version of the left eye, while showing the "
"fully processed stereoscopic output on the device."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:39
msgid ""
"Finally, you should only initialize an interface once; switching scenes and "
"reinitializing interfaces will just introduce a lot of overhead. If you want "
"to turn the headset off temporarily, just disable the viewport or set :ref:"
"`arvr<class_Viewport_property_arvr>` to ``false`` on the viewport. In most "
"scenarios though, you wouldn't disable the headset once you're in VR, this "
"can be disconcerting to the gamer."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:42
msgid "New AR/VR nodes"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:44
msgid ""
"Three new node types have been added for supporting AR and VR in Godot and "
"one additional node type especially for AR. These are:"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:46
msgid ":ref:`ARVROrigin <class_ARVROrigin>` - our origin point in the world"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:47
msgid ""
":ref:`ARVRCamera <class_ARVRCamera>` - a special subclass of the camera, "
"which is positionally tracked"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:48
msgid ""
":ref:`ARVRController <class_ARVRController>` - a new spatial class, which "
"tracks the location of a controller"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:49
msgid ""
":ref:`ARVRAnchor <class_ARVRAnchor>` - an anchor point for an AR "
"implementation mapping a real world location into your virtual world"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:51
msgid ""
"The first two must exist in your scene for AR/VR to work and this tutorial "
"focuses purely on them."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:53
msgid ""
":ref:`ARVROrigin <class_ARVROrigin>` is an important node, you must have one "
"and only one of these somewhere in your scene. This node maps the center of "
"your real world tracking space to a location in your virtual world. "
"Everything else is positionally tracked in relation to this point. Where "
"this point lies exactly differs from one implementation to another, but the "
"best example to understand how this node works is to take a look at a room "
"scale location. While we have functions to adjust the point to center it on "
"the player by default, the origin point will be the center location of the "
"room you are in. As you physically walk around the room, the location of the "
"HMD is tracked in relation to this center position and the tracking is "
"mirror in the virtual world."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:55
msgid ""
"To keep things simple, when you physically move around your room, the ARVR "
"Origin point stays where it is, the position of the camera and controllers "
"will be adjusted according to your movements. When you move through the "
"virtual world, either through controller input or when you implement a "
"teleport system, it is the position of the origin point which you will have "
"to adjust."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:58
msgid ""
":ref:`ARVRCamera <class_ARVRCamera>` is the second node that must always be "
"a part of your scene and it must always be a child node of your origin node. "
"It is a subclass of Godot's normal camera. However, its position is "
"automatically updated each frame based on the physical orientation and "
"position of the HMD. Also due to the precision required for rendering to an "
"HMD or rendering an AR overlay over a real world camera, most of the "
"standard camera properties are ignored. The only properties of the camera "
"that are used are the near and far plane settings. The FOV, aspect ratio and "
"projection mode are all ignored."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:60
msgid ""
"Note that, for our native mobile VR implementation, there is no positional "
"tracking, only the orientation of the phone and by extension, the HMD is "
"tracked. This implementation artificially places the camera at a height (Y) "
"of 1.85."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:62
msgid ""
"Conclusion: your minimum setup in your scene to make AR or VR work should "
"look like this:"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:66
msgid ""
"And that's all you need to get started. Obviously, you need to add something "
"more into your scene, so there is something to see, but after that, you can "
"export the game to your phone of choice, pop it into a viewer and away you "
"go."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:69
msgid "Other things to consider"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:71
msgid ""
"There are a few other subjects that we need to briefly touch upon in this "
"primer that are important to know."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:73
msgid ""
"The first are our units. In normal 3D games, you don't have to think a lot "
"about units. As long as everything is at the same scale, a box sized 1 unit "
"by 1 unit by 1 unit can be any size from a cube you can hold in your hand to "
"something the size of a building. In AR and VR, this changes because things "
"in your virtual world are mapped to things in the real world. If you step 1 "
"meter forward in the real world, but you only move 1 cm forward in your "
"virtual world, you have a problem. The same with the position of your "
"controllers; if they don't appear in the right relative space, it breaks the "
"immersion for the player. Most VR platforms, including our AR/VR Server, "
"assume that 1 unit = 1 meter. The AR/VR server, however, has a property "
"that, for convenience, is also exposed on the ARVROrigin node called world "
"scale. For instance, setting this to a value of 10 changes our coordinate "
"system so 10 units = 1 meter."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:77
msgid ""
"Performance is another thing that needs to be carefully considered. "
"Especially VR taxes your game a lot more than most people realize. For "
"mobile VR, you have to be extra careful here, but even for desktop games, "
"there are three factors that make life extra difficult:"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:79
msgid ""
"You are rendering stereoscopic, two for the price of one. While not exactly "
"doubling the work load and with things in the pipeline such as supporting "
"the new MultiView OpenGL extension in mind, there still is an extra workload "
"in rendering images for both eyes"
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:80
msgid ""
"A normal game will run acceptably on 30fps and ideally manages 60fps. That "
"gives you a big range to play with between lower end and higher end "
"hardware. For any HMD application of AR or VR, however, 60fps is the "
"absolute minimum and you should target your games to run at a stable 90fps "
"to ensure your users don't get motion sickness right off the bat."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:81
msgid ""
"The high FOV and related lens distortion effect require many VR experiences "
"to render at double the resolution. Yes a VIVE may only have a resolution of "
"1080x1200 per eye, we're rendering each eye at 2160x2400 as a result. This "
"is less of an issue for most AR applications."
msgstr ""

#: ../../docs/tutorials/vr/vr_primer.rst:83
msgid ""
"All in all, the workload your GPU has in comparison with a normal 3D game is "
"a fair amount higher. While things are in the pipeline to improve this, such "
"as MultiView and foveated rendering, these aren't supported on all devices. "
"This is why you see many VR games using a more art style and if you pay "
"close attention to those VR games that go for realism, you'll probably "
"notice they're a bit more conservative on the effects or use some good old "
"optical trickery."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/index.rst:2
#, fuzzy
msgid "VR starter tutorial"
msgstr "מדריכים"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:4
#, fuzzy
msgid "VR starter tutorial part 1"
msgstr "מדריכים"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:11
msgid ""
"This tutorial will show you how to make a beginner VR game project in Godot."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:13
msgid ""
"Keep in mind, **one of the most important things when making VR content is "
"getting the scale of your assets correct**! It can take lots of practice and "
"iterations to get this right, but there are a few things you can do to make "
"it easier:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:16
msgid ""
"In VR, 1 unit is typically considered 1 meter. If you design your assets "
"around that standard, you can save yourself a lot of headache."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:17
msgid ""
"In your 3D modeling program, see if there is a way to measure and use real "
"world distances. In Blender, you can use the MeasureIt add-on; in Maya, you "
"can use the Measure Tool."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:18
msgid ""
"You can make rough models using a tool like `Google Blocks <https://vr."
"google.com/blocks/>`_, and then refine in another 3D modelling program."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:19
msgid ""
"Test often, as the assets can look dramatically different in VR than on a "
"flat screen!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:21
msgid "Throughout the course of this tutorial, we will cover:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:23
msgid "How to tell Godot to run in VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:24
msgid ""
"How to make a teleportation locomotion system that uses the VR controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:25
msgid ""
"How to make a artificial movement locomotion system that uses the VR "
"controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:26
msgid ""
"How to create a :ref:`RigidBody <class_RigidBody>`-based system that allows "
"for picking up, dropping, and throwing RigidBody nodes using the VR "
"controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:27
msgid "How to create simple destroyable target."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:28
msgid ""
"How to create some special :ref:`RigidBody <class_RigidBody>`-based objects "
"that can destroy the targets."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:30
msgid ""
"While this tutorial can be completed by beginners, it is highly advised to "
"complete :ref:`doc_your_first_game`, if you are new to Godot and/or game "
"development."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:34
msgid ""
"**Some experience with making 3D games is required** before going through "
"this tutorial series. This tutorial assumes you have experience with the "
"Godot editor, GDScript, and basic 3D game development. A OpenVR-ready "
"headset and two OpenVR-ready controllers are required."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:38
msgid ""
"This tutorial was written and tested using a Windows Mixed Reality headset "
"and controllers. This project has also been tested on the HTC Vive. Code "
"adjustments may be required for other VR Headsets, such as the Oculus Rift."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:41
msgid ""
"The Godot project for this tutorial is found on the `OpenVR GitHub "
"repository <https://github.com/GodotVR/godot_openvr_fps>`_. The starter "
"assets for this tutorial can be found in the releases section on the GitHub "
"repository. The starter assets contain some 3D models, sounds, scripts, and "
"scenes that are configured for this tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:44
msgid "**Credits for the assets provided**:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:46
msgid ""
"The sky panorama was created by `CGTuts <https://cgi.tutsplus.com/articles/"
"freebie-8-awesome-ocean-hdris--cg-5684>`_."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:48
msgid "The font used is Titillium-Regular"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:49
msgid "The font is licensed under the SIL Open Font License, Version 1.1"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:51
msgid ""
"The audio used are from several different sources, all downloaded from the "
"Sonniss #GameAudioGDC Bundle (`License PDF <https://sonniss.com/gdc-bundle-"
"license/>`_)"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:52
msgid ""
"The folders where the audio files are stored have the same name as folders "
"in the Sonniss audio bundle."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:54
msgid ""
"The OpenVR addon was created by `Bastiaan Olij <https://github.com/"
"BastiaanOlij>`_ and is released under the MIT license. It can be found both "
"on the `Godot Asset Library <https://godotengine.org/asset-library/"
"asset/150>`_ and on `GitHub <https://github.com/GodotVR/godot-openvr-"
"asset>`_. *3rd party code and libraries used in the OpenVR addon may be "
"under a different license.*"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:56
msgid ""
"The initial project, 3D models, and scripts were created by `TwistedTwigleg "
"<https://github.com/TwistedTwigleg>`_ and is released under the MIT license."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:58
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:16
msgid ""
"You can find the finished project on the `OpenVR GitHub repository <https://"
"github.com/GodotVR/godot_openvr_fps>`_."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:64
msgid ""
"If you have not already, go to the `OpenVR GitHub repository <https://github."
"com/GodotVR/godot_openvr_fps>`_ and download the \"Starter Assets\" file "
"from the releases. Once you have the starter assets downloaded, open up the "
"project in Godot."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:67
msgid ""
"The starter assets are not required to use the scripts provided in this "
"tutorial. The starter assets include several premade scenes and scripts that "
"will be used throughout the tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:70
msgid ""
"When the project is first loaded, the Game.tscn scene will be opened. This "
"will be the main scene used for the tutorial. It includes several nodes and "
"scenes already placed throughout the scene, some background music, and "
"several GUI-related :ref:`MeshInstance <class_MeshInstance>` nodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:75
msgid ""
"The GUI-related :ref:`MeshInstance <class_MeshInstance>` nodes already have "
"scripts attached to them. These scripts will set the texture of a :ref:"
"`Viewport <class_Viewport>` node to the albedo texture of the material of "
"the :ref:`MeshInstance <class_MeshInstance>` node. This is used to display "
"text within the VR project. Feel free to take a look at the script, ``GUI."
"gd``, if you want. We will not be going over how to to use :ref:`Viewport "
"<class_Viewport>` nodes for displaying UI on :ref:`MeshInstance "
"<class_MeshInstance>` nodes in this tutorial ."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:80
msgid ""
"If you are interested in how to use :ref:`Viewport <class_Viewport>` nodes "
"for displaying UI on :ref:`MeshInstance <class_MeshInstance>` nodes, see "
"the :ref:`doc_viewport_as_texture` tutorial. It covers how to use a :ref:"
"`Viewport <class_Viewport>` as a render texture, along with how to apply "
"that texture onto a :ref:`MeshInstance <class_MeshInstance>` node."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:85
msgid ""
"Before we jump into the tutorial, let's take a moment to talk about how the "
"nodes used for VR work."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:87
msgid ""
"The :ref:`ARVROrigin <class_ARVROrigin>` node is the center point of the VR "
"tracking system. The position of the :ref:`ARVROrigin <class_ARVROrigin>` is "
"the position the VR system considers the 'center' point on the floor. The :"
"ref:`ARVROrigin <class_ARVROrigin>` has a `world scale` property that "
"effects the size of the user within the VR scene. For this tutorial, it is "
"set to `1.4`, as the world was originally just a tad to big. As mentioned "
"earlier, keeping the scale relatively consistent is important in VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:92
msgid ""
"The :ref:`ARVRCamera <class_ARVRCamera>` is the player's headset and view "
"into the scene. The :ref:`ARVRCamera <class_ARVRCamera>` is offset on the Y "
"axis by the VR user's height, which will be important later when we add "
"teleportation locomotoin. If the VR system supports room tracking, then the :"
"ref:`ARVRCamera <class_ARVRCamera>` will move as the player moves. This "
"means that the :ref:`ARVRCamera <class_ARVRCamera>` is not guaranteed to be "
"in the same position as the :ref:`ARVROrigin <class_ARVROrigin>` node."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:96
msgid ""
"The :ref:`ARVRController <class_ARVRController>` node represents a VR "
"controller. The :ref:`ARVRController <class_ARVRController>` will follow the "
"position and rotation of the VR controller relative to the :ref:`ARVROrigin "
"<class_ARVROrigin>` node. All of the input for the VR controllers happens "
"through the :ref:`ARVRController <class_ARVRController>` node. An :ref:"
"`ARVRController <class_ARVRController>` node with an ``ID`` of ``1`` "
"represents the left VR controller, while an :ref:`ARVRController "
"<class_ARVRController>` controller with an ``ID`` of ``2`` represents the "
"right VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:101
msgid "To summarize:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:103
msgid ""
"The :ref:`ARVROrigin <class_ARVROrigin>` node is the center of the VR "
"tracking system and is positioned on the floor."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:105
msgid ""
"The :ref:`ARVRCamera <class_ARVRCamera>` is the player's VR headset and view "
"into the scene."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:107
msgid ""
"The :ref:`ARVRCamera <class_ARVRCamera>` node is offset on the Y axis by the "
"user's height."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:109
msgid ""
"If the VR system supports room tracking, then the :ref:`ARVRCamera "
"<class_ARVRCamera>` node may be offset on the X and Z axes as the player "
"moves."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:111
msgid ""
"The :ref:`ARVRController <class_ARVRController>` nodes represent the VR "
"controllers and handle all of the input from the VR controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:115
msgid "Starting VR"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:117
msgid ""
"Now that we have gone over the VR nodes, let's start working on the project. "
"While in ``Game.tscn``, select the ``Game`` node and make a new script "
"called ``Game.gd``. In the ``Game.gd`` file, add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:157
msgid "Let's go over what this code does."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:161
msgid ""
"In the ``_ready`` function, we first get the OpenVR VR interface using the "
"``find_interface`` function in the :ref:`ARVRServer <class_ARVRServer>` and "
"assign it to a variable called `VR`. If the :ref:`ARVRServer "
"<class_ARVRServer>` finds an interface with the name OpenVR, it will return "
"it, otherwise it will return ``null``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:164
msgid ""
"The OpenVR VR interface is not included with Godot by default. You will need "
"to download the OpenVR asset from the `Asset Library <https://godotengine."
"org/asset-library/asset/150>`_ or `GitHub <https://github.com/GodotVR/godot-"
"openvr-asset>`_."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:167
msgid ""
"The code then combines two conditionals, one to check if the `VR` variable "
"is NOT null (``if VR``) and another calls the initialize function, which "
"returns a boolean based on whether the OpenVR interface was able to "
"initialize or not. If both of these conditionals return true, then we can "
"turn the main Godot :ref:`Viewport <class_Viewport>` into an ARVR viewport."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:171
msgid ""
"If the VR interface initialized successfully, we then get the root :ref:"
"`Viewport <class_Viewport>` and set the `arvr` property to ``true``. This "
"will tell Godot to use the initialized ARVR interface to drive the :ref:"
"`Viewport <class_Viewport>` display."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:174
msgid ""
"Finally, we disable VSync so the Frames Per Second (FPS) is not capped by "
"the computer monitor. After this we tell Godot to render at ``90`` frames "
"per second, which is the standard for most VR headsets. Without disabling "
"VSync, the normal computer monitor may limit the frame rate of the VR "
"headset to the frame rate of the computer monitor."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:177
msgid ""
"In the project settings, under the ``Physics->Common`` tab, the physics FPS "
"has been set to ``90``. This makes the physics engine run at the same frame "
"rate as the VR display, which makes physics reactions look smoother when in "
"VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:182
msgid ""
"That is all we need to do for Godot to launch OpenVR within the project! Go "
"ahead and give it a try if you want. Assuming everything works, you will be "
"able to look around the world. If you have a VR headset with room tracking, "
"then you will be able to move around the scene within the limits of the room "
"tracking."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:186
#, fuzzy
msgid "Creating the controllers"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:190
msgid ""
"Right now all that the VR user can do is stand around, which isn't really "
"what we are going for unless we are working on a VR film. Lets write the "
"code for the VR controllers. We are going to write all the code for the VR "
"controllers in one go, so the code is rather long. That said, once we are "
"finished you will be able to teleport around the scene, artificially move "
"using the touchpad/joystick on the VR controller, and be able to pick up, "
"drop, and throw :ref:`RigidBody <class_RigidBody>`-based nodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:195
msgid ""
"First we need to open the scene used for the VR controllers. "
"``Left_Controller.tscn`` or ``Right_Controller.tscn``. Let's briefly go over "
"how the scene is setup."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:198
msgid "How the VR controller scene is setup"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:200
msgid ""
"In both scenes the root node is a ARVRController node. The only difference "
"is that the ``Left_Controller`` scene has the ``Controller Id`` property set "
"to ``1`` while the ``Right_Controller`` has the ``Controller Id`` property "
"set to ``2``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:203
msgid ""
"The :ref:`ARVRServer <class_ARVRServer>` attempts to use these two IDs for "
"the left and right VR controllers. For VR systems that support more than 2 "
"controllers/tracked-objects, these IDs may need adjusting."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:206
msgid ""
"Next is the ``Hand`` :ref:`MeshInstance <class_MeshInstance>` node. This "
"node is used to display the hand mesh that will be used when the VR "
"controller is not holding onto a :ref:`RigidBody <class_RigidBody>` node. "
"The hand in the ``Left_Controller`` scene is a left hand, while the hand on "
"the ``Right_Controller`` scene is a right hand."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:209
msgid ""
"The node named ``Raycast`` is a :ref:`Raycast <class_Raycast>` node that is "
"used for aiming where to teleport to when the VR controller is teleporting. "
"The length of the :ref:`Raycast <class_Raycast>` is set to ``-16`` on the Y "
"axis and is rotated so that it points out of the pointer finger of the hand. "
"The ``Raycast`` node has a single child node, ``Mesh``, that is a :ref:"
"`MeshInstance <class_MeshInstance>`. This is used for visually showing where "
"the teleportation :ref:`Raycast <class_Raycast>` is aiming."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:213
msgid ""
"The node named ``Area`` is a :ref:`Area <class_Area>` node will be used for "
"grabbing :ref:`RigidBody <class_RigidBody>`-based nodes when the VR "
"controller grab mode is set to ``AREA``. The ``Area`` node has a single "
"child node, ``CollisionShape``, that defines a sphere :ref:`CollisionShape "
"<class_CollisionShape>`. When the VR controller is not holding any objects "
"and the grab button is pressed, the first :ref:`RigidBody <class_RigidBody>`-"
"based node within the ``Area`` node will be picked up."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:217
msgid ""
"Next is a :ref:`Position3D <class_Position3D>` node called ``Grab_Pos``. "
"This is used to define the position that grabbed :ref:`RigidBody "
"<class_RigidBody>` nodes will follow then they are held by the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:220
msgid ""
"A large :ref:`Area <class_Area>` node called ``Sleep_Area`` is used to "
"disable sleeping for any RigidBody nodes within its :ref:`CollisionShape "
"<class_CollisionShape>`, simple called ``CollisionShape``. This is needed "
"because if a :ref:`RigidBody <class_RigidBody>` node falls asleep, then the "
"VR controller will be unable to grab it. By using ``Sleep_Area``, we can "
"write code that makes any :ref:`RigidBody <class_RigidBody>` node within it "
"not able to sleep, therefore allowing the VR controller to grab it."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:224
msgid ""
"An :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node called "
"``AudioStreamPlayer3D`` has a sound loaded that we will use when an object "
"has been picked up, dropped or thrown by the VR controller. While this is "
"not necessary for the functionality of the VR controller, it makes grabbing "
"and dropping objects feel more natural."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:227
msgid ""
"Finally, the last nodes are the ``Grab_Cast`` node and it's only child node, "
"``Mesh``. The ``Grab_Cast`` node will be used for grabbing :ref:`RigidBody "
"<class_RigidBody>`-based nodes when the VR controller grab mode is set to "
"``RAYCAST``. This will allow the VR controller to grab objects that are just "
"slightly out of reach using a Raycast. The ``Mesh`` node is used for "
"visually showing where the teleportation :ref:`Raycast <class_Raycast>` is "
"aiming."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:231
msgid ""
"That is a quick overview of how the VR controller scenes are setup, and how "
"we will be using the nodes to provide the functionality for them. Now that "
"we have looked at the VR controller scene, let's write the code that will "
"drive them."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:235
msgid "The code for the VR controllers"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:237
msgid ""
"Select the root node of the scene, either ``Right_Controller`` or "
"``Left_Controller``, and make a new script called ``VR_Controller.gd``. Both "
"scenes will be using the same script, so it doesn't matter which you use "
"first. With ``VR_Controller.gd`` opened, add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:240
msgid ""
"You can copy and paste the code from this page directly into the script "
"editor."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:244
msgid ""
"To convert the spaces to tabs in the script editor, click the ``Edit`` menu "
"and select ``Convert Indent To Tabs``. This will convert all the spaces into "
"tabs. You can select ``Convert Indent To Spaces`` to convert tabs back into "
"spaces."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:535
msgid ""
"This is quite a bit of code to go through. Let's go through what the code "
"does step-by-step."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:538
msgid "Explaining the VR controller code"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:540
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:84
msgid "First, let's go through all the class variables in the script:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:542
msgid ""
"``controller_velocity``: A variable to hold a rough approximation of the VR "
"controller's velocity."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:543
msgid ""
"``prior_controller_position``: A variable to hold the VR controller's last "
"position in 3D space."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:544
msgid ""
"``prior_controller_velocities``: An Array to hold the last 30 calculated VR "
"controller velocities. This is used to smooth the velocity calculations over "
"time."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:545
msgid ""
"``held_object``: A variable to hold a reference to the object the VR "
"controller is holding. If the VR controller is not holding any objects, this "
"variable will be ``null``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:546
msgid ""
"``held_object_data``: A dictionary to hold data for the :ref:`RigidBody "
"<class_RigidBody>` node being held by the VR controller. This is used to "
"reset the :ref:`RigidBody <class_RigidBody>`'s data when it is no longer "
"held."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:547
msgid ""
"``grab_area``: A variable to hold the :ref:`Area <class_Area>` node used to "
"grab objects with the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:548
msgid ""
"``grab_raycast``: A variable to hold the :ref:`Raycast <class_Raycast>` node "
"used to grab objects with the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:549
msgid ""
"``grab_mode``: A variable to define the grab mode the VR controller is "
"using. There are only two modes for grabbing objects in this tutorial, "
"``AREA`` and ``RAYCAST``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:550
msgid ""
"``grab_pos_node``: A variable to hold the node that will be used to update "
"the position and rotation of held objects."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:551
msgid ""
"``hand_mesh``: A variable to hold the :ref:`MeshInstance "
"<class_MeshInstance>` node that contains the hand mesh for the VR "
"controller. This mesh will be shown when the VR controller is not holding "
"anything."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:552
msgid ""
"``hand_pickup_drop_sound``: A variable to hold the :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` node that contains the pickup/drop sound."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:553
msgid ""
"``teleport_pos``: A variable to hold the position the player will be "
"teleported to when the VR controller teleports the player."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:554
msgid ""
"``teleport_mesh``: A variable to hold the :ref:`MeshInstance "
"<class_MeshInstance>` node used to show where the player is teleporting to."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:555
msgid ""
"``teleport_button_down``: A variable used to track whether the controller's "
"teleport button is held down. This will be used to detect if this VR "
"controller is trying to teleport the player."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:556
msgid ""
"``teleport_raycast``: A variable to hold the :ref:`Raycast <class_Raycast>` "
"node used to calculate the teleport position. This node also has a :ref:"
"`MeshInstance <class_MeshInstance>` that acts as a 'laser sight' for aiming."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:557
msgid ""
"``CONTROLLER_DEADZONE``: A constant to define the deadzone for both the "
"trackpad and the joystick on the VR controller. See the note below for more "
"information."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:558
msgid ""
"``MOVEMENT_SPEED``: A constant to define the speed the player moves at when "
"using the trackpad/joystick to move artificially."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:559
msgid ""
"``CONTROLLER_RUMBLE_FADE_SPEED``: A constant to define how fast the VR "
"controller rumble fades."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:560
msgid ""
"``directional_movement``: A variable to hold whether this VR controller is "
"moving the player using the touchpad/joystick."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:562
msgid ""
"You can find a great article explaining all about how to handle touchpad/"
"joystick dead zones `here <https://web.archive.org/web/20191208161810/http://"
"www.third-helix.com/2013/04/12/doing-thumbstick-dead-zones-right.html>`__."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:564
msgid ""
"We are using a translated version of the scaled radial dead zone code "
"provided in that article for the VR controller's joystick/touchpad. The "
"article is a great read, and I highly suggest giving it a look!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:567
msgid ""
"That is quite a few class variables. Most of them are used to hold "
"references to nodes we will need throughout the code. Next let's start "
"looking at the functions, starting with the ``_ready`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:573
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:98
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:286
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:684
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:858
msgid "``_ready`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:575
msgid ""
"First we tell Godot to silence the warnings about not using the values "
"returned by the ``connect`` function. We will not need the returned values "
"for this tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:578
msgid ""
"Next we get the :ref:`Raycast <class_Raycast>` node we are going to use for "
"determining the position for teleporting and assign it to the "
"``teleport_raycast`` variable. We then get the :ref:`MeshInstance "
"<class_MeshInstance>` node that we will use to show where the player will be "
"teleporting to. The node we are using for teleporting is a child of the "
"``Game`` scene. We do this so the teleport mesh node is not effected by "
"changes in the VR controller, and so the teleport mesh can be used by both "
"VR controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:582
msgid ""
"Then the ``teleport_button_down`` variable is set to false, ``teleport_mesh."
"visible`` is set to ``false``, and ``teleport_raycast.visible`` is set to "
"``false``. This sets up the variables for teleporting the player into their "
"initial, not teleporting the player, state."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:585
msgid ""
"The code then gets the ``grab_area`` node, the ``grab_raycast`` node, and "
"the ``grab_pos_node`` node and assigns them all to their respective "
"variables for use later."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:587
msgid ""
"Next the ``grab_mode`` is set to ``AREA`` so the VR controller will attempt "
"to grab objects using the :ref:`Area <class_Area>` node defined in "
"``grab_area`` when the VR controller's grab/grip button is pressed. We also "
"set the ``grab_raycast`` node's ``visible`` property to ``false`` so the "
"'laser sight' child node of ``grab_raycast`` is not visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:590
msgid ""
"After that we connect the ``body_entered`` and ``body_exited`` signals from "
"the ``Sleep_Area`` node in the VR controller to the ``sleep_area_entered`` "
"and ``sleep_area_exited`` functions. The ``sleep_area_entered`` and "
"``sleep_area_exited`` functions will be used to make :ref:`RigidBody "
"<class_RigidBody>` nodes unable to sleep when nearby the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:593
msgid ""
"Then the ``hand_mesh`` and ``hand_pickup_drop_sound`` nodes are gotten and "
"assigned them to their respective variables for use later."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:595
msgid ""
"Finally, the ``button_pressed`` and ``button_release`` signals in the :ref:"
"`ARVRController <class_ARVRController>` node, which the VR controller "
"extends, are connected to the ``button_pressed`` and ``button_released`` "
"functions respectively. This means that when a button on the VR controller "
"is pressed or released, the ``button_pressed`` or ``button_released`` "
"functions defined in this script will be called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:601
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:106
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:292
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:694
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:868
msgid "``_physics_process`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:603
msgid ""
"First we check to see if the ``rumble`` variable is more than zero. If the "
"``rumble`` variable, which is a property of the :ref:`ARVRController "
"<class_ARVRController>` node, is more than zero then the VR controller "
"rumbles."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:606
msgid ""
"If the ``rumble`` variable is more than zero, then we reduce the rumble by "
"``CONTROLLER_RUMBLE_FADE_SPEED`` every second by subtracting "
"``CONTROLLER_RUMBLE_FADE_SPEED`` multiplied by delta. There is then a ``if`` "
"condition to check if ``rumble`` is less than zero, which sets ``rumble`` to "
"zero if its value is less than zero."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:609
msgid ""
"This small section of code is all we need for reducing the VR controller's "
"rumble. Now when we set ``rumble`` to a value, this code will automatically "
"make it fade over time."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:613
msgid ""
"The first section of code checks to see if the ``teleport_button_down`` "
"variable is equal to ``true``, which means this VR controller is trying to "
"teleport."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:615
msgid ""
"If ``teleport_button_down`` is equal to ``true``, we force the "
"``teleport_raycast`` :ref:`Raycast <class_Raycast>` node to update using the "
"``force_raycast_update`` function. The ``force_raycast_update`` function "
"will update the properties within the :ref:`Raycast <class_Raycast>` node "
"with the latest version of the physics world."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:618
msgid ""
"The code then checks to see if the ``teleport_raycast`` collided with "
"anything by checking of the ``is_colliding`` function in "
"``teleport_raycast`` is true. If the :ref:`Raycast <class_Raycast>` collided "
"with something, we then check to see if the :ref:`PhysicsBody "
"<class_PhysicsBody>` the raycast collided with is a :ref:`StaticBody "
"<class_StaticBody>` or not. We then check to see if the collision normal "
"vector returned by the raycast is greater than or equal to ``0.85`` on the Y "
"axis."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:622
msgid ""
"We do this because we do not want the user to be able to teleport onto "
"RigidBody nodes and we only want the player to be able to teleport on floor-"
"like surfaces."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:624
msgid ""
"If all these conditions are met, then we assign the ``teleport_pos`` "
"variable to the ``get_collision_point`` function in ``teleport_raycast``. "
"This will assign ``teleport_pos`` to the position the raycast collided at in "
"world space. We then move the ``teleport_mesh`` to the world position stored "
"in ``teleport_pos``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:627
msgid ""
"This section of code will get the position the player is aiming at with the "
"teleportation raycast and update the teleportation mesh, giving a visual "
"update on where the user will be teleporting to when the release the "
"teleport button."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:632
msgid ""
"The next section of code first checks to see if the VR controller is active "
"through the ``get_is_active`` function, which is defined by :ref:"
"`ARVRController <class_ARVRController>`. If the VR controller is active, "
"then it calls the ``_physics_process_update_controller_velocity`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:635
msgid ""
"The ``_physics_process_update_controller_velocity`` function will calculate "
"the VR controller's velocity through changes in position. It is not perfect, "
"but this process gets a rough idea of the velocity of the VR controller, "
"which is fine for the purposes of this tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:640
msgid ""
"The next section of code checks to see if the VR controller is holding an "
"object by checking to see if the ``held_object`` variable is not equal to "
"``null``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:642
msgid ""
"If the VR controller is holding an object, we first store it's scale in a "
"temporary variable called ``held_scale``. We then set the "
"``global_transform`` of the held object to the ``global_transform`` of the "
"``held_object`` node. This will make the held object have the same position, "
"rotation, and scale of the ``grab_pos_node`` node in world space."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:645
msgid ""
"However, because we do not want the held object to change in scale when it "
"is grabbed, we need to set the ``scale`` property of the ``held_object`` "
"node back to ``held_scale``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:647
msgid ""
"This section of code will keep the held object in the same position and "
"rotation as the VR controller, keeping it synced with the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:651
msgid ""
"Finally, the last section of code simply calls the "
"``_physics_process_directional_movement`` function. This function contains "
"all the code for moving the player when the touchpad/joystick on the VR "
"controller moves."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:656
msgid ""
"``_physics_process_update_controller_velocity`` function step-by-step "
"explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:658
msgid ""
"First this function resets the ``controller_velocity`` variable to zero :ref:"
"`Vector3 <class_Vector3>`."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:662
msgid ""
"Then we check to see if there are any stored/cached VR controller velocities "
"saved in the ``prior_controller_velocities`` array. We do this by checking "
"to see if the ``size()`` function returns a value greater than ``0``. If "
"there are cached velocities within ``prior_controller_velocities``, then we "
"iterate through each of the stored velocities using a ``for`` loop."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:665
msgid ""
"For each of the cached velocities, we simply add its value to "
"``controller_velocity``. Once the code has gone through all of the cached "
"velocities in ``prior_controller_velocities``, we divide "
"``controller_velocity`` by the size of the ``prior_controller_velocities`` "
"array, which will give us the combined velocity value. This helps take the "
"previous velocities into account, making the direction of the controller's "
"velocity more accurate."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:671
msgid ""
"Next we calculate the change in position the VR controller has taken since "
"the last ``_physics_process`` function call. We do this by subtracting "
"``prior_controller_position`` from the global position of the VR controller, "
"``global_transform.origin``. This will give us a :ref:`Vector3 "
"<class_Vector3>` that points from the position in "
"``prior_controller_position`` to the current position of the VR controller, "
"which we store in a variable called ``relative_controller_position``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:675
msgid ""
"Next we add the change in position to ``controller_velocity`` so the latest "
"change in position is taken into account in the velocity calculation. We "
"then add ``relative_controller_position`` to ``prior_controller_velocities`` "
"so it can be taken into account on the next calculation of the VR "
"controller's velocity."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:678
msgid ""
"Then ``prior_controller_position`` is updated with the global position of "
"the VR controller, ``global_transform.origin``. We then divide "
"``controller_velocity`` by ``delta`` so the velocity is higher, giving "
"results like those we expect, while still being relative to the amount of "
"time that has passed. It is not a perfect solution, but the results look "
"decent most of the time and for the purposes of this tutorial, it is good "
"enough."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:682
msgid ""
"Finally, the function checks to see if the ``prior_controller_velocities`` "
"has more than ``30`` velocities cached by checking if the ``size()`` "
"function returns a value greater than ``30``. If there are more than ``30`` "
"cached velocities stored in ``prior_controller_velocities``, then we simply "
"remove the oldest cached velocity by calling the ``remove`` function and "
"passing in a index position of ``0``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:688
msgid ""
"What this function ultimately does is that it gets a rough idea of the VR "
"controller's velocity by calculating the VR controller's relative changes in "
"position over the last thirty ``_physics_process`` calls. While this is not "
"perfect, it gives a decent idea of how fast the VR controller is moving in "
"3D space."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:693
msgid ""
"``_physics_process_directional_movement`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:695
msgid ""
"First this function gets the axes for the trackpad and the joystick and "
"assigns them to :ref:`Vector2 <class_Vector2>` variables called "
"``trackpad_vector`` and ``joystick_vector`` respectively."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:697
msgid ""
"You may need to remap the joystick and/or touchpad index values depending on "
"your VR headset and controller. The inputs in this tutorial are the index "
"values of a Windows Mixed Reality headset."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:700
msgid ""
"Then ``trackpad_vector`` and ``joystick_vector`` have their deadzones "
"account for. The code for this is detailed in the article below, with slight "
"changes as the code is converted from C# to GDScript."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:703
msgid ""
"Once the ``trackpad_vector`` and ``joystick_vector`` variables have had "
"their deadzones account for, the code then gets the forward and right "
"direction vectors relative to the global transform of the :ref:`ARVRCamera "
"<class_ARVRCamera>`. What this does is that it gives us vectors that point "
"forward and right relative to the rotation of the user camera, the :ref:"
"`ARVRCamera <class_ARVRCamera>`, in world space. These vectors point in the "
"same direction of the blue and red arrows when you select an object in the "
"Godot editor with the ``local space mode`` button enabled. The forward "
"direction vector is stored in a variable called ``forward_direction``, while "
"the right direction vector is stored in a variable called "
"``right_direction``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:709
msgid ""
"Next the code adds the ``trackpad_vector`` and ``joystick_vector`` variables "
"together and normalizes the results using the ``normalized`` function. This "
"gives us the combined movement direction of both input devices, so we can "
"use a single :ref:`Vector2 <class_Vector2>` for moving the user. We assign "
"the combined direction to a variable called ``movement_vector``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:712
msgid ""
"Then we calculate the distance the user will move forward, relative to the "
"forward direction stored in ``forward_direction``. To calculate this, we "
"multiply ``forward_direction`` by ``movement_vector.x``, ``delta``, and "
"``MOVEMENT_SPEED``. This will give us the distance the user will move "
"forward when the trackpad/joystick is pushed forward or backwards. We assign "
"this to a variable called ``movement_forward``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:716
msgid ""
"We do a similar calculation for the distance the user will move right, "
"relative to the right direction stored in ``right_direction``. To calculate "
"the distance the user will move right, we multiply ``right_direction`` by "
"``movement_vector.y``, ``delta``, and ``MOVEMENT_SPEED``. This will give us "
"the distance the user will move right when the trackpad/joystick is pushed "
"right or left. We assign this to a variable called ``movement_right``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:720
msgid ""
"Next we remove any movement on the ``Y`` axis of ``movement_forward`` and "
"``movement_right`` by assigning their ``Y`` values to ``0``. We do this so "
"the user cannot fly/fall simply by moving the trackpad or joystick. Without "
"doing this, the player could fly in the direction they are facing."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:723
msgid ""
"Finally, we check to see if the ``length`` function on ``movement_right`` or "
"``movement_forward`` is greater than ``0``. If it is, then we need to move "
"the user. To move the user, we perform a global translation to the :ref:"
"`ARVROrigin <class_ARVROrigin>` node using ``get_parent().global_translate`` "
"and pass in the ``movement_right`` variable with the ``movement_forward`` "
"variable added to it. This will move the player in the direction the "
"trackpad/joystick is pointing, relative to the rotation of the VR headset. "
"We also set the ``directional_movement`` variable to ``true`` so the code "
"knows this VR controller is moving the player."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:728
msgid ""
"If the ``length`` function on ``movement_right`` or ``movement_forward`` is "
"less than or equal to ``0``, then we simply set the ``directional_movement`` "
"variable to ``false`` so the code knows this VR controller is not moving the "
"player."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:734
msgid ""
"What this function ultimately does is takes the input from the VR "
"controller's trackpad and joystick and moves the player in the direction the "
"player is pushing them. Movement is relative to the rotation of the VR "
"headset, so if the player pushes forward and turns their head to the left, "
"they will move to the left."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:739
msgid "``button_pressed`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:741
msgid ""
"This function checks to see if the VR button that was just pressed is equal "
"to one of the VR buttons used in this project. The ``button_index`` variable "
"is passed in by the ``button_pressed`` signal in :ref:`ARVRController "
"<class_ARVRController>`, which we connected in the ``_ready`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:744
msgid ""
"There are only three buttons we are looking for in this project: the trigger "
"button, the grab/grip button, and the menu button."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:746
msgid ""
"You may need to remap these button index values depending on your VR headset "
"and controller. The inputs in this tutorial are the index values of a "
"Windows Mixed Reality headset."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:749
msgid ""
"First we check if the ``button_index`` is equal to ``15``, which should map "
"to the trigger button on the VR controller. If the button pressed is the "
"trigger button, then the ``_on_button_pressed_trigger`` function is called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:752
msgid ""
"If the ``button_index`` is equal to ``2``, then the grab button was just "
"pressed. If the button pressed is the grab button, the "
"``_on_button_pressed_grab`` function is called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:754
msgid ""
"Finally, if the ``button_index`` is equal to ``1``, then the menu button was "
"just pressed. If the button pressed is the menu button, the "
"``_on_button_pressed_menu`` function is called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:758
msgid "``_on_button_pressed_trigger`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:760
msgid ""
"First this function checks to see if the VR controller is not holding by "
"checking if ``held_object`` is equal to ``null``. If the VR controller is "
"not holding anything, then we assume that the trigger press on the VR "
"controller was for teleporting. We then make sure that ``teleport_mesh."
"visible`` is equal to ``false``. We use this to tell if the other VR "
"controller is trying to teleport or not, as ``teleport_mesh`` will be "
"visible if the other VR controller is teleporting."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:764
msgid ""
"If ``teleport_mesh.visible`` is equal to ``false``, then we can teleport "
"with this VR controller. We set the ``teleport_button_down`` variable to "
"``true``, set ``teleport_mesh.visible`` to true, and set ``teleport_raycast."
"visible`` to ``true``. This will tell the code in ``_physics_process`` that "
"this VR controller is going to teleport, it will make the ``teleport_mesh`` "
"visible so the user knows where the are teleporting to, and will make "
"``teleport_raycast`` visible to the player has a 'laser sight' they can use "
"to aim the teleportation pos."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:771
msgid ""
"If ``held_object`` is not equal to ``null``, then the VR controller is "
"holding something. We then check to see if the object that is being held, "
"``held_object``, extends a class called ``VR_Interactable_Rigidbody``. we "
"have not made ``VR_Interactable_Rigidbody`` yet, but "
"``VR_Interactable_Rigidbody`` will be a custom class we will use on all of "
"the special/custom :ref:`RigidBody <class_RigidBody>`-based nodes in the "
"project."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:775
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:850
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:874
msgid ""
"Don't worry, we will cover ``VR_Interactable_Rigidbody`` after this section!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:777
msgid ""
"If the ``held_object`` extends ``VR_Interactable_Rigidbody``, then we call "
"the ``interact`` function, so the held object can do whatever it is supposed "
"to do when the trigger is pressed and the object is held by the VR "
"controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:782
msgid "``_on_button_pressed_grab`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:784
msgid ""
"First this function checks to see if ``teleport_button_down`` is equal to "
"``true``. If it is, then it calls ``return``. We do this because we do not "
"want the user to be able to pick up objects while teleporting."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:787
msgid ""
"Then we check to see if the VR controller is currently not holding anything "
"by checking if ``held_object`` is equal to ``null``. If the VR controller is "
"not holding anything, then the ``_pickup_rigidbody`` function is called. If "
"the VR controller is holding something, ``held_object`` is not equal to "
"``null``, then the ``_throw_rigidbody`` function is called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:790
msgid ""
"Finally, the pick-up/drop sound is played by calling the ``play`` function "
"on ``hand_pickup_drop_sound``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:794
msgid "``_pickup_rigidbody`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:796
msgid ""
"First the function makes a variable called ``rigid_body``, which we'll be "
"using to store the :ref:`RigidBody <class_RigidBody>` that the VR controller "
"is going to pick up, assuming there is a RigidBody to pick up."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:801
msgid ""
"Then the function checks to see if the ``grab_mode`` variable is equal to "
"``AREA``. If it is, then it gets all of the :ref:`PhysicsBody "
"<class_PhysicsBody>` nodes within the ``grab_area`` using the "
"``get_overlapping_bodies`` functions. This function will return an array of :"
"ref:`PhysicsBody <class_PhysicsBody>` nodes. We assign the array of :ref:"
"`PhysicsBody <class_PhysicsBody>` to a new variable called ``bodies``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:805
msgid ""
"We then check to see if the length of the ``bodies`` variable is more than "
"``0``. If it is, we go through each of the :ref:`PhysicsBody "
"<class_PhysicsBody>` nodes in ``bodies`` using a for loop."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:807
msgid ""
"For each :ref:`PhysicsBody <class_PhysicsBody>` node, we check if it is, or "
"extends, a :ref:`RigidBody <class_RigidBody>` node using ``if body is "
"RigidBody``, which will return ``true`` if the :ref:`PhysicsBody "
"<class_PhysicsBody>` node is or extends the :ref:`RigidBody "
"<class_RigidBody>` node. If the object is a :ref:`RigidBody "
"<class_RigidBody>`, then we check to make sure there is not a variable/"
"constant called ``NO_PICKUP`` defined in the body. We do this because if you "
"want to have :ref:`RigidBody <class_RigidBody>` nodes that cannot be picked "
"up, all you have to do is define a constant/variable called ``NO_PICKUP`` "
"and the VR controller will be unable to pick it up. If the :ref:`RigidBody "
"<class_RigidBody>` node does not have a variable/constant defined with the "
"name ``NO_PICKUP``, then we assign the ``rigid_body`` variable to the :ref:"
"`RigidBody <class_RigidBody>` node and break the for loop."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:813
msgid ""
"What this section of code does is goes through all of the physics bodies "
"within the ``grab_area`` and grabs the first :ref:`RigidBody "
"<class_RigidBody>` node that does not have a variable/constant named "
"``NO_PICKUP`` and assigns it to the ``rigid_body`` variable so we can do "
"some additional post processing later in this function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:818
msgid ""
"If the ``grab_mode`` variable is not equal to ``AREA``, we then check to see "
"if it is equal to ``RAYCAST`` instead. If it is equal to ``RAYCAST``, we "
"force the ``grab_raycast`` node to update using the ``force_raycast_update`` "
"function. The ``force_raycast_update`` function will update the :ref:"
"`Raycast <class_Raycast>` with the latest changes in the physics world. We "
"then check to see if the ``grab_raycast`` node collided with something using "
"the ``is_colliding`` function, which will return true if the :ref:`Raycast "
"<class_Raycast>` hit something."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:822
msgid ""
"If the ``grab_raycast`` hit something, we get the :ref:`PhysicsBody "
"<class_PhysicsBody>` node hit using the ``get_collider`` function. The code "
"then checks to see if the node hit is a :ref:`RigidBody <class_RigidBody>` "
"node using ``if body is RigidBody``, which will return ``true`` if the :ref:"
"`PhysicsBody <class_PhysicsBody>` node is or extends the :ref:`RigidBody "
"<class_RigidBody>` node. Then the code checks to see if the :ref:`RigidBody "
"<class_RigidBody>` node does not have a variable named ``NO_PICKUP``, and if "
"it does not, then it assigns the :ref:`RigidBody <class_RigidBody>` node to "
"the ``rigid_body`` variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:827
msgid ""
"What this section of code does is sends the ``grab_raycast`` :ref:`Raycast "
"<class_Raycast>` node out and checks if it collided with a :ref:`RigidBody "
"<class_RigidBody>` node that does not have a variable/constant named "
"``NO_PICKUP``. If it collided with a RigidBody without ``NO_PICKUP``, it "
"assigns the node to the ``rigid_body`` variable so we can do some additional "
"post processing later in this function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:833
msgid ""
"The final section of code first checks to see if ``rigid_body`` is not equal "
"to ``null``. If ``rigid_body`` is not equal to ``null``, then the VR "
"controller found a :ref:`RigidBody <class_RigidBody>`-based node that can be "
"picked up."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:836
msgid ""
"If there is a VR controller to pickup, we assign ``held_object`` to the :ref:"
"`RigidBody <class_RigidBody>` node stored in ``rigid_body``. We then store "
"the :ref:`RigidBody <class_RigidBody>` node's ``mode``, ``collision_layer``, "
"and ``collision_mask`` in ``held_object_data`` using ``mode``, ``layer``, "
"and ``mask`` as keys for the respective values. This is so we can reapply "
"them later when the object is dropped by the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:840
msgid ""
"We then set the :ref:`RigidBody <class_RigidBody>`'s mode to "
"``MODE_STATIC``, it's ``collision_layer`` to zero, and it's "
"``collision_mask`` to zero. This will make it where the held :ref:`RigidBody "
"<class_RigidBody>` cannot interact with other objects in the physics world "
"when held by the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:843
msgid ""
"Next the ``hand_mesh`` :ref:`MeshInstance <class_MeshInstance>` is made "
"invisible by setting the ``visible`` property to ``false``. This is so the "
"hand does not get in the way of the held object. Likewise, the "
"``grab_raycast`` 'laser sight' is made invisible by setting the ``visible`` "
"property to ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:846
msgid ""
"Then the code checks to see if the held object extends a class called "
"``VR_Interactable_Rigidbody``. If it does, then sets a variable called "
"``controller`` on ``held_object`` to ``self``, and calls the ``picked_up`` "
"function on ``held_object``. While we haven't made "
"``VR_Interactable_Rigidbody`` just yet, what this will do is set tell the "
"``VR_Interactable_Rigidbody`` class that it is being held by a VR "
"controller, where the a reference to the controller is stored in the "
"``controller`` variable, through calling the ``picked_up`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:852
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:876
msgid ""
"The code should make more sense after completing part 2 of this tutorial "
"series, where we will actually be using ``VR_Interactable_Rigidbody``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:854
msgid ""
"What this section of code does is that if a :ref:`RigidBody "
"<class_RigidBody>` was found using the grab :ref:`Area <class_Area>` or :ref:"
"`Raycast <class_Raycast>`, it sets it up so that it can be carried by the VR "
"controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:858
msgid "``_throw_rigidbody`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:860
msgid ""
"First the function checks to see if the VR controller is not holding any "
"object by checking if the ``held_object`` variable is equal to ``null``. If "
"it is, then it simply calls ``return`` so nothing happens. While this "
"shouldn't be possible, the ``_throw_rigidbody`` function should only be "
"called if an object is held, this check helps ensure that if something "
"strange happens, this function will react as expected."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:864
msgid ""
"After checking if the VR controller is holding an object, we assume it is "
"and set the stored :ref:`RigidBody <class_RigidBody>` data back to the held "
"object. We take the ``mode``, ``layer`` and ``mask`` data stored in the "
"``held_object_data`` dictionary and reapply it to the object in "
"``held_object``. This will set the :ref:`RigidBody <class_RigidBody>` back "
"to the state it was prior to being picked up."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:868
msgid ""
"Then we call ``apply_impulse`` on the ``held_object`` so that the :ref:"
"`RigidBody <class_RigidBody>` is thrown in the direction of the VR "
"controller's velocity, ``controller_velocity``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:870
msgid ""
"We then check to see if the object held extends a class called "
"``VR_Interactable_Rigidbody``. If it does, then we call a function called "
"``dropped`` in ``held_object`` and set ``held_object.controller`` to "
"``null``. While we have not made ``VR_Interactable_Rigidbody`` yet, but what "
"this will do is call the ``droppped`` function so the :ref:`RigidBody "
"<class_RigidBody>` can do whatever it needs to do when dropped, and we set "
"the ``controller`` variable to ``null`` so that the :ref:`RigidBody "
"<class_RigidBody>` knows that it is not being held."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:878
msgid ""
"Regardless of whether ``held_object`` extends ``VR_Interactable_Rigidbody`` "
"or not, we then set ``held_object`` to ``null`` so the VR controller knows "
"it is no longer holding anything. Because the VR controller is no longer "
"holding anything, we make the ``hand_mesh`` visible by setting ``hand_mesh."
"visible`` to true."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:881
msgid ""
"Finally, if the ``grab_mode`` variable is set to ``RAYCAST``, we set "
"``grab_raycast.visible`` to ``true`` so the 'laser sight' for the :ref:"
"`Raycast <class_Raycast>` in ``grab_raycast`` is visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:885
msgid "``_on_button_pressed_menu`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:887
msgid ""
"First this function checks to see if the ``grab_mode`` variable is equal to "
"``AREA``. If it is, then it sets ``grab_mode`` to ``RAYCAST``. It then "
"checks to see if the VR controller is not holding anything by checking to "
"see if ``held_object`` is equal to ``null``. If the VR controller is not "
"holding anything, then ``grab_raycast.visible`` is set to ``true`` so the "
"'laser sight' on the grab raycast is visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:891
msgid ""
"If the ``grab_mode`` variable is not equal to ``AREA``, then it checks to "
"see if it is equal to ``RAYCAST``. If it is, then it sets the ``grab_mode`` "
"to ``AREA`` and sets ``grab_raycast.visible`` to ``false`` so the 'laser "
"sight' on the grab raycast is not visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:894
msgid ""
"This section of code simply changes how the VR controller will grab :ref:"
"`RigidBody <class_RigidBody>`-based nodes when the grab/grip button is "
"pressed. If ``grab_mode`` is set to ``AREA``, then the :ref:`Area "
"<class_Area>` node in ``grab_area`` will be used for detecting :ref:"
"`RigidBody <class_RigidBody>` nodes, while if ``grab_mode`` is set to "
"``RAYCAST`` the :ref:`Raycast <class_Raycast>` node in ``grab_raycast`` will "
"be used for detecting :ref:`RigidBody <class_RigidBody>` nodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:900
msgid "``button_released`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:902
msgid ""
"The only section of code in this function checks to see if the index of the "
"button that was just released, ``button_index``, is equal to ``15``, which "
"should map to the trigger button on the VR controller. The ``button_index`` "
"variable is passed in by the ``button_release`` signal in :ref:"
"`ARVRController <class_ARVRController>`, which we connected in the "
"``_ready`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:905
msgid ""
"If the trigger button was just released, then the "
"``_on_button_released_trigger`` function is called."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:909
msgid "``_on_button_released_trigger`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:911
msgid ""
"The only section of code in this function first checks to see if the VR "
"controller is trying to teleport by checking if the ``teleport_button_down`` "
"variable is equal to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:913
msgid ""
"If the ``teleport_button_down`` variable is equal to ``true``, the code then "
"checks if there is a teleport position set and whether the teleport mesh is "
"visible. It does this by checking to see if ``teleport_pos`` is not equal to "
"``null`` and if ``teleport_mesh.visible`` is equal to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:916
msgid ""
"If there is a teleport position set and the teleport mesh is visible, the "
"code then calculates the offset from the camera to the :ref:`ARVROrigin "
"<class_ARVROrigin>` node, which is assumed to be the parent node of the VR "
"controller. To calculate the offset, the global position (``global_transform."
"origin``) of the ``Player_Camera`` node has the global position of the :ref:"
"`ARVROrigin <class_ARVROrigin>` subtracted from it. This will result in a "
"vector that points from the :ref:`ARVROrigin <class_ARVROrigin>` to the :ref:"
"`ARVRCamera <class_ARVRCamera>`, which we store in a variable called "
"``camera_offset``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:920
msgid ""
"The reason we need to know the offset is because some VR headsets use room "
"tracking, where the player's camera can be offset from the :ref:`ARVROrigin "
"<class_ARVROrigin>` node. Because of this, when we teleport we want to keep "
"the offset created by room tracking so that when the player teleports, the "
"offset created by the room tracking is not applied. Without this, if you "
"moved in a room and then teleported, instead of appearing at the position "
"you wanted to teleport at, your position would be offset by the amount of "
"distance you have from the :ref:`ARVROrigin <class_ARVROrigin>` node."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:924
msgid ""
"Now that we know the offset from the VR camera to the VR origin, we need to "
"remove the difference on the ``Y`` axis. We do this because we do not want "
"to offset based on the user's height. If we did not do this, when "
"teleporting the player's head would be level with the ground."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:927
msgid ""
"Then we can 'teleport' the player by setting the global position "
"(``global_transform.origin``) of the ARVROrigin node to the position stored "
"in ``teleport_pos`` with ``camera_offset`` subtracted from it. This will "
"teleport the player and remove the room tracking offset, so the user appears "
"exactly where they want when teleporting."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:930
msgid ""
"Finally, regardless of whether the VR controller teleported the user or not, "
"we reset the teleport related variables. ``teleport_button_down`` is set to "
"``false``, ``teleport_mesh.visible`` is set to ``false`` so the mesh is "
"invisible, ``teleport_raycast.visible`` is set to ``false``, and "
"``teleport_pos`` is set to ``null``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:935
msgid "``sleep_area_entered`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:937
msgid ""
"The only section of code in this function checks to see if the :ref:"
"`PhysicsBody <class_PhysicsBody>` node that entered the ``Sleep_Area`` node "
"has a variable called ``can_sleep``. If it does, then it sets the "
"``can_sleep`` variable to ``false`` and sets the ``sleeping`` variable to "
"``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:940
msgid ""
"Without doing this, sleeping :ref:`PhysicsBody <class_PhysicsBody>` nodes "
"would not be able to be picked up by the VR controller, even if the VR "
"controller is at the same position as the :ref:`PhysicsBody "
"<class_PhysicsBody>` node. To work around this, we simply 'wake up' :ref:"
"`PhysicsBody <class_PhysicsBody>` nodes that are close to the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:946
msgid "``sleep_area_exited`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:948
msgid ""
"The only section of code in this function checks to see if the :ref:"
"`PhysicsBody <class_PhysicsBody>` node that entered the ``Sleep_Area`` node "
"has a variable called ``can_sleep``. If it does, then it sets the "
"``can_sleep`` variable to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:951
msgid ""
"This allows :ref:`RigidBody <class_RigidBody>` nodes that leave the "
"``Sleep_Area`` to sleep again, saving performance."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:955
msgid ""
"Okay, whew! That was a lot of code! Add the same script, ``VR_Controller."
"gd`` to the other VR controller scene so both VR controllers have the same "
"script."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:957
msgid ""
"Now we just need to do one thing before testing the project! Right now we "
"are referencing a class called ``VR_Interactable_Rigidbody``, but we have "
"not defined it yet. While we will not be using ``VR_Interactable_Rigidbody`` "
"in this tutorial, let's create it real quick so the project can be run."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:963
msgid "Creating a base class for interactable VR objects"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:965
msgid ""
"With the ``Script`` tab still open, create a new GDScript called "
"``VR_Interactable_Rigidbody.gd``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:967
msgid ""
"You can create GDScripts in the ``Script`` tab by pressing ``File -> New "
"Script...``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:969
msgid ""
"Once you have ``VR_Interactable_Rigidbody.gd`` open, add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:997
msgid "Let's quickly go through what this script."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1001
msgid ""
"First we start the script with ``class_name VR_Interactable_Rigidbody``. "
"What this does is that it tells Godot that this GDScript is a new class that "
"called ``VR_Interactable_Rigidbody``. This allows us to compare nodes "
"against the ``VR_Interactable_Rigidbody`` class in other script files "
"without having to load the script directly or do anything special. We can "
"compare the class just like all of the built-in Godot classes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1005
msgid ""
"Next is a class variable called ``controller``. ``controller`` will be used "
"to hold a reference to the VR controller that is currently holding the "
"object. If a VR controller is not holding the object, then the "
"``controller`` variable will be ``null``. The reason we need to have a "
"reference to the VR controller is so held objects can access VR controller "
"specific data, like ``controller_velocity``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1009
msgid ""
"Finally, we have four functions. The ``_ready`` function is defined by Godot "
"and all we do is simply have ``pass`` as there is nothing we need to do when "
"the object is added to the scene in ``VR_Interactable_Rigidbody``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1012
msgid ""
"The ``interact`` function is a stub function that will be called when the "
"interact button on the VR controller, the trigger in this case, is pressed "
"while the object is held."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1014
msgid ""
"A stub function is a function that is defined but does not have any code. "
"Stub functions are generally designed to be overwritten or extended. In this "
"project, we are using the stub functions so there is a consistent interface "
"across all interactable :ref:`RigidBody <class_RigidBody>` objects."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1017
msgid ""
"The ``picked_up`` and ``dropped`` functions are stub functions that will be "
"called when the object is picked up and dropped by the VR controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1021
msgid ""
"That is all we need to do for now! In the next part of this tutorial series, "
"we'll start making special interactable :ref:`RigidBody <class_RigidBody>` "
"objects."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1023
msgid ""
"Now that the base class is defined, the code in the VR controller should "
"work. Go ahead and try the game again, and you should find you can teleport "
"around by pressing the touch pad, and can grab and throw objects using the "
"grab/grip buttons."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1026
msgid ""
"Now, you may want to try moving using the trackpads and/or joysticks, but "
"**it may make you motion sick!**"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1028
msgid ""
"One of the main reasons this can make you feel motion sick is because your "
"vision tells you that you are moving, while your body is not moving. This "
"conflict of signals can make the body feel sick. Let's add a vignette shader "
"to help reduce motion sickness while moving in VR!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1034
msgid "Reducing motion sickness"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1036
msgid ""
"There are plenty of ways to reduce motion sickness in VR, and there is no "
"one perfect way to reduce motion sickness. See `this page on the Oculus "
"Developer Center <https://developer.oculus.com/design/latest/concepts/bp-"
"locomotion/>`_ for more information on how to implement locomotion and "
"reducing motion sickness."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1040
msgid ""
"To help reduce motion sickness while moving, we are going to add a vignette "
"effect that will only be visible while the player moves."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1042
msgid ""
"First, quickly switch back to ``Game.tscn```. Under the :ref:`ARVROrigin "
"<class_ARVROrigin>` node there is a child node called ``Movement_Vignette``. "
"This node is going to apply a simple vignette to the VR headset when the "
"player is moving using the VR controllers. This should help reduce motion "
"sickness."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1045
msgid ""
"Open up ``Movement_Vignette.tscn``, which you can find in the ``Scenes`` "
"folder. The scene is just a :ref:`ColorRect <class_ColorRect>` node with a "
"custom shader. Feel free to look at the custom shader if you want, it is "
"just a slightly modified version of the vignette shader you can find in the "
"`Godot demo repository <https://github.com/godotengine/godot-demo-"
"projects>`_."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1049
msgid ""
"Let's write the code that will make the vignette shader visible when the "
"player is moving. Select the ``Movement_Vignette`` node and create a new "
"script called ``Movement_Vignette.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1092
msgid ""
"Because this script is fairly brief, let's quickly go over what it does."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1096
msgid "Explaining the vignette code"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1098
msgid ""
"There are two class variables, ``controller_one`` and ``controller_two``. "
"These variables will hold references to the left and right VR controllers."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1102
msgid ""
"In the ``_ready`` function first waits for four frames using ``yield``. The "
"reason we are waiting four frames is because we want to ensure the VR "
"interface is ready and accessible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1105
msgid ""
"After waiting the primary VR interface is retrieved using ``ARVRServer."
"primary_interface``, which is assigned to a variable called ``interface``. "
"The code then checks to see if ``interface`` is equal to ``null``. If "
"``interface`` is equal to ``null``, then ``_process`` is disabled using "
"``set_process`` with a value of ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1108
msgid ""
"If ``interface`` is not ``null``, then we set the ``rect_size`` of the "
"vignette shader to the render size of the VR viewport so it takes up the "
"entire screen. We need to do this because different VR headsets have "
"different resolutions and aspect ratios, so we need to resize the node "
"accordingly. We also set the ``rect_position`` of the vignette shader to "
"zero so it is in the correct position relative to the screen."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1112
msgid ""
"The left and right VR controllers are then retrieved and assigned to "
"``controller_one`` and ``controller_two`` respectively. Finally, the "
"vignette shader is made invisible by default by setting it's ``visible`` "
"property to ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1117
msgid ""
"In ``_process`` the code first checks if either ``controller_one`` or "
"``controller_two`` are equal to ``null``. If either node is equal to "
"``null``, then ``return`` is called so nothing happens."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1120
msgid ""
"Then the code checks to see if either of the VR controllers are moving the "
"player using the touchpad/joystick by checking if ``directional_movement`` "
"is equal to ``true`` in ``controller_one`` or ``controller_two``. If either "
"of the VR controllers are moving the player, then the vignette shader makes "
"itself visible by setting it's ``visible`` property to ``true``. If neither "
"VR controller is moving the player, so ``directional_movement`` is ``false`` "
"in both VR controllers, than the vignette shader makes itself invisible by "
"setting it's ``visible`` property to ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1127
msgid ""
"That is the whole script! Now that we have written the code, go ahead and "
"try moving around with the trackpad and/or joystick. You should find that it "
"is less motion sickness-inducing then before!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1130
msgid ""
"As previously mentioned, there are plenty of ways to reduce motion sickness "
"in VR. Check out `this page on the Oculus Developer Center <https://"
"developer.oculus.com/design/latest/concepts/bp-locomotion/>`_ for more "
"information on how to implement locomotion and reducing motion sickness."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1141
msgid ""
"Now you have fully working VR controllers that can move around the "
"environment and interact with :ref:`RigidBody <class_RigidBody>`-based "
"objects. In the next part of this tutorial series, we will be creating some "
"special :ref:`RigidBody <class_RigidBody>`-based objects for the player to "
"use!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_one.rst:1144
msgid ""
"You can download the finished project for this tutorial series on the Godot "
"OpenVR GitHub repository, under the releases tab!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:4
#, fuzzy
msgid "VR starter tutorial part 2"
msgstr "מדריכים"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:11
msgid ""
"In this part of the VR starter tutorial series, we will be adding a number "
"of special :ref:`RigidBody <class_RigidBody>`-based nodes that can be used "
"in VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:13
msgid ""
"This continues from where we left on in the last tutorial part, where we "
"just finished getting the VR controllers working and defined a custom class "
"called ``VR_Interactable_Rigidbody``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:20
msgid "Adding destroyable targets"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:22
msgid ""
"Before we make any of the special :ref:`RigidBody <class_RigidBody>`-based "
"nodes, we need something for them to do. Let's make a simple sphere target "
"that will break into a bunch of pieces when destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:25
msgid ""
"Open up ``Sphere_Target.tscn``, which is in the ``Scenes`` folder. The scene "
"is fairly simple, with just a :ref:`StaticBody <class_StaticBody>` with a "
"sphere shaped :ref:`CollisionShape <class_CollisionShape>`, a :ref:"
"`MeshInstance <class_MeshInstance>` node displaying a sphere mesh, and an :"
"ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:28
msgid ""
"The special :ref:`RigidBody <class_RigidBody>` nodes will handle damaging "
"the sphere, which is why we are using a :ref:`StaticBody <class_StaticBody>` "
"node instead of something like an :ref:`Area <class_Area>` or :ref:"
"`RigidBody <class_RigidBody>` node. Outside of that, there isn't really a "
"lot to talk about, so let's move straight into writing the code."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:31
msgid ""
"Select the ``Sphere_Target_Root`` node and make a new script called "
"``Sphere_Target.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:79
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:263
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:658
msgid "Let's go over how this script works."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:82
msgid "Explaining the Sphere Target code"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:86
msgid ""
"``destroyed``: A variable to track whether the sphere target has been "
"destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:87
msgid ""
"``destroyed_timer``: A variable to track how long the sphere target has been "
"destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:88
msgid ""
"``DESTROY_WAIT_TIME``: A constant to define the length of time the target "
"can be destroyed for before it frees/deletes itself."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:89
msgid ""
"``health``: A variable to store the amount of health the sphere target has."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:90
msgid ""
"``RIGID_BODY_TARGET``: A constant to hold the scene of the destroyed sphere "
"target."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:92
msgid ""
"Feel free to check out the ``RIGID_BODY_TARGET`` scene. It is just a bunch "
"of :ref:`RigidBody <class_RigidBody>` nodes and a broken sphere model."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:94
msgid ""
"We'll be instancing this scene so when the target is destroyed, it looks "
"like it broke into a bunch of pieces."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:100
msgid ""
"All the ``_ready`` function does is that it stops the ``_physics_process`` "
"from being called by calling ``set_physics_process`` and passing ``false``. "
"The reason we do this is because all the code in ``_physics_process`` is for "
"destroying this node when enough time has passed, which we only want to do "
"when the target has been destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:108
msgid ""
"First this function adds time, ``delta``, to the ``destroyed_timer`` "
"variable. It then checks to see if ``destroyed_timer`` is greater than or "
"equal to ``DESTROY_WAIT_TIME``. If ``destroyed_timer`` is greater than or "
"equal to ``DESTROY_WAIT_TIME``, then the sphere target frees/deletes itself "
"by calling the ``queue_free`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:113
msgid "``damage`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:115
msgid ""
"The ``damage`` function will be called by the special :ref:`RigidBody "
"<class_RigidBody>` nodes, which will pass the amount of damage done to the "
"target, which is a function argument variable called ``damage``. The "
"``damage`` variable will hold the amount of damage the special :ref:"
"`RigidBody <class_RigidBody>` node did to the sphere target."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:118
msgid ""
"First this function checks to make sure the target is not already destroyed "
"by checking if the ``destroyed`` variable is equal to ``true``. If "
"``destroyed`` is equal to ``true``, then the function calls ``return`` so "
"none of the other code is called. This is just a safety check so that if two "
"things damage the target at exactly the same time, the target cannot be "
"destroyed twice."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:122
msgid ""
"Next the function removes the amount of damage taken, ``damage``, from the "
"target's health, ``health``. If then checks to see if ``health`` is equal to "
"zero or less, meaning that the target has just been destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:125
msgid ""
"If the target has just been destroyed, then we disable the :ref:"
"`CollisionShape <class_CollisionShape>` by setting it's ``disabled`` "
"property to ``true``. We then make the ``Sphere_Target`` :ref:`MeshInstance "
"<class_MeshInstance>` invisible by setting the ``visible`` property to "
"``false``. We do this so the target can no longer effect the physics world "
"and so the non-broken target mesh is not visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:128
msgid ""
"After this the function then instances the ``RIGID_BODY_TARGET`` scene and "
"adds it as a child of the target. It then sets the ``global_transform`` of "
"the newly instanced scene, called ``clone``, to the ``global_transform`` of "
"the non-broken target. This makes it where the broken target starts at the "
"same position as the non-broken target with the same rotation and scale."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:131
msgid ""
"Then the function sets the ``destroyed`` variable to ``true`` so the target "
"knows it has been destroyed and calls the ``set_physics_process`` function "
"and passes ``true``. This will start executing the code in "
"``_physics_process`` so that after ``DESTROY_WAIT_TIME`` seconds have "
"passed, the sphere target will free/destroy itself."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:134
msgid ""
"The function then gets the :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` node and calls the ``play`` function so it "
"plays its sound."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:136
msgid ""
"Finally, the ``remove_sphere`` function is called in ``Game.gd``. To get "
"``Game.gd``, the code uses the scene tree and works its way from the root of "
"the scene tree to the root of the ``Game.tscn`` scene."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:141
msgid "Adding the ``remove_sphere`` function to ``Game.gd``"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:143
msgid ""
"You may have noticed we are calling a function in ``Game.gd``, called "
"``remove_sphere``, that we have not defined yet. Open up ``Game.gd`` and add "
"the following additional class variables:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:152
msgid ""
"``spheres_left``: The amount of sphere targets left in the world. In the "
"provided ``Game`` scene, there are ``10`` spheres, so that is the initial "
"value."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:153
msgid ""
"``sphere_ui``: A reference to the sphere UI. We will use this later in the "
"tutorial to display the amount of spheres left in the world."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:155
msgid ""
"With these variables defined, we can now add the ``remove_sphere`` function. "
"Add the following code to ``Game.gd``:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:167
msgid "Let's go through what this function does real quick:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:169
msgid ""
"First, it removes one from the ``spheres_left`` variable. It then checks to "
"see if the ``sphere_ui`` variable is not equal to ``null``, and if it is not "
"equal to ``null`` it calls the ``update_ui`` function on ``sphere_ui``, "
"passing in the number of spheres as an argument to the function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:172
msgid "We will add the code for ``sphere_ui`` later in this tutorial!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:174
msgid ""
"Now the ``Sphere_Target`` is ready to be used, but we don't have any way to "
"destroy it. Let's fix that by adding some special :ref:`RigidBody "
"<class_RigidBody>`-based nodes that can damage the targets."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:179
msgid "Adding a pistol"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:181
msgid ""
"Let's add a pistol as the first interactable :ref:`RigidBody "
"<class_RigidBody>` node. Open up ``Pistol.tscn``, which you can find in the "
"``Scenes`` folder."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:183
msgid ""
"Let's quickly go over a few things of note in ``Pistol.tscn`` real quick "
"before we add the code."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:185
msgid ""
"All of the nodes in ``Pistol.tscn`` expect the root node are rotated. This "
"is so the pistol is in the correct rotation relative to the VR controller "
"when it is picked up. The root node is a :ref:`RigidBody <class_RigidBody>` "
"node, which we need because we're going to use the "
"``VR_Interactable_Rigidbody`` class we created in the last part of this "
"tutorial series."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:188
msgid ""
"There is a :ref:`MeshInstance <class_MeshInstance>` node called "
"``Pistol_Flash``, which is a simple mesh that we will be using to simulate "
"the muzzle flash on the end of the pistol's barrel. A :ref:`MeshInstance "
"<class_MeshInstance>` node called ``LaserSight`` is used to as a guide for "
"aiming the pistol, and it follows the direction of the :ref:`Raycast "
"<class_Raycast>` node, called ``Raycast``, that the pistol uses to detect if "
"its 'bullet' hit something. Finally, there is an :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` node at the end of the pistol that we will use "
"to play the sound of the pistol firing."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:193
msgid ""
"Feel free to look at the other parts of the scene if you want. Most of the "
"scene is fairly straightforward, with the major changes mentioned above. "
"Select the :ref:`RigidBody <class_RigidBody>` node called ``Pistol`` and "
"make a new script called ``Pistol.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:267
msgid "Explaining the pistol code"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:269
msgid ""
"First, notice how instead of ``extends RigidBody``, we instead have "
"``extends VR_Interactable_Rigidbody``. This makes it where the pistol script "
"extends the ``VR_Interactable_Rigidbody`` class so the VR controllers know "
"this object can be interacted with and that the functions defined in "
"``VR_Interactable_Rigidbody`` can be called when this object is held by a VR "
"controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:273
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:667
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:849
msgid "Next, let's look at the class variables:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:275
msgid ""
"``flash_mesh``: A variable to hold the :ref:`MeshInstance "
"<class_MeshInstance>` node that is used to simulate muzzle flash on the "
"pistol."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:276
msgid ""
"``FLASH_TIME``: A constant to define how long the muzzle flash will be "
"visible. This will also define how fast the pistol can fire."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:277
msgid ""
"``flash_timer``: A variable to hold the amount of time the muzzle flash has "
"been visible for."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:278
msgid ""
"``laser_sight_mesh``: A variable to hold the :ref:`MeshInstance "
"<class_MeshInstance>` node that acts as the pistol's 'laser sight'."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:279
msgid ""
"``pistol_fire_sound``: A variable to hold the :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` node used for the pistol's firing sound."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:280
msgid ""
"``raycast``: A variable to hold the :ref:`Raycast <class_Raycast>` node that "
"is used for calculating the bullet's position and normal when the pistol is "
"fired."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:281
msgid ""
"``BULLET_DAMAGE``: A constant to define the amount of damage a single bullet "
"from the pistol does."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:282
msgid ""
"``COLLISION_FORCE``: A constant that defines the amount of force that is "
"applied to :ref:`RigidBody <class_RigidBody>` nodes when the pistol's bullet "
"collides."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:288
msgid ""
"This function gets the nodes and assigns them to their proper variables. For "
"the ``flash_mesh`` and ``laser_sight_mesh`` nodes, both have their "
"``visible`` property set to ``false`` so they are not visible initially."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:294
msgid ""
"The ``_physics_process`` function first checks to see if the pistol's muzzle "
"flash is visible by checking if ``flash_timer`` is more than zero. If "
"``flash_timer`` is more than zero, then we remove time, ``delta`` from it. "
"Next we check if the ``flash_timer`` variable is zero or less now that we "
"removed ``delta`` from it. If it is, then the pistol muzzle flash timer just "
"finished and so we need to make ``flash_mesh`` invisible by setting it's "
"``visible`` property to ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:299
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:473
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:760
msgid "``interact`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:301
msgid ""
"The interact function first checks to see if the pistol's muzzle flash is "
"invisible by checking to see if ``flash_timer`` is less than or equal to "
"zero. We do this so we can limit the rate of fire of the pistol to the "
"length of time the muzzle flash is visible, which is a simple solution for "
"limiting how fast the player can fire."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:304
msgid ""
"If ``flash_timer`` is zero or less, we then set ``flash_timer`` to "
"``FLASH_TIME`` so there is a delay before the pistol can fire again. After "
"that we set ``flash_mesh.visible`` to ``true`` so the muzzle flash at the "
"end of the pistol is visible while ``flash_timer`` is more than zero."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:307
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:481
msgid ""
"Next we call the ``force_raycast_update`` function on the :ref:`Raycast "
"<class_Raycast>` node in ``raycast`` so that it gets the latest collision "
"info from the physics world. We then check if the ``raycast`` hit something "
"by checking if the ``is_colliding`` function is equal to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:312
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:501
msgid ""
"If the ``raycast`` hit something, then we get the :ref:`PhysicsBody "
"<class_PhysicsBody>` it collided with through the ``get_collider`` function. "
"We assign the hit :ref:`PhysicsBody <class_PhysicsBody>` to a variable "
"called ``body``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:315
msgid ""
"We then get the direction of the :ref:`Raycast <class_Raycast>` by getting "
"it's positive ``Z`` directional axis from the :ref:`Basis <class_Basis>` on "
"the ``raycast`` node's ``global_transform``. This will give us the direction "
"the raycast is pointing on the Z axis, which is the same direction as the "
"blue arrow on the :ref:`Spatial <class_Spatial>` gizmo when ``Local space "
"mode`` is enabled in the Godot editor. We store this direction in a variable "
"called ``direction_vector``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:319
msgid ""
"Next we get the distance from the :ref:`Raycast <class_Raycast>` origin to "
"the :ref:`Raycast <class_Raycast>` collision point by getting the distance "
"from the global position, ``global_transform.origin`` of the ``raycast`` "
"node to the collision point of the :ref:`Raycast <class_Raycast>`, ``raycast."
"get_collision_point``, using the ``distance_to`` function. This will give us "
"the distance the :ref:`Raycast <class_Raycast>` traveled before it collided, "
"which we store in a variable called ``raycast_distance``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:323
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:512
msgid ""
"Then the code checks if the :ref:`PhysicsBody <class_PhysicsBody>`, "
"``body``, has a function/method called ``damage`` using the ``has_method`` "
"function. If the :ref:`PhysicsBody <class_PhysicsBody>` has a function/"
"method called ``damage``, then we call the ``damage`` function and pass "
"``BULLET_DAMAGE`` so it takes damage from the bullet colliding into it."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:326
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:515
msgid ""
"Regardless of whether the :ref:`PhysicsBody <class_PhysicsBody>` has a "
"``damage`` function, we then check to see if ``body`` is a :ref:`RigidBody "
"<class_RigidBody>`-based node. If ``body`` is a :ref:`RigidBody "
"<class_RigidBody>`-based node, then we want to push it when the bullet "
"collides."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:329
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:518
msgid ""
"To calculate the amount of force applied, we simply take ``COLLISION_FORCE`` "
"and divide it by ``raycast_distance``, then we multiply the whole thing by "
"``body.mass``. We store this calculation in a variable called "
"``collision_force``. This will make collisions over a shorter distance apply "
"move force than those over longer distances, giving a *slightly* more "
"realistic collision response."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:332
#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:521
msgid ""
"We then push the :ref:`RigidBody <class_RigidBody>` using the "
"``apply_impulse`` function, where the position is a zero Vector3 so the "
"force is applied from the center, and the collision force is the "
"``collision_force`` variable we calculated."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:336
msgid ""
"Regardless of whether the ``raycast`` variable hit something or not, we then "
"play the pistol shot sound by calling the ``play`` function on the "
"``pistol_fire_sound`` variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:338
msgid ""
"Finally, we check to see if the pistol is being held by a VR controller by "
"checking to see if the ``controller`` variable is not equal to ``null``. If "
"it is not equal to ``null``, we then set the ``rumble`` property of the VR "
"controller to ``0.25``, so there is a slight rumble when the pistol fires."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:343
msgid "``picked_up`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:345
msgid ""
"This function simply makes the ``laser_sight_mesh`` :ref:`MeshInstance "
"<class_MeshInstance>` visible by setting the ``visible`` property to "
"``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:348
msgid "``dropped`` function step-by-step explanation"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:350
msgid ""
"This function simply makes the ``laser_sight_mesh`` :ref:`MeshInstance "
"<class_MeshInstance>` invisible by setting the ``visible`` property to "
"``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:354
msgid "Pistol finished"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:359
msgid ""
"That is all we need to do to have working pistols in the project! Go ahead "
"and run the project. If you climb up the stairs and grab the pistols, you "
"can fire them at the sphere targets in the scene using the trigger button on "
"the VR controller! If you fire at the targets long enough, they will break "
"into pieces."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:365
msgid "Adding a shotgun"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:367
msgid "Next let's add a shotgun to the VR project."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:369
msgid ""
"Adding a special shotgun :ref:`RigidBody <class_RigidBody>` should be fairly "
"straightforward, as almost everything with the shotgun is the same as the "
"pistol."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:371
msgid ""
"Open up ``Shotgun.tscn``, which you can find in the ``Scenes`` folder and "
"take a look at the scene. Almost everything is the same as in ``Pistol."
"tscn``. The only thing that is different, beyond name changes, is that "
"instead of a single :ref:`Raycast <class_Raycast>`, there are five :ref:"
"`Raycast <class_Raycast>` nodes. This is because a shotgun generally fires "
"in a cone shape, so we are going to emulate that effect by having several :"
"ref:`Raycast <class_Raycast>` nodes that will rotate randomly in a cone "
"shape when the shotgun fires."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:376
msgid ""
"Outside of that, everything is more or less the same as ``Pistol.tscn``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:378
msgid ""
"Let's write the code for the shotgun. Select the :ref:`RigidBody "
"<class_RigidBody>` node called ``Shotgun`` and make a new script called "
"``Shotgun.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:456
msgid ""
"The majority of this code is exactly the same as the code for the pistol "
"with just a few *minor* changes that are primarily just different names. Due "
"to how similar these scripts are, let's just focus on the changes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:460
#, fuzzy
msgid "Explaining the shotgun code"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:462
msgid ""
"Like with the pistol, the shotgun extends ``VR_Interactable_Rigidbody`` so "
"the VR controllers know that this object can be interacted with and what "
"functions are available."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:465
msgid "There is only one new class variable:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:467
msgid ""
"``raycasts``: A variable to hold the node that has all of the :ref:`Raycast "
"<class_Raycast>` nodes as its children."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:469
msgid ""
"The new class variable replaces the ``raycast`` variable from ``Pistol.gd``, "
"because with the shotgun we need to process multiple :ref:`Raycast "
"<class_Raycast>` nodes instead of just one. All of the other class variables "
"are the same as ``Pistol.gd`` and function the same way, some just are "
"renamed to be non-pistol specific."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:475
msgid ""
"The interact function first checks to see if the shotgun's muzzle flash is "
"invisible by checking to see if ``flash_timer`` is less than or equal to "
"zero. We do this so we can limit the rate of fire of the shotgun to the "
"length of time the muzzle flash is visible, which is a simple solution for "
"limiting how fast the player can fire."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:478
msgid ""
"If ``flash_timer`` is zero or less, we then set ``flash_timer`` to "
"``FLASH_TIME`` so there is a delay before the shotgun can fire again. After "
"that we set ``flash_mesh.visible`` to ``true`` so the muzzle flash at the "
"end of the shotgun is visible while ``flash_timer`` is more than zero."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:484
msgid ""
"Next we go through each of the child nodes of the ``raycasts`` variable "
"using a for loop. This way the code will go through each of the :ref:"
"`Raycast <class_Raycast>` nodes that are children of the ``raycasts`` "
"variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:489
msgid ""
"For each node, we check to see if ``raycast`` is *not* a :ref:`Raycast "
"<class_Raycast>` node. If the node is not a :ref:`Raycast <class_Raycast>` "
"node, we simply use ``continue`` to skip it."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:491
msgid ""
"Next we rotate the ``raycast`` node randomly around a small ``10`` degrees "
"cone by settings the ``rotation_degrees`` variable of the ``raycast`` to a "
"Vector3 where the X and Z axis are a random number from ``-10`` to ``10``. "
"This random number is selected using the ``rand_range`` function."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:494
msgid ""
"Then we call the ``force_raycast_update`` function on the :ref:`Raycast "
"<class_Raycast>` node in ``raycast`` so that it gets the latest collision "
"info from the physics world. We then check if the ``raycast`` hit something "
"by checking if the ``is_colliding`` function is equal to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:497
msgid ""
"The rest of the code is exactly the same, but this process is repeated for "
"each :ref:`Raycast <class_Raycast>` node that is a child of the ``raycasts`` "
"variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:504
msgid ""
"We then get the direction of the raycast by getting it's positive ``Z`` "
"directional axis from the :ref:`Basis <class_Basis>` on the ``raycast`` "
"node's ``global_transform``. This will give us the direction the raycast is "
"pointing on the Z axis, which is the same direction as the blue arrow on "
"the :ref:`Spatial <class_Spatial>` gizmo when ``Local space mode`` is "
"enabled in the Godot editor. We store this direction in a variable called "
"``direction_vector``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:508
msgid ""
"Next we get the distance from the raycast origin to the raycast collision "
"point by getting the distance from the global position, ``global_transform."
"origin`` of the ``raycast`` node to the collision point of the raycast, "
"``raycast.get_collision_point``, using the ``distance_to`` function. This "
"will give us the distance the :ref:`Raycast <class_Raycast>` traveled before "
"it collided, which we store in a variable called ``raycast_distance``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:526
msgid ""
"Once all of the :ref:`Raycast <class_Raycast>`\\s in the ``raycast`` "
"variable have been iterated over, we then play the shotgun shot sound by "
"calling the ``play`` function on the ``shotgun_fire_sound`` variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:528
msgid ""
"Finally, we check to see if the shotgun is being held by a VR controller by "
"checking to see if the ``controller`` variable is not equal to ``null``. If "
"it is not equal to ``null``, we then set the ``rumble`` property of the VR "
"controller to ``0.25``, so there is a slight rumble when the shotgun fires."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:532
msgid "Shotgun finished"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:534
msgid ""
"Everything else is exactly the same as the pistol, with at most just some "
"simple name changes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:536
msgid ""
"Now the shotgun is finished! You can find the shotgun in the sample scene by "
"looking around the back of one of the walls (not in the building though!)."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:541
msgid "Adding a bomb"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:543
msgid ""
"Okay, let's add a different special :ref:`RigidBody <class_RigidBody>`. "
"Instead of adding something that shoots, let's add something we can throw - "
"a bomb!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:545
msgid "Open up ``Bomb.tscn``, which is in the ``Scenes`` folder."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:547
msgid ""
"The root node is a :ref:`RigidBody <class_RigidBody>` node that we'll be "
"extending to use ``VR_Interactable_Rigidbody``, which has a :ref:"
"`CollisionShape <class_CollisionShape>` like the other special :ref:"
"`RigidBody <class_RigidBody>` nodes we've made so far. Likewise, there is a :"
"ref:`MeshInstance <class_MeshInstance>` called ``Bomb`` that is used to "
"display the mesh for the bomb."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:551
msgid ""
"Then we have an :ref:`Area <class_Area>` node simply called ``Area`` that "
"has a large :ref:`CollisionShape <class_CollisionShape>` as its child. We'll "
"use this :ref:`Area <class_Area>` node to effect anything within it when the "
"bomb explodes. Essentially, this :ref:`Area <class_Area>` node will be the "
"blast radius for the bomb."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:554
msgid ""
"There is also a couple :ref:`Particles <class_Particles>` nodes. One of the :"
"ref:`Particles <class_Particles>` nodes are for the smoke coming out of the "
"bomb's fuse, while another is for the explosion. You can take a look at the :"
"ref:`ParticlesMaterial <class_ParticlesMaterial>` resources, which define "
"how the particles work, if you want. We will not be covering how the "
"particles work in this tutorial due to it being outside of the scope of this "
"tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:558
msgid ""
"There is one thing with the :ref:`Particles <class_Particles>` nodes that we "
"need to make note of. If you select the ``Explosion_Particles`` node, you'll "
"find that its ``lifetime`` property is set to ``0.75`` and that the ``one "
"shot`` checkbox is enabled. This means that the particles will only play "
"once, and the particles will last for ``0.75`` seconds. We'll need to know "
"this so we can time the removal of the bomb with the end of the explosion :"
"ref:`Particles <class_Particles>`."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:562
msgid ""
"Let's write the code for the bomb. Select the ``Bomb`` :ref:`RigidBody "
"<class_RigidBody>` node and make a new script called ``Bomb.gd``. Add the "
"following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:662
msgid "Explaining the bomb code"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:664
msgid ""
"Like with the other special :ref:`RigidBody <class_RigidBody>` nodes, the "
"bomb extends ``VR_Interactable_Rigidbody`` so the VR controllers know this "
"object can be interacted with and that the functions defined defined in "
"``VR_Interactable_Rigidbody`` can be called when this object is held by a VR "
"controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:669
msgid ""
"``bomb_mesh``: A variable to hold the :ref:`MeshInstance "
"<class_MeshInstance>` node that is used for the non-exploded bomb."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:670
msgid ""
"``FUSE_TIME``: A constant to define how long the fuse will 'burn' before the "
"bomb explodes"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:671
msgid ""
"``fuse_timer``: A variable to hold the length of time that has passed since "
"the bomb's fuse has started to burn."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:672
msgid ""
"``explosion_area``: A variable to hold the :ref:`Area <class_Area>` node "
"used to detect objects within the bomb's explosion."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:673
msgid ""
"``EXPLOSION_DAMAGE``: A constant to define how much damage is applied with "
"the bomb explodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:674
msgid ""
"``EXPLOSION_TIME``: A constant to define how long the bomb will last in the "
"scene after it explodes. This value should be the same as the ``lifetime`` "
"property of the explosion :ref:`Particles <class_Particles>` node."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:675
msgid ""
"``explosion_timer`` A variable to hold the length of time that has passed "
"since the bomb exploded."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:676
msgid "``exploded``: A variable to hold whether the bomb has exploded or not."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:677
msgid ""
"``COLLISION_FORCE``: A constant that defines the amount of force that is "
"applied to :ref:`RigidBody <class_RigidBody>` nodes when the bomb explodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:678
msgid ""
"``fuse_particles``: A variable to hold a reference to the :ref:`Particles "
"<class_Particles>` node used for the bomb's fuse."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:679
msgid ""
"``explosion_particles``: A variable to hold a reference to the :ref:"
"`Particles <class_Particles>` node used for the bomb's explosion."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:680
msgid ""
"``explosion_sound``: A variable to hold a reference to the :ref:"
"`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node used for the "
"explosion sound."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:686
msgid ""
"The ``_ready`` function first gets all of the nodes from the bomb scene and "
"assigns them to their respective class variables for later use."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:688
msgid ""
"Then we call ``set_physics_process`` and pass ``false`` so "
"``_physics_process`` is not executed. We do this because the code in "
"``_physics_process`` will start burning the fuse and exploding the bomb, "
"which we only want to do when the user interacts with the bomb. If we did "
"not disable ``_physics_process``, the bomb's fuse would start before the "
"user has a chance to get to the bomb."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:696
msgid ""
"The ``_physics_process`` function first checks to see if ``fuse_timer`` is "
"less than ``FUSE_TIME``. If it is, then the bomb's fuse is still burning."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:698
msgid ""
"If the bomb's fuse is still burning, we then add time, ``delta``, to the "
"``fuse_timer`` variable. We then check to see if ``fuse_timer`` is more than "
"or equal to ``FUSE_TIME`` now that we have added ``delta`` to it. If "
"``fuse_timer`` is more than or equal to ``FUSE_TIME``, then the fuse has "
"just finished and we need to explode the bomb."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:701
msgid ""
"To explode the bomb, we first stop emitting particles for the fuse by "
"setting ``emitting`` to ``false`` on ``fuse_particles``. We then tell the "
"explosion :ref:`Particles <class_Particles>` node, ``explosion_particles``, "
"to emit all of its particle in a single shot by setting ``one_shot`` to "
"``true``. After that, we set ``emitting`` to ``true`` on "
"``explosion_particles`` so it looks like the bomb has exploded. To help make "
"it look like the bomb exploded, we hide the bomb :ref:`MeshInstance "
"<class_MeshInstance>` node by setting ``bomb_mesh.visible`` to ``false``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:705
msgid ""
"To keep the bomb from colliding with other objects in the physics world, we "
"set the ``collision_layer`` and ``collision_mask`` properties of the bomb to "
"``0``. We also change the :ref:`RigidBody <class_RigidBody>` mode to "
"``MODE_STATIC`` so the bomb :ref:`RigidBody <class_RigidBody>` does not move."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:708
msgid ""
"Then we need to get all of the :ref:`PhysicsBody <class_PhysicsBody>` nodes "
"within the ``explosion_area`` node. To do this, we use the "
"``get_overlapping_bodies`` in a for loop. The ``get_overlapping_bodies`` "
"function will return an array of :ref:`PhysicsBody <class_PhysicsBody>` "
"nodes within the :ref:`Area <class_Area>` node, which is exactly what we are "
"looking for."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:713
msgid ""
"For each :ref:`PhysicsBody <class_PhysicsBody>` node, which we store in a "
"variable called ``body``, we check to see if it is equal to ``self``. We do "
"this so the bomb does not accidentally explode itself, as the "
"``explosion_area`` could potentially detect the ``Bomb`` :ref:`RigidBody "
"<class_RigidBody>` as a PhysicsBody within the explosion area."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:716
msgid ""
"If the :ref:`PhysicsBody <class_PhysicsBody>` node, ``body``, is not the "
"bomb, then we first check to see if the :ref:`PhysicsBody "
"<class_PhysicsBody>` node has a function called ``damage``. If the :ref:"
"`PhysicsBody <class_PhysicsBody>` node has a function called ``damage``, we "
"call it and pass ``EXPLOSION_DAMAGE`` to it so it takes damage from the "
"explosion."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:719
msgid ""
"Next we check to see if the :ref:`PhysicsBody <class_PhysicsBody>` node is "
"a :ref:`RigidBody <class_RigidBody>`. If ``body`` is a :ref:`RigidBody "
"<class_RigidBody>`, we want to move it when the bomb explodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:722
msgid ""
"To move the :ref:`RigidBody <class_RigidBody>` node when the bomb explodes, "
"we first need to calculate the direction from the bomb to the :ref:"
"`RigidBody <class_RigidBody>` node. To do this we subtract the global "
"position of the bomb, ``global_transform.origin`` from the global position "
"of the :ref:`RigidBody <class_RigidBody>`. This will give us a :ref:`Vector3 "
"<class_Vector3>` that points from the bomb to the :ref:`RigidBody "
"<class_RigidBody>` node. We store this :ref:`Vector3 <class_Vector3>` in a "
"variable called ``direction_vector``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:726
msgid ""
"We then calculate the distance the :ref:`RigidBody <class_RigidBody>` is "
"from the bomb by using the ``length`` function on ``direction_vector``. We "
"store the distance in a variable called ``bomb_distance``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:729
msgid ""
"We then calculate the amount of force the bomb will be applied to the :ref:"
"`RigidBody <class_RigidBody>` node when the bomb explodes by dividing "
"``COLLISION_FORCE`` by ``bomb_distance``, and multiplying that by "
"``collision_force``. This will make it so if the :ref:`RigidBody "
"<class_RigidBody>` node is closer to the bomb, it will be pushed farther."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:732
msgid ""
"Finally, we push the :ref:`RigidBody <class_RigidBody>` node using the "
"``apply_impulse`` function, with a :ref:`Vector3 <class_Vector3>` position "
"of zero and ``collision_force`` multiplied by ``direction_vector."
"normalized`` as the force. This will send the :ref:`RigidBody "
"<class_RigidBody>` node flying when the bomb explodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:737
msgid ""
"After we have looped through all of the :ref:`PhysicsBody "
"<class_PhysicsBody>` nodes within the ``explosion_area``, we set the "
"``exploded`` variable to ``true`` so the code knows the bomb exploded and "
"call ``play`` on ``explosion_sound`` so the sound of an explosion is played."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:742
msgid ""
"Alright, the next section of code starts by first checking if ``exploded`` "
"is equal to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:744
msgid ""
"If ``exploded`` is equal to ``true``, then that means the bomb is waiting "
"for the explosion particles to finish before it frees/destroys itself. We "
"add time, ``delta``, to ``explosion_timer`` so we can track how long it has "
"been since the bomb has exploded."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:747
msgid ""
"If ``explosion_timer`` is greater than or equal to ``EXPLOSION_TIME`` after "
"we added ``delta``, then the explosion timer just finished."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:749
msgid ""
"If the explosion timer just finished, we set ``explosion_area.monitoring`` "
"to ``false``. The reason we do this is because there was a bug that would "
"print an error when you freed/deleted an :ref:`Area <class_Area>` node when "
"the ``monitoring`` property was true. To make sure this doesn't happen, we "
"simply set ``monitoring`` to false on ``explosion_area``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:752
msgid ""
"Next we check to see if the bomb is being held by a VR controller by "
"checking to see if the ``controller`` variable is not equal to ``null``. If "
"the bomb is being held by a VR controller, we set the ``held_object`` "
"property of the VR controller, ``controller``, to ``null``. Because the VR "
"controller is no longer holding anything, we make the VR controller's hand "
"mesh visible by setting ``controller.hand_mesh.visible`` to ``true``. Then "
"we check to see if the VR controller grab mode is ``RAYCAST``, and if it is "
"we set ``controller.grab_raycast.visible`` to ``true`` so the 'laser sight' "
"for the grab raycast is visible."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:757
msgid ""
"Finally, regardless if the bomb is being held by a VR controller or not, we "
"call ``queue_free`` so the bomb scene is freed/removed from the scene."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:762
msgid ""
"First the ``interact`` function calls ``set_physics_process`` and passes "
"``true`` so the code in ``_physics_process`` starts executing. This will "
"start the bomb's fuse and eventually lead to the bomb exploding."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:765
msgid ""
"Finally, we start the fuse particles by setting ``fuse_particles.visible`` "
"to ``true``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:769
msgid "Bomb finished"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:771
msgid ""
"Now the bomb is ready to go! You can find the bombs in the orange building."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:773
msgid ""
"Because of how we are calculating the VR controller's velocity, it is "
"easiest to throw the bombs using a thrusting-like motion instead of a more "
"natural throwing-like motion. The smooth curve of a throwing-like motion is "
"harder to track with the code we are using for calculating the velocity of "
"the VR controllers, so it does not always work correctly and can lead "
"inaccurately calculated velocities."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:780
msgid "Adding a sword"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:782
msgid ""
"Let's add one last special :ref:`RigidBody <class_RigidBody>`-based node "
"that can destroy targets. Let's add a sword so we can slice through the "
"targets!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:784
msgid "Open up ``Sword.tscn``, which you can find in the ``Scenes`` folder."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:786
msgid ""
"There is not a whole lot going on here. All of the child nodes of the root "
"``Sword`` :ref:`RigidBody <class_RigidBody>` node are rotated to they are "
"positioned correctly when the VR controller picks them up, there is a :ref:"
"`MeshInstance <class_MeshInstance>` node for displaying the sword, and there "
"is an :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` node that holds "
"a sound for the sword colliding with something."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:790
msgid ""
"There is one thing that is slightly different though. There is a :ref:"
"`KinematicBody <class_KinematicBody>` node called ``Damage_Body``. If you "
"take a look at it, you'll find that it is not on any collision layers, and "
"is instead only on a single collision mask. This is so the :ref:"
"`KinematicBody <class_KinematicBody>` will not effect other :ref:"
"`PhysicsBody <class_PhysicsBody>` nodes in the scene, but it will still be "
"effected by :ref:`PhysicsBody <class_PhysicsBody>` nodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:794
msgid ""
"We are going to use the ``Damage_Body`` :ref:`KinematicBody "
"<class_KinematicBody>` node to detect the collision point and normal when "
"the sword collides with something in the scene."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:796
msgid ""
"While this is perhaps not the best way of getting the collision information "
"from a performance point of view, it does give us a lot of information we "
"can use for post-processing! Using a :ref:`KinematicBody "
"<class_KinematicBody>` this way means we can detect exactly where the sword "
"collided with other :ref:`PhysicsBody <class_PhysicsBody>` nodes."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:799
msgid ""
"That is really the only thing note worthy about the sword scene. Select the "
"``Sword`` :ref:`RigidBody <class_RigidBody>` node and make a new script "
"called ``Sword.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:840
msgid "Let's go over how this script works!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:844
#, fuzzy
msgid "Explaining the sword code"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:846
msgid ""
"Like with the other special :ref:`RigidBody <class_RigidBody>` nodes, the "
"sword extends ``VR_Interactable_Rigidbody`` so the VR controllers know this "
"object can be interacted with and that the functions defined defined in "
"``VR_Interactable_Rigidbody`` can be called when this object is held by a VR "
"controller."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:851
msgid ""
"``SWORD_DAMAGE``: A constant to define the amount of damage the sword does. "
"This damage is applied  to every object in the sword on every "
"``_physics_process`` call"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:852
msgid ""
"``COLLISION_FORCE``: A constant that defines the amount of force applied to :"
"ref:`RigidBody <class_RigidBody>` nodes when the sword collides with a :ref:"
"`PhysicsBody <class_PhysicsBody>`."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:853
msgid ""
"``damage_body``: A variable to hold the :ref:`KinematicBody "
"<class_KinematicBody>` node used to detect whether the sword is stabbing a :"
"ref:`PhysicsBody <class_PhysicsBody>` node or not."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:854
msgid ""
"``sword_noise``: A variable to hold the :ref:`AudioStreamPlayer3D "
"<class_AudioStreamPlayer3D>` node used to play a sound when the sword "
"collides with something."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:860
msgid ""
"All we are doing in the ``_ready`` function is getting the ``Damage_Body`` :"
"ref:`KinematicBody <class_KinematicBody>` node and assigning it to "
"``damage_body``. Because we do not want the sword to detect a collision with "
"the root :ref:`RigidBody <class_RigidBody>` node of the sword, we call "
"``add_collision_exception_with`` on ``damage_body`` and pass ``self`` so the "
"sword will not be detected."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:864
msgid ""
"Finally, we get the :ref:`AudioStreamPlayer3D <class_AudioStreamPlayer3D>` "
"node for the sword collision sound and apply it to the ``sword_noise`` "
"variable."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:870
msgid ""
"First we need to determine whether the sword is colliding with something or "
"not. To do this, we use the ``move_and_collide`` function of the "
"``damage_body`` node. Unlike how ``move_and_collide`` is normally used, we "
"are not passing a velocity and instead are passing an empty :ref:`Vector3 "
"<class_Vector3>`. Because we do not want the ``damage_body`` node to move, "
"we set the ``test_only`` argument (the fourth argument) as ``true`` so the :"
"ref:`KinematicBody <class_KinematicBody>` generates collision info without "
"actually causing any collisions within the collision world."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:875
msgid ""
"The ``move_and_collide`` function will return a :ref:`KinematicCollision "
"<class_KinematicCollision>` class that has all of the information we need "
"for detecting collisions on the sword. We assign the return value of "
"``move_and_collide`` to a variable called ``collision_results``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:878
msgid ""
"Next we check to see if ``collision_results`` is not equal to ``null``. If "
"``collision_results`` is not equal to ``null``, then we know that the sword "
"has collided with something."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:880
msgid ""
"We then check to see if the :ref:`PhysicsBody <class_PhysicsBody>` the sword "
"collided with has a function/method called ``damage`` using the "
"``has_method`` function. If the :ref:`PhysicsBody <class_PhysicsBody>` has a "
"function called ``damage_body``, we call it and pass the amount of damage "
"the sword does, ``SWORD_DAMAGE``, to it."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:883
msgid ""
"Next we check to see if the :ref:`PhysicsBody <class_PhysicsBody>` the sword "
"collided with is a :ref:`RigidBody <class_RigidBody>`. If what the sword "
"collided with is a :ref:`RigidBody <class_RigidBody>` node, we then check to "
"see if the sword is being held by a VR controller or not by checking to see "
"if ``controller`` is equal to ``null``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:886
msgid ""
"If the sword is not being held by a VR controller, ``controller`` is equal "
"to ``null``, then we move the :ref:`RigidBody <class_RigidBody>` node the "
"sword collided with using the ``apply_impulse`` function. For the "
"``position`` of the ``apply_impulse`` function, we use "
"``collision_position`` variable stored within the :ref:`KinematicCollision "
"<class_KinematicCollision>` class in ``collision_results``. For the "
"``velocity`` of the ``apply_impulse`` function, we use the "
"``collision_normal`` multiplied by the ``linear_velocity`` of the sword's :"
"ref:`RigidBody <class_RigidBody>` node multiplied by ``COLLISION_FORCE``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:891
msgid ""
"If the sword is being held by a VR controller, ``controller`` is not equal "
"to ``null``, then we move the :ref:`RigidBody <class_RigidBody>` node the "
"sword collided with using the ``apply_impulse`` function. For the "
"``position`` of the ``apply_impulse`` function, we use "
"``collision_position`` variable stored within the :ref:`KinematicCollision "
"<class_KinematicCollision>` class in ``collision_results``. For the "
"``velocity`` of the ``apply_impulse`` function, we use the "
"``collision_normal`` multiplied by the VR controller's velocity multiplied "
"by ``COLLISION_FORCE``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:895
msgid ""
"Finally, regardless of whether the :ref:`PhysicsBody <class_PhysicsBody>` is "
"a :ref:`RigidBody <class_RigidBody>` or not, we play the sound of the sword "
"colliding with something by calling ``play`` on ``sword_noise``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:900
msgid "Sword finished"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:904
msgid ""
"With that done, you can now slice through the targets! You can find the "
"sword in the corner in between the shotgun and the pistol."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:909
msgid "Updating the target UI"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:911
msgid "Let's update the UI as the sphere targets are destroyed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:913
msgid ""
"Open up ``Main_VR_GUI.tscn``, which you can find in the ``Scenes`` folder. "
"Feel free to look at how the scene is setup if you want, but in an effort to "
"keep this tutorial from becoming too long, we will not be covering the scene "
"setup in this tutorial."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:916
msgid ""
"Expand the ``GUI`` :ref:`Viewport <class_Viewport>` node and then select the "
"``Base_Control`` node. Add a new script called ``Base_Control.gd``, and add "
"the following:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:937
msgid "Let's go over how this script works real quick."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:939
msgid ""
"First, in ``_ready``, we get the :ref:`Label <class_Label>` that shows how "
"many spheres are left and assign it to the ``sphere_count_label`` class "
"variable. Next, we get ``Game.gd`` by using ``get_tree().root`` and assign "
"``sphere_ui`` to this script."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:942
msgid ""
"In ``update_ui``, we change the sphere :ref:`Label <class_Label>`'s text. If "
"there is at least one sphere remaining, we change the text to show how many "
"spheres are still left in the world. If there are no more spheres remaining, "
"we change the text and congratulate the player."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:948
msgid "Adding the final special RigidBody"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:950
msgid ""
"Finally, before we finish this tutorial, let's add a way to reset the game "
"while in VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:952
msgid ""
"Open up ``Reset_Box.tscn``, which you will find in ``Scenes``. Select the "
"``Reset_Box`` :ref:`RigidBody <class_RigidBody>` node and make a new script "
"called ``Reset_Box.gd``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:990
msgid "Let's quickly go over how this script works."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:994
#, fuzzy
msgid "Explaining the reset box code"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:996
msgid ""
"Like with the other special :ref:`RigidBody <class_RigidBody>`-based objects "
"we've created, the reset box extends ``VR_Interactable_Rigidbody``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:998
msgid ""
"The ``start_transform`` class variable will store the global transform of "
"the reset box when the game starts, the ``reset_timer`` class variable will "
"hold the length of time that has passed since the reset box's position has "
"moved, the ``RESET_TIME`` constant defines the length of time the reset box "
"has to wait before being reset, and the ``RESET_MIN_DISTANCE`` constant "
"defines how far the reset box has to be away from it's initial position "
"before the reset timer starts."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1002
msgid ""
"In the ``_ready`` function all we are doing is storing the "
"``global_transform`` of the reset position when the scene starts. This is so "
"we can reset the position, rotation, and scale of the reset box object to "
"this initial transform when enough time has passed."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1005
msgid ""
"In the ``_physics_process`` function, the code checks to see if the reset "
"box's initial position to the reset box's current position is farther than "
"``RESET_MIN_DISTANCE``. If it is farther, then it starts adding time, "
"``delta``, to ``reset_timer``. Once ``reset_timer`` is more than or equal to "
"``RESET_TIME``, we reset the ``global_transform`` to the ``start_transform`` "
"so the reset box is back in its initial position. We then set "
"``reset_timer`` to ``0``."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1009
msgid ""
"The ``interact`` function simply reloads the ``Game.tscn`` scene using "
"``get_tree().change_scene``. This will reload the game scene, resetting "
"everything."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1011
msgid ""
"Finally, the ``dropped`` function resets the ``global_transform`` to the "
"initial transform in ``start_transform`` so the reset box has its initial "
"position/rotation. Then ``reset_timer`` is set to ``0`` so the timer is "
"reset."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1016
msgid "Reset box finished"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1018
msgid ""
"With that done, when you grab and interact with the reset box, the entire "
"scene will reset/restart and you can destroy all the targets again!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1020
msgid ""
"Resetting the scene abruptly without any sort of transition can lead to "
"discomfort in VR."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1029
msgid "Whew! That was a lot of work."
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1031
msgid ""
"Now you have a fully working VR project with multiple different types of "
"special :ref:`RigidBody <class_RigidBody>`-based nodes that can be used and "
"extended. Hopefully this will help serve as an introduction to making fully-"
"featured VR games in Godot! The code and concepts detailed in this tutorial "
"can be expanded on to make puzzle games, action games, story-based games, "
"and more!"
msgstr ""

#: ../../docs/tutorials/vr/vr_starter_tutorial/vr_starter_tutorial_part_two.rst:1035
msgid ""
"You can download the finished project for this tutorial series on the "
"`OpenVR GitHub repository <https://github.com/GodotVR/godot_openvr_fps>`_, "
"under the releases tab!"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:4
msgid "Developing for Oculus Quest"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:9
msgid ""
"This tutorial goes over how to get started developing for the *Oculus Quest* "
"with an official Godot plugin."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:12
msgid "Before starting, there are two things you need to do:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:14
msgid ""
"First you need to go through the steps on the :ref:"
"`doc_exporting_for_android` page. This leads you through installing the "
"toolset that Godot needs to export to Android devices."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:18
msgid ""
"Next you need the Quest plugin. You can get it from the Asset Library or "
"manually download it from `here <https://github.com/GodotVR/godot-oculus-"
"mobile-asset>`__."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:22
msgid "Setting Up Godot"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:24
msgid "To get started open Godot and create a new project."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:28
msgid ""
"Make sure to choose the ``GLES2`` renderer. Due to the Quest's GPU this "
"backend is far better suited for the Quest."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:31
msgid ""
"Copy the addons folder from the Oculus Mobile asset into your Godot project. "
"Your project tree should look similar to this:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:36
msgid "Now you can start building the main scene:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:38
msgid "Add an :ref:`ARVROrigin <class_ARVROrigin>` node first."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:39
msgid ""
"Then add three child nodes to the origin node, one :ref:`ARVRCamera "
"<class_ARVRCamera>` and two :ref:`ARVRController <class_ARVRController>` "
"nodes."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:40
msgid ""
"Assign controller ID 1 to the first :ref:`ARVRController "
"<class_ARVRController>` and rename that to ``LeftHand``."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:41
msgid ""
"Assign controller ID 2 to the second :ref:`ARVRController "
"<class_ARVRController>` and rename that to ``RightHand``."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:42
msgid ""
"Finally add a :ref:`MeshInstance <class_MeshInstance>` as a child node to "
"our first :ref:`ARVRController <class_ARVRController>` and create a box "
"shape, resize the box so each side is set to 0.1. Now duplicate the :ref:"
"`MeshInstance <class_MeshInstance>` and move it to the second :ref:"
"`ARVRController <class_ARVRController>` node. These will stand in for our "
"controllers."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:46
msgid "Now add a script to the main node and add the following code:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:73
msgid ""
"Before you can export this project to the Quest you need to do three more "
"things."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:76
msgid ""
"First go into the project settings and make sure that the main scene is the "
"scene we run. Godot does not ask you to set this on export."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:81
msgid ""
"Then go into the export menu and configure a new Android export. if you "
"still haven't gone through the :ref:`doc_exporting_for_android` page do it "
"now. If you didn't you'll have some red messages on this screen."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:86
msgid ""
"If you did you can forge ahead and make a few small changes to the export "
"settings. First change the XR Mode to ``Oculus Mobile VR``. Then change the "
"Degrees of Freedom mode to ``6DOF``."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:92
msgid "Now save and close the export window."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:95
msgid "Setting Up Your Quest"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:97
msgid ""
"Finally take out your phone, when you got your Quest you needed to install "
"an Oculus app on it and link it up to your Quest. Start the Oculus app. "
"Press the settings cogwheel on the bottom right hand side. Select your Quest:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:104
msgid "Select \"More Settings\", and select \"Developer Mode\":"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:108
msgid "Now turn developer mode on:"
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:112
msgid "This allows you to deploy your games to the Quest."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:114
msgid ""
"Connect the Quest to your PC with the provided USB cable. Put the Quest on, "
"it may give a few dialogs to give the PC permission to deploy apps. Now hit "
"the little Android button that should be visible in the top right hand side "
"of your Godot window. It should build your game and export it to the Quest."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:120
msgid ""
"The above does the bare minimum to get your project running on the Quest, "
"it's not very exciting. Holger Dammertz has made a great toolkit for the "
"quest that contains a lot of scenes to get help you on your way including "
"really nice controller meshes."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:125
msgid ""
"You can find the toolkit `here <https://github.com/NeoSpark314/"
"godot_oculus_quest_toolkit>`__."
msgstr ""

#: ../../docs/tutorials/vr/developing_for_oculus_quest.rst:127
msgid ""
"If you want to help out with improving the plugin please join us `here "
"<https://github.com/GodotVR/godot_oculus_mobile>`__."
msgstr ""

#: ../../docs/tutorials/plugins/editor/index.rst:2
msgid "Editor plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:4
#, fuzzy
msgid "Installing plugins"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:6
msgid ""
"Godot features an editor plugin system with numerous plugins developed by "
"the community. Plugins can extend the editor's functionality with new nodes, "
"additional docks, convenience features, and more."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:11
#, fuzzy
msgid "Finding plugins"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:13
msgid ""
"The preferred way to find Godot plugins is to use the `Asset Library "
"<https://godotengine.org/asset-library/>`_. While it can be browsed online, "
"it's more convenient to use it directly from the editor. To do so, click the "
"**AssetLib** tab at the top of the editor:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:20
msgid "You can also find assets on code hosting websites such as GitHub."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:24
msgid ""
"Some repositories describe themselves as \"plugins\" but may not actually be "
"*editor* plugins. This is especially the case for scripts that are intended "
"to be used in a running project. You don't need to enable such plugins to "
"use them. Download them and extract the files in your project folder."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:29
msgid ""
"One way to distinguish editor plugins from non-editor plugins is to look for "
"a ``plugin.cfg`` file in the repository that hosts the plugin. If the "
"repository contains a ``plugin.cfg`` file in a folder placed in the ``addons/"
"`` folder, then it is an editor plugin."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:35
#, fuzzy
msgid "Installing a plugin"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:37
msgid ""
"To install a plugin, download it as a ZIP archive. On the Asset Library, "
"this can be done using the **Download** button, either from the editor or "
"using the Web interface."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:41
msgid ""
"On GitHub, if a plugin has *tags* (versions) declared, go to the "
"**Releases** tab to download a stable release. This ensures you download a "
"version that was declared to be stable by its author."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:45
msgid ""
"On GitHub, if the plugin doesn't have any *tags* declared, use the "
"**Download ZIP** button to download a ZIP of the latest revision:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:50
msgid ""
"Extract the ZIP archive and move the ``addons/`` folder it contains into "
"your project folder. If your project already contains an ``addons/`` folder, "
"move the plugin's ``addons/`` folder into your project folder to merge the "
"new folder contents with the existing one. Your file manager may ask you "
"whether to write into the folder; answer **Yes**. No files will be "
"overwritten in the process."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:57
msgid "Enabling a plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:59
msgid ""
"To enable the freshly installed plugin, open **Project > Project Settings** "
"at the top of the editor then go the **Plugins** tab. If the plugin was "
"packaged correctly, you should see it in the list of plugins. Click on the "
"gray **Inactive** text and choose **Active** to enable the plugin. The word "
"**Active** will display in green to confirm the plugin was enabled."
msgstr ""

#: ../../docs/tutorials/plugins/editor/installing_plugins.rst:68
msgid ""
"You can use the plugin immediately after enabling it; there's no need to "
"restart the editor. Likewise, disabling a plugin can be done without having "
"to restart the editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:4
msgid "Making plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:7
msgid "About plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:9
msgid ""
"A plugin is a great way to extend the editor with useful tools. It can be "
"made entirely with GDScript and standard scenes, without even reloading the "
"editor. Unlike modules, you don't need to create C++ code nor recompile the "
"engine. While this makes plugins less powerful, there are still many things "
"you can do with them. Note that a plugin is similar to any scene you can "
"already make, except it is created using a script to add editor "
"functionality."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:16
msgid ""
"This tutorial will guide you through the creation of two simple plugins so "
"you can understand how they work and be able to develop your own. The first "
"will be a custom node that you can add to any scene in the project and the "
"other will be a custom dock added to the editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:22
msgid "Creating a plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:24
msgid ""
"Before starting, create a new empty project wherever you want. This will "
"serve as a base to develop and test the plugins."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:27
msgid ""
"The first thing you need for the editor to identify a new plugin is to "
"create two files: a ``plugin.cfg`` for configuration and a tool script with "
"the functionality. Plugins have a standard path like ``addons/plugin_name`` "
"inside the project folder. Godot provides a dialog for generating those "
"files and placing them where they need to be."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:33
msgid ""
"In the main toolbar, click the ``Project`` dropdown. Then click ``Project "
"Settings...``. Go to the ``Plugins`` tab and then click on the ``Create`` "
"button in the top-right."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:37
msgid "You will see the dialog appear, like so:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:41
msgid ""
"The placeholder text in each field describes how it affects the plugin's "
"creation of the files and the config file's values."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:44
msgid "To continue with the example, use the following values::"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:55
msgid "You should end up with a directory structure like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:59
msgid ""
"``plugin.cfg`` is a simple INI file with metadata about your plugin. The "
"name and description help people understand what it does. Your name helps "
"you get properly credited for your work. The version number helps others "
"know if they have an outdated version; if you are unsure on how to come up "
"with the version number, check out `Semantic Versioning <https://semver.org/"
">`_. The main script file will instruct Godot what your plugin does in the "
"editor once it is active."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:68
msgid "The script file"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:70
msgid ""
"Upon creation of the plugin, the dialog will automatically open the "
"EditorPlugin script for you. The script has two requirements that you cannot "
"change: it must be a ``tool`` script, or else it will not load properly in "
"the editor, and it must inherit from :ref:`class_EditorPlugin`."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:76
msgid ""
"In addition to the EditorPlugin script, any other GDScript that your plugin "
"uses must *also* be a tool.  Any GDScript without ``tool`` imported into the "
"editor will act like an empty file!"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:80
msgid ""
"It's important to deal with initialization and clean-up of resources. A good "
"practice is to use the virtual function :ref:`_enter_tree() "
"<class_Node_method__enter_tree>` to initialize your plugin and :ref:"
"`_exit_tree() <class_Node_method__exit_tree>` to clean it up. Thankfully, "
"the dialog generates these callbacks for you. Your script should look "
"something like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:123
msgid "This is a good template to use when creating new plugins."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:126
msgid "A custom node"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:128
msgid ""
"Sometimes you want a certain behavior in many nodes, such as a custom scene "
"or control that can be reused. Instancing is helpful in a lot of cases, but "
"sometimes it can be cumbersome, especially if you're using it in many "
"projects. A good solution to this is to make a plugin that adds a node with "
"a custom behavior."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:136
msgid ""
"Nodes added via an EditorPlugin are \"CustomType\" nodes. While they work "
"with any scripting language, they have fewer features than :ref:`the Script "
"Class system <doc_scripting_continued_class_name>`. If you are writing "
"GDScript or NativeScript, we recommend using them instead."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:141
msgid ""
"To create a new node type, you can use the function :ref:`add_custom_type() "
"<class_EditorPlugin_method_add_custom_type>` from the :ref:"
"`class_EditorPlugin` class. This function can add new types to the editor "
"(nodes or resources). However, before you can create the type, you need a "
"script that will act as the logic for the type. While that script doesn't "
"have to use the ``tool`` keyword, it can be added so the script runs in the "
"editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:148
msgid ""
"For this tutorial, we'll create a simple button that prints a message when "
"clicked. For that, we'll need a simple script that extends from :ref:"
"`class_Button`. It could also extend :ref:`class_BaseButton` if you prefer:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:184
msgid ""
"That's it for our basic button. You can save this as ``my_button.gd`` inside "
"the plugin folder. You'll also need a 16×16 icon to show in the scene tree. "
"If you don't have one, you can grab the default one from the engine and save "
"it in your `addons/my_custom_node` folder as `icon.png`, or use the default "
"Godot logo (`preload(\"res://icon.png\")`). You can also use SVG icons if "
"desired."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:192
msgid ""
"Now, we need to add it as a custom type so it shows on the **Create New "
"Node** dialog. For that, change the ``custom_node.gd`` script to the "
"following:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:238
msgid ""
"With that done, the plugin should already be available in the plugin list in "
"the **Project Settings**, so activate it as explained in `Checking the "
"results`_."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:241
msgid "Then try it out by adding your new node:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:245
msgid ""
"When you add the node, you can see that it already has the script you "
"created attached to it. Set a text to the button, save and run the scene. "
"When you click the button, you can see some text in the console:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:252
msgid "A custom dock"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:254
msgid ""
"Sometimes, you need to extend the editor and add tools that are always "
"available. An easy way to do it is to add a new dock with a plugin. Docks "
"are just scenes based on Control, so they are created in a way similar to "
"usual GUI scenes."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:258
msgid ""
"Creating a custom dock is done just like a custom node. Create a new "
"``plugin.cfg`` file in the ``addons/my_custom_dock`` folder, then add the "
"following content to it:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:283
msgid ""
"Then create the script ``custom_dock.gd`` in the same folder. Fill it with "
"the :ref:`template we've seen before <doc_making_plugins_template_code>` to "
"get a good start."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:287
msgid ""
"Since we're trying to add a new custom dock, we need to create the contents "
"of the dock. This is nothing more than a standard Godot scene: just create a "
"new scene in the editor then edit it."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:291
msgid ""
"For an editor dock, the root node **must** be a :ref:`Control "
"<class_Control>` or one of its child classes. For this tutorial, you can "
"create a single button. The name of the root node will also be the name that "
"appears on the dock tab, so be sure to give it a short and descriptive name. "
"Also, don't forget to add some text to your button."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:299
msgid ""
"Save this scene as ``my_dock.tscn``. Now, we need to grab the scene we "
"created then add it as a dock in the editor. For this, you can rely on the "
"function :ref:`add_control_to_dock() "
"<class_EditorPlugin_method_add_control_to_dock>` from the :ref:`EditorPlugin "
"<class_EditorPlugin>` class."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:304
msgid ""
"You need to select a dock position and define the control to add (which is "
"the scene you just created). Don't forget to **remove the dock** when the "
"plugin is deactivated. The script could look like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:362
msgid ""
"Note that, while the dock will initially appear at its specified position, "
"the user can freely change its position and save the resulting layout."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:366
msgid "Checking the results"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:368
msgid ""
"It's now time to check the results of your work. Open the **Project "
"Settings** and click on the **Plugins** tab. Your plugin should be the only "
"one on the list. If it is not showing, click on the **Update** button in the "
"top-right corner."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:375
msgid ""
"You can see the plugin is inactive on the **Status** column; click on the "
"status to select **Active**. The dock should become visible before you even "
"close the settings window. You should now have a custom dock:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:382
msgid "Going beyond"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:384
msgid ""
"Now that you've learned how to make basic plugins, you can extend the editor "
"in several ways. Lots of functionality can be added to the editor with "
"GDScript; it is a powerful way to create specialized editors without having "
"to delve into C++ modules."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:389
msgid ""
"You can make your own plugins to help yourself and share them in the `Asset "
"Library <https://godotengine.org/asset-library/>`_ so that people can "
"benefit from your work."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:4
msgid "Making main screen plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:7
msgid "What this tutorial covers"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:9
msgid ""
"As seen in the :ref:`doc_making_plugins` page, making a basic plugin that "
"extends the editor is fairly easy. Main screen plugins allow you to create "
"new UIs in the central part of the editor, which appear next to the \"2D\", "
"\"3D\", \"Script\", and \"AssetLib\" buttons. Such editor plugins are "
"referred as \"Main screen plugins\"."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:15
msgid ""
"This tutorial leads you through the creation of a basic main screen plugin. "
"For the sake of simplicity, our main screen plugin will contain a single "
"button that prints text to the console."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:20
msgid "Initializing the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:22
msgid ""
"First create a new plugin from the Plugins menu. For this tutorial, we'll "
"put it in a folder called ``main_screen``, but you can use any name you'd "
"like."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:25
msgid ""
"The plugin script will come with ``_enter_tree()`` and ``_exit_tree()`` "
"methods, but for a main screen plugin we need to add a few extra methods. "
"Add five extra methods such that the script looks like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:58
msgid ""
"The important part in this script is the ``has_main_screen()`` function, "
"which is overloaded so it returns ``true``. This function is automatically "
"called by the editor on plugin activation, to tell it that this plugin adds "
"a new center view to the editor. For now, we'll leave this script as-is and "
"we'll come back to it later."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:65
msgid "Main screen scene"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:67
msgid ""
"Create a new scene with a root node derived from ``Control`` (for this "
"example plugin, we'll make the root node a ``CenterContainer``). Select this "
"root node, and in the viewport, click the ``Layout`` menu and select ``Full "
"Rect``. You also need to enable the ``Expand`` vertical size flag in the "
"inspector. The panel now uses all the space available in the main viewport."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:74
msgid ""
"Next, let's add a button to our example main screen plugin. Add a ``Button`` "
"node, and set the text to \"Print Hello\" or similar. Add a script to the "
"button like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:87
msgid ""
"Then connect the \"pressed\" signal to itself. If you need help with "
"signals, see the :ref:`doc_signals` article."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:90
msgid ""
"We are done with the main screen panel. Save the scene as ``main_panel."
"tscn``."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:93
msgid "Update the plugin script"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:95
msgid ""
"We need to update the ``main_screen_plugin.gd`` script so the plugin "
"instances our main panel scene and places it where it needs to be. Here is "
"the full plugin script:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:140
msgid ""
"A couple of specific lines were added. ``MainPanel`` is a constant that "
"holds a reference to the scene, and we instance it into "
"`main_panel_instance`."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:143
msgid ""
"The ``_enter_tree()`` function is called before ``_ready()``. This is where "
"we instance the main panel scene, and add them as children of specific parts "
"of the editor. We use ``get_editor_interface().get_editor_viewport()`` to "
"obtain the viewport and add our main panel instance as a child to it. We "
"call the ``make_visible(false)`` function to hide the main panel so it "
"doesn't compete for space when first activating the plugin."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:150
msgid ""
"The ``_exit_tree()`` function is called when the plugin is deactivated. If "
"the main screen still exists, we call ``queue_free()`` to free the instance "
"and remove it from memory."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:154
msgid ""
"The ``make_visible()`` function is overridden to hide or show the main panel "
"as needed. This function is automatically called by the editor when the user "
"clicks on the main viewport buttons at the top of the editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:158
msgid ""
"The ``get_plugin_name()`` and ``get_plugin_icon()`` functions control the "
"displayed name and icon for the plugin's main viewport button."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:161
msgid ""
"Another function you can add is the ``handles()`` function, which allows you "
"to handle a node type, automatically focusing the main screen when the type "
"is selected. This is similar to how clicking on a 3D node will automatically "
"switch to the 3D viewport."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:167
msgid "Try the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:169
msgid ""
"Activate the plugin in the Project Settings. You'll observe a new button "
"next to 2D, 3D, Script above the main viewport. Clicking it will take you to "
"your new main screen plugin, and the button in the middle will print text."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:173
msgid ""
"If you would like to try a finished version of this plugin, check out the "
"plugin demos here: https://github.com/godotengine/godot-demo-projects/tree/"
"master/plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_main_screen_plugins.rst:177
msgid ""
"If you would like to see a more complete example of what main screen plugins "
"are capable of, check out the 2.5D demo projects here: https://github.com/"
"godotengine/godot-demo-projects/tree/master/misc/2.5d"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:4
msgid "Import plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:6
msgid ""
"This tutorial assumes you already know how to make generic plugins. If in "
"doubt, refer to the :ref:`doc_making_plugins` page. This also assumes you "
"are acquainted with Godot's import system."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:13
msgid ""
"An import plugin is a special type of editor tool that allows custom "
"resources to be imported by Godot and be treated as first-class resources. "
"The editor itself comes bundled with a lot of import plugins to handle the "
"common resources like PNG images, Collada and glTF models, Ogg Vorbis "
"sounds, and many more."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:18
msgid ""
"This tutorial will show you how to create a simple import plugin to load a "
"custom text file as a material resource. This text file will contain three "
"numeric values separated by comma, which represents the three channels of a "
"color, and the resulting color will be used as the albedo (main color) of "
"the imported material. In this example it will contain the pure blue color "
"(zero red, zero green, and full blue):"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:30
msgid "Configuration"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:32
msgid ""
"First we need a generic plugin that will handle the initialization and "
"destruction of our import plugin. Let's add the ``plugin.cfg`` file first:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:45
msgid ""
"Then we need the ``material_import.gd`` file to add and remove the import "
"plugin when needed:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:64
msgid ""
"When this plugin is activated, it will create a new instance of the import "
"plugin (which we'll soon make) and add it to the editor using the :ref:"
"`add_import_plugin() <class_EditorPlugin_method_add_import_plugin>` method. "
"We store a reference to it in a class member ``import_plugin`` so we can "
"refer to it later when removing it. The :ref:`remove_import_plugin() "
"<class_EditorPlugin_method_remove_import_plugin>` method is called when the "
"plugin is deactivated to clean up the memory and let the editor know the "
"import plugin isn't available anymore."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:73
msgid ""
"Note that the import plugin is a reference type, so it doesn't need to be "
"explicitly released from memory with the ``free()`` function. It will be "
"released automatically by the engine when it goes out of scope."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:78
msgid "The EditorImportPlugin class"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:80
msgid ""
"The main character of the show is the :ref:`EditorImportPlugin class "
"<class_EditorImportPlugin>`. It is responsible for implementing the methods "
"that are called by Godot when it needs to know how to deal with files."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:85
msgid "Let's begin to code our plugin, one method at time:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:96
msgid ""
"The first method is the :ref:"
"`get_importer_name()<class_EditorImportPlugin_method_get_importer_name>`. "
"This is a unique name for your plugin that is used by Godot to know which "
"import was used in a certain file. When the files needs to be reimported, "
"the editor will know which plugin to call."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:107
msgid ""
"The :ref:"
"`get_visible_name()<class_EditorImportPlugin_method_get_visible_name>` "
"method is responsible for returning the name of the type it imports and it "
"will be shown to the user in the Import dock."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:111
msgid ""
"You should choose this name as a continuation to \"Import as\", e.g. *"
"\"Import as Silly Material\"*. You can name it whatever you want but we "
"recommend a descriptive name for your plugin."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:120
msgid ""
"Godot's import system detects file types by their extension. In the :ref:"
"`get_recognized_extensions()<class_EditorImportPlugin_method_get_recognized_extensions>` "
"method you return an array of strings to represent each extension that this "
"plugin can understand. If an extension is recognized by more than one "
"plugin, the user can select which one to use when importing the files."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:126
msgid ""
"Common extensions like ``.json`` and ``.txt`` might be used by many plugins. "
"Also, there could be files in the project that are just data for the game "
"and should not be imported. You have to be careful when importing to "
"validate the data. Never expect the file to be well-formed."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:136
msgid ""
"The imported files are saved in the ``.import`` folder at the project's "
"root. Their extension should match the type of resource you are importing, "
"but since Godot can't tell what you'll use (because there might be multiple "
"valid extensions for the same resource), you need to declare what will be "
"used in the import."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:142
msgid ""
"Since we're importing a Material, we'll use the special extension for such "
"resource types. If you are importing a scene, you can use ``scn``. Generic "
"resources can use the ``res`` extension. However, this is not enforced in "
"any way by the engine."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:152
msgid ""
"The imported resource has a specific type, so the editor can know which "
"property slot it belongs to. This allows drag and drop from the FileSystem "
"dock to a property in the Inspector."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:156
msgid ""
"In our case it's a :ref:`class_SpatialMaterial`, which can be applied to 3D "
"objects."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:159
msgid ""
"If you need to import different types from the same extension, you have to "
"create multiple import plugins. You can abstract the import code on another "
"file to avoid duplication in this regard."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:164
msgid "Options and presets"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:166
msgid ""
"Your plugin can provide different options to allow the user to control how "
"the resource will be imported. If a set of selected options is common, you "
"can also create different presets to make it easier for the user. The "
"following image shows how the options will appear in the editor:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:173
msgid ""
"Since there might be many presets and they are identified with a number, "
"it's a good practice to use an enum so you can refer to them using names."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:185
msgid ""
"Now that the enum is defined, let's keep looking at the methods of an import "
"plugin:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:193
msgid ""
"The :ref:`get_preset_count() "
"<class_EditorImportPlugin_method_get_preset_count>` method returns the "
"amount of presets that this plugins defines. We only have one preset now, "
"but we can make this method future-proof by returning the size of our "
"``Presets`` enumeration."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:208
msgid ""
"Here we have the :ref:`get_preset_name() "
"<class_EditorImportPlugin_method_get_preset_name>` method, which gives names "
"to the presets as they will be presented to the user, so be sure to use "
"short and clear names."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:213
msgid ""
"We can use the ``match`` statement here to make the code more structured. "
"This way it's easy to add new presets in the future. We use the catch all "
"pattern to return something too. Although Godot won't ask for presets beyond "
"the preset count you defined, it's always better to be on the safe side."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:218
msgid ""
"If you have only one preset you could simply return its name directly, but "
"if you do this you have to be careful when you add more presets."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:233
msgid ""
"This is the method which defines the available options. :ref:"
"`get_import_options() <class_EditorImportPlugin_method_get_import_options>` "
"returns an array of dictionaries, and each dictionary contains a few keys "
"that are checked to customize the option as its shown to the user. The "
"following table shows the possible keys:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:240
msgid "Key"
msgstr "מפתח"

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:242
#: ../../docs/development/file_formats/tscn.rst:167
msgid "``name``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:242
msgid ""
"The name of the option. When showed, underscores become spaces and first "
"letters are capitalized."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
msgid "``default_value``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
msgid "Any"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
msgid "The default value of the option for this preset."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
msgid "``property_hint``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
msgid "Enum value"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
msgid ""
"One of the :ref:`PropertyHint <enum_@GlobalScope_PropertyHint>` values to "
"use as hint."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
msgid "``hint_string``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
msgid ""
"The hint text of the property. The same as you'd add in the ``export`` "
"statement in GDScript."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
msgid "``usage``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
msgid ""
"One of the :ref:`PropertyUsageFlags <enum_@GlobalScope_PropertyUsageFlags>` "
"values to define the usage."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:253
msgid ""
"The ``name`` and ``default_value`` keys are **mandatory**, the rest are "
"optional."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:255
msgid ""
"Note that the ``get_import_options`` method receives the preset number, so "
"you can configure the options for each different preset (especially the "
"default value). In this example we use the ``match`` statement, but if you "
"have lots of options and the presets only change the value you may want to "
"create the array of options first and then change it based on the preset."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:261
msgid ""
"The ``get_import_options`` method is called even if you don't define presets "
"(by making ``get_preset_count`` return zero). You have to return an array "
"even it's empty, otherwise you can get errors."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:271
msgid ""
"For the :ref:`get_option_visibility() "
"<class_EditorImportPlugin_method_get_option_visibility>` method, we simply "
"return ``true`` because all of our options (i.e. the single one we defined) "
"are visible all the time."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:276
msgid ""
"If you need to make certain option visible only if another is set with a "
"certain value, you can add the logic in this method."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:280
msgid "The ``import`` method"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:282
msgid ""
"The heavy part of the process, responsible for converting the files into "
"resources, is covered by the :ref:`import() "
"<class_EditorImportPlugin_method_import>` method. Our sample code is a bit "
"long, so let's split in a few parts:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:298
msgid ""
"The first part of our import method opens and reads the source file. We use "
"the :ref:`File <class_File>` class to do that, passing the ``source_file`` "
"parameter which is provided by the editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:302
msgid ""
"If there's an error when opening the file, we return it to let the editor "
"know that the import wasn't successful."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:317
msgid ""
"This code takes the line of the file it read before and splits it in pieces "
"that are separated by a comma. If there are more or less than the three "
"values, it considers the file invalid and reports an error."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:321
msgid ""
"Then it creates a new :ref:`Color <class_Color>` variable and sets its "
"values according to the input file. If the ``use_red_anyway`` option is "
"enabled, then it sets the color as a pure red instead."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:330
msgid ""
"This part makes a new :ref:`SpatialMaterial <class_SpatialMaterial>` that is "
"the imported resource. We create a new instance of it and then set its "
"albedo color as the value we got before."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:338
msgid ""
"This is the last part and quite an important one, because here we save the "
"made resource to the disk. The path of the saved file is generated and "
"informed by the editor via the ``save_path`` parameter. Note that this comes "
"**without** the extension, so we add it using :ref:`string formatting "
"<doc_gdscript_printf>`. For this we call the ``get_save_extension`` method "
"that we defined earlier, so we can be sure that they won't get out of sync."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:345
msgid ""
"We also return the result from the :ref:`ResourceSaver.save() "
"<class_ResourceSaver_method_save>` method, so if there's an error in this "
"step, the editor will know about it."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:350
msgid "Platform variants and generated files"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:352
msgid ""
"You may have noticed that our plugin ignored two arguments of the ``import`` "
"method. Those are *return arguments* (hence the ``r`` at the beginning of "
"their name), which means that the editor will read from them after calling "
"your import method. Both of them are arrays that you can fill with "
"information."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:357
msgid ""
"The ``r_platform_variants`` argument is used if you need to import the "
"resource differently depending on the target platform. While it's called "
"*platform* variants, it is based on the presence of :ref:`feature tags "
"<doc_feature_tags>`, so even the same platform can have multiple variants "
"depending on the setup."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:362
msgid ""
"To import a platform variant, you need to save it with the feature tag "
"before the extension, and then push the tag to the ``r_platform_variants`` "
"array so the editor can know that you did."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:366
msgid ""
"For example, let's say we save a different material for a mobile platform. "
"We would need to do something like the following:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:374
msgid ""
"The ``r_gen_files`` argument is meant for extra files that are generated "
"during your import process and need to be kept. The editor will look at it "
"to understand the dependencies and make sure the extra file is not "
"inadvertently deleted."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:379
msgid ""
"This is also an array and should be filled with full paths of the files you "
"save. As an example, let's create another material for the next pass and "
"save it in a different file:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:395
msgid "Trying the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:397
msgid ""
"This has been theoretical, but now that the import plugin is done, let's "
"test it. Make sure you created the sample file (with the contents described "
"in the introduction section) and save it as ``test.mtxt``. Then activate the "
"plugin in the Project Settings."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:402
msgid ""
"If everything goes well, the import plugin is added to the editor and the "
"file system is scanned, making the custom resource appear on the FileSystem "
"dock. If you select it and focus the Import dock, you can see the only "
"option to select there."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:407
msgid ""
"Create a MeshInstance node in the scene, and for its Mesh property set up a "
"new SphereMesh. Unfold the Material section in the Inspector and then drag "
"the file from the FileSystem dock to the material property. The object will "
"update in the viewport with the blue color of the imported material."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:414
msgid ""
"Go to Import dock, enable the \"Use Red Anyway\" option, and click on "
"\"Reimport\". This will update the imported material and should "
"automatically update the view showing the red color instead."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:418
msgid ""
"And that's it! Your first import plugin is done! Now get creative and make "
"plugins for your own beloved formats. This can be quite useful to write your "
"data in a custom format and then use it in Godot as if they were native "
"resources. This shows how the import system is powerful and extendable."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:4
msgid "Spatial gizmo plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:9
msgid ""
"Spatial gizmo plugins are used by the editor and custom plugins to define "
"the gizmos attached to any kind of Spatial node."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:12
msgid ""
"This tutorial will show you the two main approaches to defining your own "
"custom gizmos. The first option works well for simple gizmos and creates "
"less clutter in your plugin structure, while the second one will let you "
"store some per-gizmo data."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:16
msgid ""
"This tutorial assumes you already know how to make generic plugins. If in "
"doubt, refer to the :ref:`doc_making_plugins` page."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:20
msgid "The EditorSpatialGizmoPlugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:22
msgid ""
"Regardless of the approach we choose, we will need to create a new :ref:"
"`EditorSpatialGizmoPlugin <class_EditorSpatialGizmoPlugin>`. This will allow "
"us to set a name for the new gizmo type and define other behaviors such as "
"whether the gizmo can be hidden or not."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:27
msgid "This would be a basic setup:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:57
msgid ""
"For simple gizmos, just inheriting :ref:`EditorSpatialGizmoPlugin "
"<class_EditorSpatialGizmoPlugin>` is enough. If you want to store some per-"
"gizmo data or you are porting a Godot 3.0 gizmo to 3.1+, you should go with "
"the second approach."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:63
msgid "Simple approach"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:65
msgid ""
"The first step is to, in our custom gizmo plugin, override the :ref:"
"`has_gizmo()<class_EditorSpatialGizmoPlugin_method_has_gizmo>` method so "
"that it returns ``true`` when the spatial parameter is of our target type."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:76
msgid ""
"Then we can override methods like :ref:"
"`redraw()<class_EditorSpatialGizmoPlugin_method_redraw>` or all the handle "
"related ones."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:107
msgid ""
"Note that we created a material in the `_init` method, and retrieved it in "
"the `redraw` method using :ref:"
"`get_material()<class_EditorSpatialGizmoPlugin_method_get_material>`. This "
"method retrieves one of the material's variants depending on the state of "
"the gizmo (selected and/or editable)."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:112
msgid "So the final plugin would look somewhat like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:148
msgid ""
"Note that we just added some handles in the redraw method, but we still need "
"to implement the rest of handle-related callbacks in :ref:"
"`EditorSpatialGizmoPlugin <class_EditorSpatialGizmoPlugin>` to get properly "
"working handles."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:153
msgid "Alternative approach"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:155
msgid ""
"In some cases we want to provide our own implementation of :ref:"
"`EditorSpatialGizmo<class_EditorSpatialGizmo>`, maybe because we want to "
"have some state stored in each gizmo or because we are porting an old gizmo "
"plugin and we don't want to go through the rewriting process."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:159
msgid ""
"In these cases all we need to do is, in our new gizmo plugin, override :ref:"
"`create_gizmo()<class_EditorSpatialGizmoPlugin_method_create_gizmo>`, so it "
"returns our custom gizmo implementation for the Spatial nodes we want to "
"target."
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:181
msgid ""
"This way all the gizmo logic and drawing methods can be implemented in a new "
"class extending :ref:`EditorSpatialGizmo<class_EditorSpatialGizmo>`, like so:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/spatial_gizmos.rst:217
msgid ""
"Note that we just added some handles in the redraw method, but we still need "
"to implement the rest of handle-related callbacks in :ref:"
"`EditorSpatialGizmo<class_EditorSpatialGizmo>` to get properly working "
"handles."
msgstr ""

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:4
#, fuzzy
msgid "Inspector plugins"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:6
msgid ""
"The inspector dock supports custom plugins to create your own widgets for "
"editing properties. This tutorial explains how to use the :ref:"
"`class_EditorInspectorPlugin` and :ref:`class_EditorProperty` classes to "
"write such plugins with the example of creating a custom value editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:14
msgid ""
"Just like :ref:`doc_making_plugins`, we start out by making a new plugin, "
"getting a ``plugin.cfg`` file created, and start with our :ref:"
"`class_EditorPlugin`.  However, instead of using ``add_custom_node`` or "
"``add_control_to_dock`` we'll use ``add_inspector_plugin``."
msgstr ""

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:37
#, fuzzy
msgid "EditorInspectorPlugin"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:39
msgid ""
"To actually connect into the Inspector, we create a :ref:"
"`class_EditorInspectorPlugin` class. This script provides the \"hooks\" to "
"the inspector. Thanks to this class, the editor will call the functions "
"within the EditorInspectorPlugin while it goes through the process of "
"building the UI for the inspector. The script is used to check if we should "
"enable ourselves for any :ref:`class_Object` that is currently in the "
"inspector (including any :ref:`class_Resource` that is embedded!)."
msgstr ""

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:47
msgid ""
"Once enabled, EditorInspectorPlugin has methods that allow for adding :ref:"
"`class_EditorProperty` nodes or just custom :ref:`class_Control` nodes to "
"the beginning and end of the inspector for that :ref:`class_Object`, or for "
"overriding or changing existing property editors."
msgstr ""

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:80
#, fuzzy
msgid "EditorProperty"
msgstr "פיתוח"

#: ../../docs/tutorials/plugins/editor/inspector_plugins.rst:82
msgid ""
"Next, we define the actual :ref:`class_EditorProperty` custom value editor "
"that we want instantiated to edit integers. This is a custom :ref:"
"`class_Control` and we can add any kinds of additional nodes to make "
"advanced widgets to embed in the inspector."
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:4
#, fuzzy
msgid "Visual Shader plugins"
msgstr "Android"

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:6
msgid ""
"Visual Shader plugins are used to create custom :ref:`class_VisualShader` "
"nodes in GDScript."
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:9
msgid ""
"The creation process is different from usual editor plugins. You do not need "
"to create a ``plugin.cfg`` file to register it; instead, create and save a "
"script file and it will be ready to use, provided the custom node is "
"registered with ``class_name``."
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:14
msgid ""
"This short tutorial will explain how to make a Perlin-3D noise node "
"(original code from this `GPU noise shaders plugin <https://github.com/curly-"
"brace/Godot-3.0-Noise-Shaders/blob/master/assets/gpu_noise_shaders/"
"classic_perlin3d.tres>`_."
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:18
msgid ""
"Create a Sprite and assign a :ref:`class_ShaderMaterial` to its material "
"slot:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:22
msgid "Assign :ref:`class_VisualShader` to the shader slot of the material:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:26
msgid ""
"Don't forget to change its mode to \"CanvasItem\" (if you are using a "
"Sprite):"
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:30
msgid ""
"Create a script which derives from :ref:`class_VisualShaderNodeCustom`. This "
"is all you need to initialize your plugin."
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:182
msgid ""
"Save it and open the Visual Shader. You should see your new node type within "
"the member's dialog (if you can't see your new node, try restarting the "
"editor):"
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:186
msgid "Place it on a graph and connect the required ports:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/visual_shader_plugins.rst:190
msgid ""
"That is everything you need to do, as you can see it is easy to create your "
"own custom VisualShader nodes!"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:4
msgid "GDNative C example"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:9
msgid ""
"This tutorial will introduce you to the bare minimum required to create "
"GDNative modules. This should be your starting point into the world of "
"GDNative. Understanding the contents of this tutorial will help you in "
"understanding all that is to come after this."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:14
msgid ""
"Before we begin, you can download the source code to the example object we "
"describe below in the `GDNative-demos repository <https://github.com/"
"GodotNativeTools/GDNative-demos/tree/master/c/SimpleDemo>`_."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:18
msgid ""
"This example project also contains a SConstruct file that makes compiling a "
"little easier, but in this tutorial we'll be doing things by hand to "
"understand the process."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:22
msgid ""
":ref:`GDNative <class_GDNative>` can be used to create several types of "
"additions to Godot, using interfaces such as :ref:`PluginScript "
"<class_PluginScript>` or :ref:`ARVRInterfaceGDNative "
"<class_ARVRInterfaceGDNative>`. In this tutorial we are going to look at "
"creating a :ref:`NativeScript <class_NativeScript>` module. NativeScript "
"allows you to write logic in C or C++ in a similar fashion as you would "
"write a GDScript file. We'll be creating the C equivalent of this GDScript:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:43
msgid ""
"Future tutorials will focus on the other types of GDNative modules and "
"explain when and how to use each of them."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:47
msgid "Prerequisites"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:49
msgid "Before we start you'll need a few things:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:51
msgid "A Godot executable for your target version."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:52
msgid ""
"A C compiler. On Linux, install ``gcc`` or ``clang`` from your package "
"manager. On macOS, you can install Xcode from the Mac App Store. On Windows, "
"you can use Visual Studio 2015 or later, or MinGW-w64."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:55
msgid ""
"A Git clone of the `godot_headers repository <https://github.com/"
"GodotNativeTools/godot_headers>`_: these are the C headers for Godot's "
"public API exposed to GDNative."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:59
msgid ""
"For the latter, we suggest that you create a dedicated folder for this "
"GDNative example project, open a terminal in that folder and execute:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:66
msgid "This will download the required files into that folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:70
msgid ""
"If you plan to use Git for your GDNative project, you can also add "
"``godot_headers`` as a Git submodule."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:75
msgid ""
"The ``godot_headers`` repository has different branches. As Godot evolves, "
"so does GDNative. While we try to preserve compatibility between version, "
"you should always build your GDNative module against headers matching the "
"Godot stable branch (e.g. ``3.1``) and ideally actual release (e.g. ``3.1.1-"
"stable``) that you use. GDNative modules built against older versions of the "
"Godot headers *may* work with newer versions of the engine, but not the "
"other way around."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:83
msgid ""
"The ``master`` branch of the ``godot_headers`` repository is kept in line "
"with the ``master`` branch of Godot and thus contains the GDNative class and "
"structure definitions that will work with the latest development builds."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:87
msgid ""
"If you want to write a GDNative module for a stable version of Godot, look "
"at the available Git tags (with ``git tags``) for the one matching your "
"engine version. In the ``godot_headers`` repository, such tags are prefixed "
"with ``godot-``, so you can e.g. checkout the ``godot-3.1.1-stable`` tag for "
"use with Godot 3.1.1. In your cloned repository, you can do:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:97
msgid ""
"If a tag matching your stable release is missing for any reason, you can "
"fall back to the matching stable branch (e.g. ``3.1``), which you would also "
"check out with ``git checkout 3.1``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:101
msgid ""
"If you are building Godot from source with your own changes that impact "
"GDNative, you can find the updated class and structure definition in "
"``<godotsource>/modules/gdnative/include``"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:106
msgid "Our C source"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:108
msgid ""
"Let's start by writing our main code. Eventually, we want to end up with a "
"file structure that looks along those lines:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:126
msgid ""
"Open up Godot and create a new project called \"simple\" alongside your "
"``godot_headers`` Git clone. This will create the ``simple`` folder and "
"``project.godot`` file. Then manually create a ``src`` folder alongside the "
"``simple`` folder, and a ``bin`` subfolder in the ``simple`` folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:131
msgid ""
"We're going to start by having a look at what our ``simple.c`` file "
"contains. Now, for our example here we're making a single C source file "
"without a header to keep things simple. Once you start writing bigger "
"projects it is advisable to break your project up into multiple files. That "
"however falls outside of the scope of this tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:137
msgid ""
"We'll be looking at the source code bit by bit so all the parts below should "
"all be put together into one big file. Each section will be explained as we "
"add it."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:149
msgid ""
"The above code includes the GDNative API struct header and a standard header "
"that we will use further down for string operations. It then defines two "
"pointers to two different structs. GDNative supports a large collection of "
"functions for calling back into the main Godot executable. In order for your "
"module to have access to these functions, GDNative provides your application "
"with a struct containing pointers to all these functions."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:156
msgid ""
"To keep this implementation modular and easily extendable, the core "
"functions are available directly through the \"core\" API struct, but "
"additional functions have their own \"GDNative structs\" that are accessible "
"through extensions."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:160
msgid ""
"In our example, we access one of these extension to gain access to the "
"functions specifically needed for NativeScript."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:163
msgid ""
"A NativeScript behaves like any other script in Godot. Because the "
"NativeScript API is rather low level, it requires the library to specify "
"many things more verbosely than other scripting systems, such as GDScript. "
"When a NativeScript instance gets created, a library-given constructor gets "
"called. When that instance gets destroyed, the given destructor will be "
"executed."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:176
msgid ""
"These are forward declarations for the functions we'll be implementing for "
"our object. A constructor and destructor is needed. Additionally, the object "
"will have a single method called ``get_data``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:180
msgid ""
"Next up is the first of the entry points Godot will call when our dynamic "
"library is loaded. These methods are all prefixed with ``godot_`` (you can "
"change this later on) followed by their name. ``gdnative_init`` is a "
"function that initializes our dynamic library. Godot will give it a pointer "
"to a structure that contains various bits of information we may find useful "
"among which the pointers to our API structures."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:187
msgid ""
"For any additional API structures we need to loop through our extensions "
"array and check the type of extension."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:206
msgid ""
"Next up is ``gdnative_terminate`` which is called before the library is "
"unloaded. Godot will unload the library when no object uses it anymore. "
"Here, you can do any cleanup you may need to do. For our example, we're "
"simply going to clear our API pointers."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:218
msgid ""
"Finally, we have ``nativescript_init`` which is the most important function "
"we'll need today. This function will be called by Godot as part of loading a "
"GDNative library and communicates back to the engine what objects we make "
"available."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:243
msgid ""
"We first tell the engine which classes are implemented by calling "
"``nativescript_register_class``. The first parameter here is the handle "
"pointer given to us. The second is the name of our object class. The third "
"is the type of object in Godot that we 'inherit' from; this is not true "
"inheritance but it's close enough. Finally, our fourth and fifth parameters "
"are descriptions for our constructor and destructor."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:250
msgid ""
"We then tell Godot about our methods (well our one method in this case), by "
"calling ``nativescript_register_method`` for each method of our class. In "
"our case, that is just ``get_data``. Our first parameter is yet again our "
"handle pointer. The second is again the name of the object class we're "
"registering. The third is the name of our function as it will be known to "
"GDScript. The fourth is our attributes setting (see "
"``godot_method_rpc_mode`` enum in ``godot_headers/nativescript/"
"godot_nativescript.h`` for possible values). The fifth and final parameter "
"is a description of which function to call when the method gets called."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:260
msgid ""
"The description struct ``instance_method`` contains the function pointer to "
"the function itself as first field. The other two fields in these structs "
"are for specifying per-method userdata. The second is the ``method_data`` "
"field which is passed on every function call as the ``p_method_data`` "
"argument. This is useful to reuse one function for different methods on "
"possibly multiple different script-classes. If the ``method_data`` value is "
"a pointer to memory that needs to be freed, the third ``free_func`` field "
"can contain a pointer to a function that will free that memory. That free "
"function gets called when the script itself (not instance!) gets unloaded "
"(so usually at library-unload time)."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:270
msgid ""
"Now, it's time to start working on the functions of our object. First, we "
"define a structure that we use to store the member data of an instance of "
"our GDNative class."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:280
msgid ""
"And then, we define our constructor. All we do in our constructor is "
"allocate memory for our structure and fill it with some data. Note that we "
"use Godot's memory functions so the memory gets tracked and then return the "
"pointer to our new structure. This pointer will act as our instance "
"identifier in case multiple objects are instantiated."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:286
msgid ""
"This pointer will be passed to any of our functions related to our object as "
"a parameter called ``p_user_data``, and can both be used to identify our "
"instance and to access its member data."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:299
msgid ""
"Our destructor is called when Godot is done with our object and we free our "
"instances' member data."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:308
msgid ""
"And finally, we implement our ``get_data`` function. Data is always sent and "
"returned as variants so in order to return our data, which is a string, we "
"first need to convert our C string to a Godot string object, and then copy "
"that string object into the variant we are returning."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:329
msgid ""
"Strings are heap-allocated in Godot, so they have a destructor which frees "
"the memory. Destructors are named ``godot_TYPENAME_destroy``. When a Variant "
"gets created with a String, it references the String. That means that the "
"original String can be \"destroyed\" to decrease the ref-count. If that does "
"not happen the String memory will leak since the ref-count will never be "
"zero and the memory never deallocated. The returned variant gets "
"automatically destroyed by Godot."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:338
msgid ""
"In more complex operations it can be confusing the keep track of which value "
"needs to be deallocated and which does not. As a general rule: call "
"``godot_TYPENAME_destroy`` when a C++ destructor would be called instead. "
"The String destructor would be called in C++ after the Variant was created, "
"so the same is necessary in C."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:344
msgid "The variant we return is destroyed automatically by Godot."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:346
msgid "And that is the whole source code of our module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:351
msgid ""
"We now need to compile our source code. As mentioned our example project on "
"GitHub contains a SCons configuration that does all the hard work for you, "
"but for our tutorial here we are going to call the compilers directly."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:355
msgid ""
"Assuming you are sticking to the folder structure suggested above, it is "
"best to open a terminal session in the ``src`` folder and execute the "
"commands from there. Make sure to create the ``bin`` folder before you "
"proceed."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:359
msgid "On Linux:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:366
msgid "On macOS:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:373
msgid "On Windows:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:382
msgid ""
"On the Windows build you also end up with a ``libsimple.lib`` library. This "
"is a library that you can compile into a project to provide access to the "
"DLL. We get it as a byproduct and we do not need it :) When exporting your "
"game for release this file will be ignored."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:388
msgid "Creating the GDNativeLibrary (``.gdnlib``) file"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:390
msgid ""
"With our module compiled, we now need to create a corresponding :ref:"
"`GDNativeLibrary <class_GDNativeLibrary>` resource with ``.gdnlib`` "
"extension which we place alongside our dynamic libraries. This file tells "
"Godot what dynamic libraries are part of our module and need to be loaded "
"per platform."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:396
msgid ""
"We can use Godot to generate this file, so open the \"simple\" project in "
"the editor."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:399
msgid "Start by clicking the create resource button in the Inspector:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:403
msgid "And select ``GDNativeLibrary``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:407
msgid ""
"You should see a contextual editor appear in the bottom panel. Use the "
"\"Expand Bottom Panel\" button in the bottom right to expand it to full "
"height:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:413
msgid "General properties"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:415
msgid ""
"In the Inspector, you have various properties to control loading the library."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:417
msgid ""
"If *Load Once* is enabled, our library is loaded only once and each "
"individual script that uses our library will use the same data. Any variable "
"you define globally will be accessible from any instance of your object you "
"create. If *Load Once* is disabled, a new copy of the library is loaded into "
"memory each time a script accesses the library."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:423
msgid ""
"If *Singleton* is enabled, our library is automatically loaded and a "
"function called ``godot_gdnative_singleton`` is called. We'll leave that for "
"another tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:427
msgid ""
"The *Symbol Prefix* is a prefix for our core functions, such as ``godot_`` "
"in ``godot_nativescript_init`` seen earlier. If you use multiple GDNative "
"libraries that you wish to statically link, you will have to use different "
"prefixes. This again is a subject to dive into deeper in a separate "
"tutorial, it is only needed at this time for deployment to iOS as this "
"platform does not like dynamic libraries."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:434
msgid ""
"*Reloadable* defines whether the library should be reloaded when the editor "
"loses and gains focus, typically to pick up new or modified symbols from any "
"change made to the library externally."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:439
msgid "Platform libraries"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:441
msgid ""
"The GDNativeLibrary editor plugin lets you configure two things for each "
"platform and architecture that you aim to support."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:444
msgid ""
"The *Dynamic Library* column (``entry`` section in the saved file) tells us "
"for each platform and feature combination which dynamic library has to be "
"loaded. This also informs the exporter which files need to be exported when "
"exporting to a specific platform."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:449
msgid ""
"The *Dependencies* column (also ``dependencies`` section) tells Godot what "
"other files need to be exported for each platform in order for our library "
"to work. Say that your GDNative module uses another DLL to implement "
"functionality from a 3rd party library, this is where you list that DLL."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:454
msgid ""
"For our example, we only built libraries for Linux, macOS and/or Windows, so "
"you can link them in the relevant fields by clicking the folder button. If "
"you built all three libraries, you should have something like this:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:461
#, fuzzy
msgid "Saving the resource"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:463
msgid ""
"We can then save our GDNativeLibrary resource as ``bin/libsimple.gdnlib`` "
"with the Save button in the Inspector:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:468
msgid ""
"The file is saved in a text-based format and should have contents similar to "
"this:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:495
msgid "Creating the NativeScript (``.gdns``) file"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:497
msgid ""
"With our ``.gdnlib`` file we've told Godot how to load our library, now we "
"need to tell it about our \"Simple\" object class. We do this by creating a :"
"ref:`NativeScript <class_NativeScript>` resource file with ``.gdns`` "
"extension."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:501
msgid ""
"Like done for the GDNativeLibrary resource, click the button to create a new "
"resource in the Inspector and select ``NativeScript``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:506
msgid ""
"The inspector will show a few properties that we need to fill. As *Class "
"Name* we enter \"Simple\" which is the object class name that we declared in "
"our C source when calling ``godot_nativescript_register_class``. We also "
"need to select our ``.gdnlib`` file by clicking on *Library* and selecting "
"*Load*:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:515
msgid ""
"The *Class Name* must have the same spelling as the one given in "
"``godot_nativescript_init`` when registering the class."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:519
msgid "Finally, click on the save icon and save this as ``bin/simple.gdns``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:523
msgid ""
"Now it's time to build our scene. Add a Control node to your scene as your "
"root and call it ``main``. Then add a Button and a Label as child nodes. "
"Place them somewhere nice on screen and give your button a name."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:529
msgid "Select the control node and attach a script to it:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:533
msgid "Next link up the ``pressed`` signal on the button to your script:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:537
msgid "Don't forget to save your scene, call it ``main.tscn``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:539
msgid "Now we can implement our ``main.gd`` code:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:551
msgid ""
"After all that, our project should work. The first time you run it Godot "
"will ask you what your main scene is and you select your ``main.tscn`` file "
"and presto:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:4
msgid "GDNative C++ example"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:9
msgid ""
"This tutorial builds on top of the information given in the :ref:`GDNative C "
"example <doc_gdnative_c_example>`, so we highly recommend you read that "
"first."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:13
msgid ""
"The C++ bindings for GDNative are built on top of the NativeScript GDNative "
"API and provide a nicer way to \"extend\" nodes in Godot using C++. This is "
"equivalent to writing scripts in GDScript, but in C++ instead."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:17
msgid ""
"Godot 3.1 saw the introduction of the NativeScript 1.1 additions that "
"enabled the GDNative team to build a nicer C++ bindings library. These "
"changes have now been merged into the master branch and will be the way we "
"go forward. If you want to write a C++ GDNative plugin that also supports "
"Godot 3.0 you will need to use the 3.0 branch and the NativeScript 1.0 "
"syntax. We'll be showing them side by side in this writeup."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:24
msgid ""
"You can download the full example we'll be creating in this tutorial `on "
"GitHub <https://github.com/BastiaanOlij/gdnative_cpp_example>`__."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:28
msgid "Setting up the project"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:30
msgid "There are a few prerequisites you'll need:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:32
msgid "a Godot 3.x executable,"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:33
msgid "a C++ compiler,"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:34
msgid "SCons as a build tool,"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:35
msgid ""
"a copy of the `godot-cpp repository <https://github.com/GodotNativeTools/"
"godot-cpp>`__."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:38
msgid ""
"See also :ref:`Compiling <toc-devel-compiling>` as the build tools are "
"identical to the ones you need to compile Godot from source."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:41
msgid ""
"You can download these repositories from GitHub or let Git do the work for "
"you. Note that these repositories now have different branches for different "
"versions of Godot. GDNative modules written for an earlier version of Godot "
"will work in newer versions (with the exception of one breaking change in "
"ARVR interfaces between 3.0 and 3.1) but not vice versa so make sure you "
"download the correct branch. Also note that the version of Godot you use to "
"generate the ``api.json`` with becomes your minimum version."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:49
msgid ""
"If you are versioning your project using Git, it is a good idea to add them "
"as Git submodules:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:71
msgid ""
"If you decide to just download the repositories or clone them into your "
"project folder, make sure to keep the folder layout identical to the one "
"described here, as much of the code we'll be showcasing here assumes the "
"project follows this layout."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:76
msgid "Do make sure you clone recursive to pull in both repositories:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:93
msgid ""
"``godot-cpp`` now includes ``godot_headers`` as a nested submodule, if "
"you've manually downloaded them please make sure to place ``godot_headers`` "
"inside of the ``godot-cpp`` folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:97
msgid ""
"You don't have to do it this way but we've found it easiest to manage. If "
"you decide to just download the repositories or just clone them into your "
"folder, make sure to keep the folder layout the same as we've setup here as "
"much of the code we'll be showcasing here assumes the project has this "
"layout."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:102
msgid ""
"If you cloned the example from the link specified in the introduction, the "
"submodules are not automatically initialized. You will need to execute the "
"following commands:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:111
msgid "This will clone these two repositories into your project folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:114
msgid "Building the C++ bindings"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:116
msgid ""
"Now that we've downloaded our prerequisites, it is time to build the C++ "
"bindings."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:119
msgid ""
"The repository contains a copy of the metadata for the current Godot "
"release, but if you need to build these bindings for a newer version of "
"Godot, simply call the Godot executable:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:127
msgid ""
"Place the resulting ``api.json`` file in the project folder and add "
"``use_custom_api_file=yes custom_api_file=../api.json`` to the scons command "
"below."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:131
msgid ""
"To generate and compile the bindings, use this command (replacing "
"``<platform>`` with ``windows``, ``linux`` or ``osx`` depending on your OS):"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:134
msgid ""
"To speed up compilation, add `-jN` at the end of the SCons command line "
"where `N` is the number of CPU threads you have on your system. The example "
"below uses 4 threads."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:142
msgid ""
"This step will take a while. When it is completed, you should have static "
"libraries that can be compiled into your project stored in ``godot-cpp/bin/"
"``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:145
msgid ""
"At some point in the future, compiled binaries will be available, making "
"this step optional."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:150
msgid ""
"You may need to add ``bits=64`` to the command on Windows or Linux. We're "
"still working on better auto detection."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:154
msgid "Creating a simple plugin"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:156
msgid ""
"Now it's time to build an actual plugin. We'll start by creating an empty "
"Godot project in which we'll place a few files."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:159
msgid ""
"Open Godot and create a new project. For this example, we will place it in a "
"folder called ``demo`` inside our GDNative module's folder structure."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:162
msgid ""
"In our demo project, we'll create a scene containing a Node called \"Main\" "
"and we'll save it as ``main.tscn``. We'll come back to that later."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:165
msgid ""
"Back in the top-level GDNative module folder, we're also going to create a "
"subfolder called ``src`` in which we'll place our source files."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:168
msgid ""
"You should now have ``demo``, ``godot-cpp``, ``godot_headers``, and ``src`` "
"directories in your GDNative module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:171
msgid ""
"In the ``src`` folder, we'll start with creating our header file for the "
"GDNative node we'll be creating. We will name it ``gdexample.h``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:235
msgid ""
"There are a few things of note to the above. We're including ``Godot.hpp`` "
"which contains all our basic definitions. After that, we include ``Sprite."
"hpp`` which contains bindings to the Sprite class. We'll be extending this "
"class in our module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:240
msgid ""
"We're using the namespace ``godot``, since everything in GDNative is defined "
"within this namespace."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:243
msgid ""
"Then we have our class definition, which inherits from our Sprite through a "
"container class. We'll see a few side effects of this later on. The "
"``GODOT_CLASS`` macro sets up a few internal things for us."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:247
msgid "After that, we declare a single member variable called ``time_passed``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:249
msgid ""
"In the next block we're defining our methods, we obviously have our "
"constructor and destructor defined, but there are two other functions that "
"will likely look familiar to some, and one new method."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:253
msgid ""
"The first is ``_register_methods``, which is a static function that Godot "
"will call to find out which methods can be called on our NativeScript and "
"which properties it exposes. The second is our ``_process`` function, which "
"will work exactly the same as the ``_process`` function you're used to in "
"GDScript. The third is our ``_init`` function which is called after Godot "
"has properly set up our object. It has to exist even if you don't place any "
"code in it."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:260
msgid "Let's implement our functions by creating our ``gdexample.cpp`` file:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:320
msgid ""
"This one should be straightforward. We're implementing each method of our "
"class that we defined in our header file. Note that the ``register_method`` "
"call **must** expose the ``_process`` method, otherwise Godot will not be "
"able to use it. However, we do not have to tell Godot about our constructor, "
"destructor and ``_init`` functions."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:326
msgid ""
"The other method of note is our ``_process`` function, which simply keeps "
"track of how much time has passed and calculates a new position for our "
"sprite using a simple sine and cosine function. What stands out is calling "
"``owner->set_position`` to call one of the build in methods of our Sprite. "
"This is because our class is a container class; ``owner`` points to the "
"actual Sprite node our script relates to. In the upcoming NativeScript 1.1, "
"``set_position`` can be called directly on our class."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:334
msgid ""
"There is one more C++ file we need; we'll name it ``gdlibrary.cpp``. Our "
"GDNative plugin can contain multiple NativeScripts, each with their own "
"header and source file like we've implemented ``GDExample`` up above. What "
"we need now is a small bit of code that tells Godot about all the "
"NativeScripts in our GDNative plugin."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:358
msgid ""
"Note that we are not using the ``godot`` namespace here, since the three "
"functions implemented here need to be defined without a namespace."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:361
msgid ""
"The ``godot_gdnative_init`` and ``godot_gdnative_terminate`` functions get "
"called respectively when Godot loads our plugin and when it unloads it. All "
"we're doing here is parse through the functions in our bindings module to "
"initialize them, but you might have to set up more things depending on your "
"needs."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:367
msgid ""
"The important function is the third function called "
"``godot_nativescript_init``. We first call a function in our bindings "
"library that does its usual stuff. After that, we call the function "
"``register_class`` for each of our classes in our library."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:373
msgid "Compiling the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:375
msgid ""
"We cannot easily write by hand a ``SConstruct`` file that SCons would use "
"for building. For the purpose of this example, just use :download:`this "
"hardcoded SConstruct file <files/cpp_example/SConstruct>` we've prepared. "
"We'll cover a more customizable, detailed example on how to use these build "
"files in a subsequent tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:383
msgid ""
"This ``SConstruct`` file was written to be used with the latest ``godot-"
"cpp`` master, you may need to make small changes using it with older "
"versions or refer to the ``SConstruct`` file in the Godot 3.0 documentation."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:387
msgid ""
"Once you've downloaded the ``SConstruct`` file, place it in your GDNative "
"module folder besides ``godot-cpp``, ``godot_headers`` and ``demo``, then "
"run:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:394
msgid "You should now be able to find the module in ``demo/bin/<platform>``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:398
msgid ""
"Here, we've compiled both godot-cpp and our gdexample library as debug "
"builds. For optimized builds, you should compile them using the "
"``target=release`` switch."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:403
msgid "Using the GDNative module"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:405
msgid ""
"Before we jump back into Godot, we need to create two more files in ``demo/"
"bin/``. Both can be created using the Godot editor, but it may be faster to "
"create them directly."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:409
msgid ""
"The first one is a file that lets Godot know what dynamic libraries should "
"be loaded for each platform and is called ``gdexample.gdnlib``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:433
msgid ""
"This file contains a ``general`` section that controls how the module is "
"loaded. It also contains a prefix section which should be left on ``godot_`` "
"for now. If you change this, you'll need to rename various functions that "
"are used as entry points. This was added for the iPhone platform because it "
"doesn't allow dynamic libraries to be deployed, yet GDNative modules are "
"linked statically."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:439
msgid ""
"The ``entry`` section is the important bit: it tells Godot the location of "
"the dynamic library in the project's filesystem for each supported platform. "
"It will also result in *just* that file being exported when you export the "
"project, which means the data pack won't contain libraries that are "
"incompatible with the target platform."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:445
msgid ""
"Finally, the ``dependencies`` section allows you to name additional dynamic "
"libraries that should be included as well. This is important when your "
"GDNative plugin implements someone else's library and requires you to supply "
"a third-party dynamic library with your project."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:450
msgid ""
"If you double click on the ``gdexample.gdnlib`` file within Godot, you'll "
"see there are far more options to set:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:455
msgid ""
"The second file we need to create is a file used by each NativeScript we've "
"added to our plugin. We'll name it ``gdexample.gdns`` for our gdexample "
"NativeScript."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:471
msgid ""
"This is a standard Godot resource; you could just create it directly in your "
"scene, but saving it to a file makes it much easier to reuse it in other "
"places. This resource points to our gdnlib file, so that Godot can know "
"which dynamic library contains our NativeScript. It also defines the "
"``class_name`` which identifies the NativeScript in our plugin we want to "
"use."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:477
msgid ""
"Time to jump back into Godot. We load up the main scene we created way back "
"in the beginning and now add a Sprite to our scene:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:482
msgid ""
"We're going to assign the Godot logo to this sprite as our texture, disable "
"the ``centered`` property and drag our ``gdexample.gdns`` file onto the "
"``script`` property of the sprite:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:488
msgid "We're finally ready to run the project:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:493
msgid "Adding properties"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:495
msgid ""
"GDScript allows you to add properties to your script using the ``export`` "
"keyword. In GDNative you have to register the properties and there are two "
"ways of doing this. You can either bind directly to a member or use a setter "
"and getter function."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:502
msgid ""
"There is a third option, just like in GDScript you can directly implement "
"the ``_get_property_list``, ``_get`` and ``_set`` methods of an object but "
"that goes far beyond the scope of this tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:506
msgid ""
"We'll examine both starting with the direct bind. Lets add a property that "
"allows us to control the amplitude of our wave."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:509
msgid ""
"In our ``gdexample.h`` file we simply need to add a member variable like so:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:519
msgid ""
"In our ``gdexample.cpp`` file we need to make a number of changes, we will "
"only show the methods we end up changing, don't remove the lines we're "
"omitting:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:571
msgid ""
"Once you compile the module with these changes in place you will see that a "
"property has been added to our interface. You can now change this property "
"and when you run your project, you will see that our Godot icon travels "
"along a larger figure."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:578
msgid ""
"The ``reloadable`` property in the ``gdexample.gdnlib`` file must be set to "
"``true`` for the Godot editor to automatically pick up the newly added "
"property."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:582
msgid ""
"However, this setting should be used with care especially when tool classes "
"are used, as the editor might hold objects then that have script instances "
"attached to them that are managed by a GDNative library."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:586
msgid ""
"Lets do the same but for the speed of our animation and use a setter and "
"getter function. Our ``gdexample.h`` header file again only needs a few more "
"lines of code:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:601
msgid ""
"This requires a few more changes to our ``gdexample.cpp`` file, again we're "
"only showing the methods that have changed so don't remove anything we're "
"omitting:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:673
msgid ""
"Now when the project is compiled we'll see another property called speed. "
"Changing its value will make the animation go faster or slower."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:676
msgid ""
"For this example there is no obvious advantage of using a setter and getter. "
"It is just more code to write. For a simple example as this there may be a "
"good reason for a setter if you want to react on the variable being changed "
"but in many cases just binding the variable will be enough."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:681
msgid ""
"Getters and setters become far more useful in more complex scenarios where "
"you need to make additional choices based on the state of your object."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:686
msgid ""
"For simplicity we've left out the optional parameters in the "
"register_property<class, type> method call. These parameters are "
"``rpc_mode``, ``usage``, ``hint`` and ``hint_string``. These can be used to "
"further configure how properties are displayed and set on the Godot side."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:691
msgid ""
"Modern C++ compilers are able to infer the class and variable type and allow "
"you to omit the ``<GDExample, float>`` part of our ``register_property`` "
"method. We've had mixed experiences with this however."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:698
msgid ""
"Last but not least, signals fully work in GDNative as well. Having your "
"module react to a signal given out by another object requires you to call "
"``connect`` on that object. We can't think of a good example for our "
"wobbling Godot icon, we would need to showcase a far more complete example."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:703
msgid "This however is the required syntax:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:714
msgid ""
"Note that you can only call ``my_method`` if you've previously registered it "
"in your ``_register_methods`` method."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:717
msgid ""
"Having your object sending out signals is far more common. For our wobbling "
"Godot icon we'll do something silly just to show how it works. We're going "
"to emit a signal every time a second has passed and pass the new location "
"along."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:721
msgid ""
"In our ``gdexample.h`` header file we just need to define a new member "
"``time_emit``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:732
msgid ""
"The changes in ``gdexample.cpp`` are a bit more elaborate this time. First "
"you'll need to set ``time_emit = 0.0;`` in either our ``_init`` method or in "
"our constructor. But the other two needed changes we'll look at one by one."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:736
msgid ""
"In our ``_register_methods`` method we need to declare our signal and we do "
"this as follows:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:763
msgid ""
"Here we see a nice improvement in the latest version of godot-cpp where our "
"``register_signal`` method can be a single call first taking the signals "
"name, then having pairs of values specifying the parameter name and type of "
"each parameter we'll send along with this signal."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:768
msgid ""
"For NativeScript 1.0 we first build a dictionary in which we tell Godot "
"about the types of arguments we will pass to our signal, and then register "
"it."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:771
msgid "Next we'll need to change our ``_process`` method:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:817
msgid ""
"After a second has passed we emit our signal and reset our counter. Again in "
"the new version of godot-cpp we can add our parameter values directly to "
"``emit_signal``. In NativeScript 1.0 We first build an array of values and "
"then call ``emit_signal``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:822
msgid ""
"Once compiled we can go into Godot and select our sprite node. On our "
"``Node`` tab we find our new signal and link it up by pressing connect. "
"We've added a script on our main node and implemented our signal like this:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:833
msgid "Every second we simply output our position to the console."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:836
msgid "NativeScript 1.1 vs NativeScript 1.0"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:838
msgid ""
"So far in our example above there doesn't seem to be a lot of difference "
"between the old and new syntax. The class is defined slightly differently "
"and we no longer use the ``owner`` member to call methods on the Godot side "
"of our object. A lot of the improvements are hidden under the hood."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:843
msgid ""
"This example only deals with simple variables and simple methods. Especially "
"once you start passing references to other objects or when you start calling "
"methods that require more complex parameters, NativeScript 1.1 does start to "
"show its benefits."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:851
msgid ""
"The above is only a simple example, but we hope it shows you the basics. You "
"can build upon this example to create full-fledged scripts to control nodes "
"in Godot using C++."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:855
msgid ""
"You should be able to edit and recompile the plugin while the Godot editor "
"remains open; just rerun the project after the library has finished building."
msgstr ""

#: ../../docs/tutorials/plugins/android/index.rst:2
#, fuzzy
msgid "Android plugins"
msgstr "Android"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:4
#, fuzzy
msgid "Creating Android plugins (Godot 3.2.2+)"
msgstr "אנימציות"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:9
msgid ""
"Android plugins are powerful tools to extend the capabilities of the Godot "
"engine by tapping into the functionality provided by the Android platform "
"and ecosystem."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:12
msgid ""
"Mobile gaming monetization is one such example since it requires features "
"and capabilities that don't belong to the core feature set of a game engine:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:15
msgid "Analytics"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:16
msgid "In-app purchases"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:17
msgid "Receipt validation"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:18
msgid "Install tracking"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:19
msgid "Ads"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:20
msgid "Video ads"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:21
msgid "Cross-promotion"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:22
msgid "In-game soft & hard currencies"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:23
msgid "Promo codes"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:24
msgid "A/B testing"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:25
msgid "Login"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:26
msgid "Cloud saves"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:27
msgid "Leaderboards and scores"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:28
msgid "User support & feedback"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:29
msgid "Posting to Facebook, Twitter, etc."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:30
msgid "Push notifications"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:33
#, fuzzy
msgid "Android plugin"
msgstr "Android"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:35
msgid ""
"While introduced in Godot 3.2.0, the Android plugin system got a significant "
"architecture update starting with Godot 3.2.2. The new plugin system is "
"backward-incompatible with the previous one, but both systems are kept "
"functional in future releases of the 3.2.x branch. Since we previously did "
"not version the Android plugin systems, the new one is now labelled ``v1`` "
"and is the starting point for the modern Godot Android ecosystem."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:37
msgid ""
"**Note:** In Godot 4.0, the previous system will be fully deprecated and "
"removed."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:39
msgid ""
"As a prerequisite, make sure you understand how to set up a :ref:`custom "
"build environment<doc_android_custom_build>` for Android."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:41
msgid ""
"At its core, a Godot Android plugin is a `Android archive library <https://"
"developer.android.com/studio/projects/android-library#aar-contents>`_ (*aar* "
"archive file) with the following caveats:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:44
msgid ""
"The library must have a dependency on the Godot engine library (``godot-lib."
"<version>.<status>.aar``). A stable version is made available for each Godot "
"release on the `Godot download page <https://godotengine.org/download>`_."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:46
msgid ""
"The library must include a specifically configured ``<meta-data>`` tag in "
"its manifest file."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:49
#, fuzzy
msgid "Building a Android plugin"
msgstr "אנימציות"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:51
msgid ""
"**Prerequisite:** `Android Studio <https://developer.android.com/studio>`_ "
"is strongly recommended as the IDE to use to create Android plugins. The "
"instructions below assumes that you're using Android Studio."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:54
msgid ""
"Follow `these instructions <https://developer.android.com/studio/projects/"
"android-library>`__ to create an Android library module for your plugin."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:56
msgid "Add the Godot engine library as a dependency to your plugin module:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:58
msgid ""
"Download the Godot engine library (``godot-lib.<version>.<status>.aar``) "
"from the `Godot download page <https://godotengine.org/download>`_ (e.g: "
"``godot-lib.3.2.2.stable.aar``)."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:60
msgid ""
"Follow `these instructions <https://developer.android.com/studio/projects/"
"android-library#AddDependency>`__ to add the Godot engine library as a "
"dependency for your plugin."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:63
msgid ""
"In the plugin module's ``build.gradle`` file, replace ``implementation`` "
"with ``compileOnly`` for the dependency line for the Godot engine library."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:65
msgid ""
"Create a new class in the plugin module and make sure it extends ``org."
"godotengine.godot.plugin.GodotPlugin``. At runtime, it will be used to "
"instantiate a singleton object that will be used by the Godot engine to "
"load, initialize and run the plugin."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:68
msgid "Update the plugin ``AndroidManifest.xml`` file:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:70
msgid "Open the plugin ``AndroidManifest.xml`` file."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:72
msgid "Add the ``<application></application>`` tag if it's missing."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:74
msgid ""
"In the ``<application>`` tag, add a ``<meta-data>`` tag setup as follow::"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:80
msgid ""
"Where ``PluginName`` is the name of the plugin, and ``plugin.init."
"ClassFullName`` is the full name (package + class name) of the plugin "
"loading class."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:82
msgid ""
"Add the remaining logic for your plugin and run the ``gradlew build`` "
"command to generate the plugin's ``aar`` file. The build will likely "
"generate both a ``debug`` and ``release`` ``aar`` files. Depending on your "
"need, pick only one version (usually the ``release`` one) which to provide "
"your users with."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:86
msgid ""
"It's recommended that the ``aar`` filename matches the following pattern: "
"``[PluginName]*.aar`` where ``PluginName`` is the name of the plugin in "
"PascalCase (e.g.: ``GodotPayment.release.aar``)."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:88
msgid ""
"Create a Godot Android Plugin configuration file to help the system detect "
"and load your plugin:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:90
msgid ""
"The configuration file extension must be ``gdap`` (e.g.: ``MyPlugin.gdap``)."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:92
msgid "The configuration file format is as follow::"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:106
msgid "The ``config`` section and fields are required and defined as follow:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:108
msgid "**name**: name of the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:110
msgid ""
"**binary_type**: can be either ``local`` or ``remote``. The type affects the "
"**binary** field"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:112
msgid "**binary**:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:114
msgid ""
"if **binary_type** is ``local``, then this should be the filepath of the "
"plugin ``aar`` file."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:116
msgid ""
"The filepath can be relative (e.g.: ``MyPlugin.aar``) in which case it's "
"relative to the ``res://android/plugins`` directory."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:118
msgid "The filepath can be absolute: ``res://some_path/MyPlugin.aar``."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:120
msgid ""
"if **binary_type** is ``remote``, then this should be a declaration for a "
"`remote gradle binary <https://developer.android.com/studio/build/"
"dependencies#dependency-types>`_ (e.g.: ``org.godot.example:my-"
"plugin:0.0.0``)."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:122
msgid ""
"The ``dependencies`` section and fields are optional and defined as follow:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:124
msgid ""
"**local**: contains a list of filepaths to the local ``.aar`` binary files "
"the plugin depends on. Similarly to the ``binary`` field (when the "
"``binary_type`` is ``local``), the local binaries' filepaths can be relative "
"or absolute."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:126
msgid ""
"**remote**: contains a list of remote binary gradle dependencies for the "
"plugin."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:128
msgid ""
"**custom_maven_repos**: contains a list of URLs specifying the custom maven "
"repositories required for the plugin's dependencies"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:131
#, fuzzy
msgid "Loading and using a Android plugin"
msgstr "אנימציות"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:133
msgid ""
"Move the plugin configuration file (e.g.: ``MyPlugin.gdap``) and, if any, "
"its local binary (e.g.: ``MyPlugin.aar``) and dependencies to the Godot "
"project's ``res://android/plugins`` directory."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:135
msgid ""
"The Godot editor will automatically parse all ``.gdap`` files in the ``res://"
"android/plugins`` directory and show a list of detected and toggleable "
"plugins in the Android export presets window under the **Plugins** section."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:139
#, fuzzy
msgid "From your script:"
msgstr "תיאור"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:149
#, fuzzy
msgid "Bundling GDNative resources"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/plugins/android/android_plugin.rst:150
msgid ""
"A Android plugin can define and provide C/C++ GDNative resources, either to "
"provide and/or access functionality from the game logic. The GDNative "
"resources can be bundled within the plugin ``aar`` file which simplifies the "
"distribution and deployment process:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:153
msgid ""
"The shared libraries (``.so``) for the defined GDNative libraries will be "
"automatically bundled by the ``aar`` build system."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:155
msgid ""
"Godot ``*.gdnlib`` and ``*.gdns`` resource files must be manually defined in "
"the plugin ``assets`` directory. The recommended path for these resources "
"relative to the ``assets`` directory should be: ``godot/plugin/v1/"
"[PluginName]/``."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:158
msgid ""
"For GDNative libraries, the plugin singleton object must override the ``org."
"godotengine.godot.plugin.GodotPlugin::getPluginGDNativeLibrariesPaths()`` "
"method, and return the paths to the bundled GDNative libraries config files "
"(``*.gdnlib``). The paths must be relative to the ``assets`` directory. At "
"runtime, the plugin will provide these paths to Godot core which will use "
"them to load and initialize the bundled GDNative libraries."
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:163
msgid "Reference implementations"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:164
msgid ""
"`Godot Oculus Mobile plugin <https://github.com/GodotVR/"
"godot_oculus_mobile>`_"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:166
msgid ""
"`Bundled gdnative resources <https://github.com/GodotVR/godot_oculus_mobile/"
"tree/master/plugin/src/main/assets/addons/godot_ovrmobile>`_"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:168
msgid ""
"`Godot Payment plugin <https://github.com/godotengine/godot/tree/master/"
"platform/android/java/plugins/godotpayment>`_"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:172
#: ../../docs/development/compiling/compiling_for_windows.rst:223
#: ../../docs/development/compiling/compiling_for_android.rst:200
#: ../../docs/development/editor/creating_icons.rst:92
msgid "Troubleshooting"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:175
msgid "Godot crashes upon load"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:177
msgid "Check ``adb logcat`` for possible problems, then:"
msgstr ""

#: ../../docs/tutorials/plugins/android/android_plugin.rst:179
msgid ""
"Check that the methods used in the Java singleton only use simple Java "
"datatypes. More complex datatypes are not supported."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:4
msgid "Android in-app purchases"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:6
msgid ""
"Godot offers a first-party ``GodotGooglePlayBilling`` Android plugin since "
"Godot 3.2.2. The new plugin uses the `Google Play Billing library <https://"
"developer.android.com/google/play/billing>`__ instead of the now deprecated "
"AIDL IAP implementation."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:10
msgid ""
"If you learn better by looking at an example, you can find the demo project "
"`here <https://github.com/godotengine/godot-demo-projects/tree/master/misc/"
"android_iap>`__."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:15
msgid "Migrating from Godot 3.2.1 and lower (GodotPaymentsV3)"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:17
msgid ""
"The new ``GodotGooglePlayBilling`` API is not compatible with its "
"predecessor ``GodotPaymentsV3``."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:20
msgid "Changes"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:22
msgid ""
"You need to enable the Custom Build option in your Android export settings "
"and install the ``GodotGooglePlayBilling`` plugin manually (see below for "
"details)"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:24
msgid ""
"All purchases have to be acknowledged by your app. This is a `requirement "
"from Google <https://developer.android.com/google/play/billing/"
"integrate#process>`__. Purchases that are not acknowledged by your app will "
"be refunded."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:27
msgid "Support for subscriptions"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:28
msgid "Signals (no polling or callback objects)"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:37
msgid ""
"If not already done, make sure you have enabled and successfully set up :ref:"
"`Android Custom Builds <doc_android_custom_build>`. Grab "
"the``GodotGooglePlayBilling`` plugin binary and config from the `releases "
"page <https://github.com/godotengine/godot-google-play-billing/releases>`__ "
"and put both into `res://android/plugins`. The plugin should now show up in "
"the Android export settings, where you can enable it."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:46
msgid ""
"To use the ``GodotGooglePlayBilling`` API you first have to get the "
"``GodotGooglePlayBilling`` singleton and start the connection:"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:75
msgid ""
"All API methods only work if the API is connected. You can use ``payment."
"isReady()`` to check the connection status."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:79
msgid "Querying available items"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:81
msgid ""
"As soon as the API is connected, you can query SKUs using "
"``querySkuDetails``."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:83
#: ../../docs/tutorials/platform/android_in_app_purchases.rst:115
msgid "Full example:"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:96
msgid "Purchase an item"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:98
msgid ""
"To initiate the purchase flow for an item, call ``purchase``. You **must** "
"query the SKU details for an item before you can initiate the purchase flow "
"for it."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:109
msgid "Check if the user purchased an item"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:111
msgid ""
"To get all purchases, call ``queryPurchases``. Unlike most of the other "
"functions, ``queryPurchases`` is a synchronous operation and returns a :ref:"
"`Dictionary <class_Dictionary>` with a status code and either an array of "
"purchases or an error message."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:129
#, fuzzy
msgid "Consumables"
msgstr "קבועים"

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:131
msgid ""
"If your in-app item is not a one-time purchase but a consumable item (e.g. "
"coins) which can be purchased multiple times, you can consume an item by "
"calling ``consumePurchase`` with a purchase token. Call ``queryPurchases`` "
"to get the purchase token. Calling ``consumePurchase`` automatically "
"acknowledges a purchase."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:148
#, fuzzy
msgid "Subscriptions"
msgstr "תיאור"

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:150
msgid ""
"Subscriptions don't work much different from regular in-app items. Just use "
"``\"subs\"`` as second argument to ``querySkuDetails`` to get subscription "
"details. Check ``is_auto_renewing`` in the results of ``queryPurchases()`` "
"to see if a user has cancelled an auto-renewing subscription"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:6
msgid ""
"At the moment, there are two iOS APIs partially implemented, GameCenter and "
"Storekit. Both use the same model of asynchronous calls explained below."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:11
msgid "Asynchronous methods"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:13
msgid ""
"When requesting an asynchronous operation, the method will look like this:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:20
msgid ""
"The parameter will usually be a Dictionary, with the information necessary "
"to make the request, and the call will have two phases. First, the method "
"will immediately return an Error value. If the Error is not 'OK', the call "
"operation is completed, with an error probably caused locally (no internet "
"connection, API incorrectly configured, etc). If the error value is 'OK', a "
"response event will be produced and added to the 'pending events' queue. "
"Example:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:47
msgid ""
"Remember that when a call returns OK, the API will *always* produce an event "
"through the pending_event interface, even if it's an error, or a network "
"timeout, etc. You should be able to, for example, safely block the interface "
"waiting for a reply from the server. If any of the APIs don't behave this "
"way it should be treated as a bug."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:53
msgid "The pending event interface consists of two methods:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:55
msgid ""
"``get_pending_event_count()`` Returns the number of pending events on the "
"queue."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:58
msgid ""
"``Variant pop_pending_event()`` Pops the first event from the queue and "
"returns it."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:62
msgid "Store Kit"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:64
msgid "Implemented in ``platform/iphone/in_app_store.mm``."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:66
msgid ""
"The Store Kit API is accessible through the \"InAppStore\" singleton (will "
"always be available from gdscript). It is initialized automatically. It has "
"three methods for purchasing:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:70
msgid "``Error purchase(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:71
msgid "``Error request_product_info(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:72
msgid "``Error restore_purchases();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:74
msgid "and the pending_event interface"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:82
msgid "purchase"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:84
msgid "Purchases a product id through the Store Kit API."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:89
msgid ""
"Takes a Dictionary as a parameter, with one field, ``product_id``, a string "
"with your product id. Example:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:97
#: ../../docs/tutorials/platform/services_for_ios.rst:137
#: ../../docs/tutorials/platform/services_for_ios.rst:161
#: ../../docs/tutorials/platform/services_for_ios.rst:212
#: ../../docs/tutorials/platform/services_for_ios.rst:259
#: ../../docs/tutorials/platform/services_for_ios.rst:288
#: ../../docs/tutorials/platform/services_for_ios.rst:318
#: ../../docs/tutorials/platform/services_for_ios.rst:350
#: ../../docs/tutorials/platform/services_for_ios.rst:407
msgid "Response event"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:99
#: ../../docs/tutorials/platform/services_for_ios.rst:139
#: ../../docs/tutorials/platform/services_for_ios.rst:214
#: ../../docs/tutorials/platform/services_for_ios.rst:261
#: ../../docs/tutorials/platform/services_for_ios.rst:290
#: ../../docs/tutorials/platform/services_for_ios.rst:320
#: ../../docs/tutorials/platform/services_for_ios.rst:352
#: ../../docs/tutorials/platform/services_for_ios.rst:409
msgid "The response event will be a dictionary with the following fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:101
#: ../../docs/tutorials/platform/services_for_ios.rst:216
#: ../../docs/tutorials/platform/services_for_ios.rst:263
#: ../../docs/tutorials/platform/services_for_ios.rst:292
#: ../../docs/tutorials/platform/services_for_ios.rst:322
#: ../../docs/tutorials/platform/services_for_ios.rst:354
msgid "On error:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:111
#: ../../docs/tutorials/platform/services_for_ios.rst:227
#: ../../docs/tutorials/platform/services_for_ios.rst:273
#: ../../docs/tutorials/platform/services_for_ios.rst:302
#: ../../docs/tutorials/platform/services_for_ios.rst:332
#: ../../docs/tutorials/platform/services_for_ios.rst:364
msgid "On success:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:122
msgid "request_product_info"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:124
msgid "Requests the product info on a list of product IDs."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:129
msgid ""
"Takes a Dictionary as a parameter, with one field, ``product_ids``, a string "
"array with a list of product ids. Example:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:155
msgid "restore_purchases"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:157
msgid ""
"Restores previously made purchases on user's account. This will create "
"response events for each previously purchased product id."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:163
msgid "The response events will be dictionaries with the following fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:174
msgid "Game Center"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:176
msgid "Implemented in ``platform/iphone/game_center.mm``."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:178
msgid ""
"The Game Center API is available through the \"GameCenter\" singleton. It "
"has 8 methods:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:181
msgid "``bool is_authenticated();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:182
msgid "``Error post_score(Variant p_score);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:183
msgid "``Error award_achievement(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:184
msgid "``void reset_achievements();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:185
msgid "``void request_achievements();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:186
msgid "``void request_achievement_descriptions();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:187
msgid "``Error show_game_center(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:188
msgid "``Error request_identity_verification_signature();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:190
msgid "plus the standard pending event interface."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:193
msgid "post_score"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:195
msgid "Posts a score to a Game Center leaderboard."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:200
#: ../../docs/tutorials/platform/services_for_ios.rst:389
msgid "Takes a Dictionary as a parameter, with two fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:202
msgid "``score`` a float number"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:203
msgid "``category`` a string with the category name"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:237
msgid "award_achievement"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:239
msgid "Modifies the progress of a Game Center achievement."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:244
msgid "Takes a Dictionary as a parameter, with 3 fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:246
msgid "``name`` (string) the achievement name"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:247
msgid ""
"``progress`` (float) the achievement progress from 0.0 to 100.0 (passed to "
"``GKAchievement::percentComplete``)"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:249
msgid ""
"``show_completion_banner`` (bool) whether Game Center should display an "
"achievement banner at the top of the screen"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:283
msgid "reset_achievements"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:285
msgid "Clears all Game Center achievements. The function takes no parameters."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:312
msgid "request_achievements"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:314
msgid ""
"Request all the Game Center achievements the player has made progress on. "
"The function takes no parameters."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:344
msgid "request_achievement_descriptions"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:346
msgid ""
"Request the descriptions of all existing Game Center achievements regardless "
"of progress. The function takes no parameters."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:381
msgid "show_game_center"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:383
msgid ""
"Displays the built in Game Center overlay showing leaderboards, "
"achievements, and challenges."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:391
msgid ""
"``view`` (string) (optional) the name of the view to present. Accepts "
"\"default\", \"leaderboards\", \"achievements\", or \"challenges\". Defaults "
"to \"default\"."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:394
msgid ""
"``leaderboard_name`` (string) (optional) the name of the leaderboard to "
"present. Only used when \"view\" is \"leaderboards\" (or \"default\" is "
"configured to show leaderboards). If not specified, Game Center will display "
"the aggregate leaderboard."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:411
msgid "On close:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:421
msgid "Multi-platform games"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:423
msgid ""
"When working on a multi-platform game, you won't always have the \"GameCenter"
"\" singleton available (for example when running on PC or Android). Because "
"the gdscript compiler looks up the singletons at compile time, you can't "
"just query the singletons to see and use what you need inside a conditional "
"block, you need to also define them as valid identifiers (local variable or "
"class member). This is an example of how to work around this in a class:"
msgstr ""

#: ../../docs/tutorials/platform/platform_html5.rst:4
msgid "HTML5"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:4
msgid "HTML5 shell class reference"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:6
msgid ""
"Projects exported for the Web expose the ``Engine`` class to the JavaScript "
"environment, that allows fine control over the engine's start-up process."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:9
msgid ""
"This API is built in an asynchronous manner and requires basic understanding "
"of `Promises <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/"
"Using_promises>`__."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:13
#: ../../docs/tutorials/platform/html5_shell_classref.rst:43
#, fuzzy
msgid "Engine"
msgstr "על Godot"

#: ../../docs/tutorials/platform/html5_shell_classref.rst:15
msgid ""
"The ``Engine`` class provides methods for loading and starting exported "
"projects on the Web. For default export settings, this is already part of "
"the exported HTML page. To understand practical use of the ``Engine`` class, "
"see :ref:`Custom HTML page for Web export <doc_customizing_html5_shell>`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:20
msgid "Static Methods"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:23
#: ../../docs/tutorials/platform/html5_shell_classref.rst:45
#: ../../docs/tutorials/platform/html5_shell_classref.rst:47
#: ../../docs/tutorials/platform/html5_shell_classref.rst:49
#: ../../docs/tutorials/platform/html5_shell_classref.rst:51
msgid "Promise"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:23
msgid "`Engine.load <#Engine.load>`__ **(** string basePath **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:25
#: ../../docs/tutorials/platform/html5_shell_classref.rst:29
#: ../../docs/tutorials/platform/html5_shell_classref.rst:53
#: ../../docs/tutorials/platform/html5_shell_classref.rst:55
#: ../../docs/tutorials/platform/html5_shell_classref.rst:57
#: ../../docs/tutorials/platform/html5_shell_classref.rst:59
#: ../../docs/tutorials/platform/html5_shell_classref.rst:61
#: ../../docs/tutorials/platform/html5_shell_classref.rst:63
#: ../../docs/tutorials/platform/html5_shell_classref.rst:65
#: ../../docs/tutorials/platform/html5_shell_classref.rst:67
msgid "void"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:25
msgid "`Engine.unload <#Engine.unload>`__ **(** **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:27
msgid "boolean"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:27
msgid ""
"`Engine.isWebGLAvailable <#Engine.isWebGLAvailable>`__ **(** *[ number "
"majorVersion=1 ]* **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:29
msgid ""
"`Engine.setWebAssemblyFilenameExtension <#Engine."
"setWebAssemblyFilenameExtension>`__ **(** string extension **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:33
msgid "Instance Properties"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:36
msgid "Emscripten ``Module``"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:36
msgid "`engine.rtenv <#engine.rtenv>`__"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:40
msgid "Instance Methods"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:43
msgid "`Engine <#Engine>`__ **(** **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:45
msgid "`engine.init <#engine.init>`__ **(** *[ string basePath ]* **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:47
msgid ""
"`engine.preloadFile <#engine.preloadFile>`__ **(** string\\|ArrayBuffer file "
"*[, string path ]* **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:49
msgid ""
"`engine.start <#engine.start>`__ **(** *[ string arg1, string arg2, … ]* "
"**)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:51
msgid ""
"`engine.startGame <#engine.startGame>`__ **(** string execName, string "
"mainPack **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:53
msgid ""
"`engine.setUnloadAfterInit <#engine.setUnloadAfterInit>`__ **(** boolean "
"enabled **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:55
msgid ""
"`engine.setCanvas <#engine.setCanvas>`__ **(** HTMLCanvasElement canvasElem "
"**)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:57
msgid ""
"`engine.setCanvasResizedOnStart <#engine.setCanvasResizedOnStart>`__ **(** "
"boolean enabled **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:59
msgid "`engine.setLocale <#engine.setLocale>`__ **(** string locale **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:61
msgid ""
"`engine.setExecutableName <#engine.setExecutableName>`__ **(** string "
"execName **)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:63
msgid ""
"`engine.setProgressFunc <#engine.setProgressFunc>`__ **(** function callback "
"**)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:65
msgid ""
"`engine.setStdoutFunc <#engine.setStdoutFunc>`__ **(** function callback "
"**)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:67
msgid ""
"`engine.setStderrFunc <#engine.setStderrFunc>`__ **(** function callback "
"**)**"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:72
msgid "Static Method Descriptions"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:76
msgid "Load the engine from the specified base path."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:0
#: ../../docs/<rst_epilog>:0
#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:59
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:61
#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:24
msgid "Arguments"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:78
#: ../../docs/tutorials/platform/html5_shell_classref.rst:129
msgid "Base path of the engine to load."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:0
msgid "Returns"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:80
msgid "Promise which resolves once the engine is loaded."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:85
msgid "Unload the engine to free memory."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:87
msgid ""
"This method is called automatically once the engine is started unless "
"explicitly disabled using :js:meth:`engine.setUnloadAfterInit`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:92
msgid ""
"Check whether WebGL is available. Optionally, specify a particular version "
"of WebGL to check for."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:94
msgid ""
"The major WebGL version to check for. Defaults to ``1`` for *WebGL 1.0*."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:96
msgid ""
"``true`` if the given major version of WebGL is available, ``false`` "
"otherwise."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:102
msgid ""
"Set an alternative filename extension for the WebAssembly module. By default "
"it is assumed to be ``wasm``."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:105
msgid "Filename extension without preceding dot."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:110
msgid "Instance Property Descriptions"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:114
msgid ""
"The runtime environment provided by Emscripten's ``Module``. For more "
"information refer to the `official documentation <https://emscripten.org/"
"docs/api_reference/module.html>`__ on Emscripten."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:118
msgid "Instance Method Descriptions"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:122
msgid "Create a new instance of the ``Engine`` class."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:126
msgid ""
"Initialize the engine instance. Optionally, pass the base path to the engine "
"to load it, if it hasn't been loaded yet. See :js:meth:`Engine.load`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:132
msgid "Promise that resolves once the engine is loaded and initialized."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:137
msgid ""
"Load a file so it is available in the instance's file system once it runs. "
"Must be called **before** starting the instance."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:140
msgid ""
"If type is ``string``, the file will be loaded from that path.  If type is "
"``ArrayBuffer`` or a view on one, the buffer will used as the content of the "
"file."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:141
msgid "If type is ``string``, the file will be loaded from that path."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:143
msgid ""
"If type is ``ArrayBuffer`` or a view on one, the buffer will used as the "
"content of the file."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:146
msgid ""
"Path by which the file will be accessible. Required, if ``file`` is not a "
"string. If not passed, the path is derived from the URL of the loaded file."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:151
msgid "Promise that resolves once the file is loaded."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:156
msgid ""
"Start the instance of the engine, using the passed strings as command line "
"arguments. :js:meth:`engine.startGame` can be used in typical cases instead."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:160
msgid ""
"This will initialize the instance if it is not initialized. For manual "
"initialization, see :js:meth:`engine.init`. The engine must be loaded "
"beforehand."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:163
msgid "Fails if a canvas cannot be found on the page."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:165
msgid "Command line argument."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:168
msgid "Promise that resolves once the engine started."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:173
msgid ""
"Start the game instance using the given executable URL and main pack URL."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:175
msgid ""
"This will initialize the instance if it is not initialized. For manual "
"initialization, see :js:meth:`engine.init`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:178
msgid ""
"This will load the engine if it is not loaded. The base path of the "
"executable URL will be used as the engine base path."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:181
msgid "Executable name in a form of URL, omitting filename extension."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:184
msgid "URL of the main pack to start the game."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:187
msgid "Promise that resolves once the game started."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:192
msgid ""
"Specify whether the engine will be unloaded automatically after the instance "
"is initialized. Enabled by default."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:195
msgid ""
"``true`` if the engine shall be unloaded after initializing, ``false`` "
"otherwise."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:201
msgid ""
"Specify a canvas HTML element to use. By default, the first canvas element "
"on the page is used for rendering."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:204
msgid "The canvas element to use."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:209
msgid ""
"Specifies whether the canvas will be resized to the width and height "
"specified in the project settings on start. Enabled by default."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:212
msgid "``true`` if the canvas shall be resized on start, ``false`` otherwise."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:217
msgid "Specify a language code to select the proper localization for the game."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:219
msgid "Complete list of :ref:`supported locales <doc_locales>`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:221
msgid "Language code."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:226
msgid ""
"Specify the virtual filename of the executable. By default, the base name of "
"the loaded engine files is used."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:229
msgid ""
"This affects the output of :ref:`OS.get_executable_path() "
"<class_OS_method_get_executable_path>` and sets the automatically started "
"main pack to :file:`{ExecutableName}.pck`."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:232
msgid "Executable name."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:237
msgid ""
"Specify a callback function for displaying download progress. The callback "
"function is called once per frame, so that the usage of "
"``requestAnimationFrame()`` is not necessary."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:240
msgid ""
"If the callback function receives a total amount of bytes as 0, this means "
"that it is impossible to calculate. Possible reasons include:"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:243
msgid "Files are delivered with server-side chunked compression"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:244
msgid "Files are delivered with server-side compression on Chromium"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:245
msgid ""
"Not all file downloads have started yet (usually on servers without multi-"
"threading)"
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:248
msgid ""
"The callback function must accept two numeric arguments: the amount of bytes "
"loaded so far, and the total number of bytes to load."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:254
msgid ""
"Specify a callback function for handling the standard output stream. This "
"method should usually only be used in debug pages. By default, ``console."
"log()`` is used."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:257
#: ../../docs/tutorials/platform/html5_shell_classref.rst:265
msgid ""
"The callback function must accept one string argument: the message to print."
msgstr ""

#: ../../docs/tutorials/platform/html5_shell_classref.rst:262
msgid ""
"Specify a callback function for handling the standard error stream. This "
"method should usually only be used in debug pages. By default, ``console."
"warn()`` is used."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:4
msgid "Custom HTML page for Web export"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:6
msgid ""
"While Web export templates provide a default HTML page fully capable of "
"launching the project without any further customization, it may be "
"beneficial to create a custom HTML page. While the game itself cannot be "
"directly controlled from the outside, such page allows to customize the "
"initialization process for the engine."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:11
msgid "Some use-cases where customizing the default page is useful include:"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:13
msgid "Loading files from a different directory than the page;"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:14
msgid "Loading a ``.zip`` file instead of a ``.pck`` file as the main pack;"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:15
msgid "Loading the engine from a different directory than the main pack file;"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:16
msgid ""
"Adding a click-to-play button so that games can be started in the fullscreen "
"mode;"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:17
msgid ""
"Loading some extra files before the engine starts, making them available in "
"the project file system as soon as possible;"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:19
msgid ""
"Passing custom command line arguments, e.g. ``-s`` to start a ``MainLoop`` "
"script."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:21
msgid ""
"The default HTML page is available in the Godot Engine repository at `/misc/"
"dist/html/full-size.html <https://github.com/godotengine/godot/blob/master/"
"misc/dist/html/full-size.html>`__ and can be used as a reference "
"implementation. Another sample HTML page is available at `/misc/dist/html/"
"fixed-size.html <https://github.com/godotengine/godot/blob/master/misc/dist/"
"html/fixed-size.html>`__. It differs from the default one by having a fixed "
"size canvas area and an output widget below it."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:27
msgid ""
"It is recommended to use developer tools provided by browser vendors to "
"debug exported projects. Output generated by the engine may be limited and "
"does not include WebGL errors."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:33
msgid ""
"As evident by the default HTML page, it is mostly a regular HTML document. "
"To work with Godot projects it needs to be fully realized, to have a control "
"code that calls the :js:class:`Engine` class, and to provide places for "
"several placeholders, which are replaced with their actual values during "
"export."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:40
msgid ""
"``$GODOT_BASENAME``: The base name from the *Export Path*, as set up in the "
"export options; suffixes are omitted (e.g. ``game.html`` becomes ``game``). "
"This variable can be used to generate a path to the main JavaScript file ``"
"$GODOT_BASENAME.js``, which provides the :js:class:`Engine` class. A splash "
"image shown during the booting process can be accessed using this variable "
"as well: ``$GODOT_BASENAME.png``."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:47
msgid ""
"``$GODOT_PROJECT_NAME``: The project name as defined in the Project Settings."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:50
msgid ""
"``$GODOT_HEAD_INCLUDE``: A custom string to include in the HTML document "
"just before the end of the ``<head>`` tag. It is customized in the export "
"options under the *Html / Head Include* section. While you fully control the "
"HTML page you create, this variable can be useful for configuring parts of "
"the HTML ``head`` element from the Godot Editor, e.g. for different Web "
"export presets."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:56
msgid ""
"``$GODOT_DEBUG_ENABLED``: A flag that tells if this is a debug build, or "
"not. This variable is substituted by strings ``true`` and ``false``, and can "
"be used to disable debug branches within your control code."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:60
msgid ""
"When the custom page is ready, it can be selected in the export options "
"under the *Html / Custom Html Shell* section."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:64
#, fuzzy
msgid "Starting the project"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:65
msgid ""
"To be able to start the game, you need to write a script that initializes "
"the engine — the control code. This process consists of three steps, though "
"some of them can be skipped and left for a default behavior."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:69
msgid ""
"First, the engine must be loaded, then it needs to be initialized, and after "
"this the project can finally be started. You can perform every of these "
"steps manually and with great control. However, in the simplest case all you "
"need to do is to create an instance of the :js:class:`Engine` class and then "
"call the :js:meth:`engine.startGame` method."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:82
msgid ""
"This snippet of code automatically loads and initializes the engine before "
"starting the game. It uses the given path to the executable to deduce the "
"path to load the engine. The :js:meth:`engine.startGame` method is "
"asynchronous and returns a ``Promise``. This allows your control code to "
"track if the game was loaded correctly without blocking execution or relying "
"on polling."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:87
msgid ""
"In case your project needs to have special arguments passed to it by the "
"start-up script, :js:meth:`engine.startGame` can be replaced by :js:meth:"
"`engine.start`. This method takes an arbitrary list of string arguments. As "
"it does not have a defined list of arguments, :js:meth:`engine.start` cannot "
"automatically load the engine."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:92
msgid ""
"To load the engine manually the :js:meth:`Engine.load` static method must be "
"called. As this method is static, multiple engine instances can be spawned "
"with the exact same ``basePath``. If an instance requires a different "
"``basePath``, you can call the :js:meth:`engine.init` method with that path "
"before starting the game."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:97
msgid ""
"Multiple instances cannot be spawned by default, as the engine is "
"immediately unloaded after it is initialized. To prevent this from happening "
"the :js:meth:`engine.setUnloadAfterInit` method can be called. It is still "
"possible to unload the engine manually afterwards by calling the :js:meth:"
"`Engine.unload` static method. Unloading the engine frees browser memory by "
"unloading files that are no longer needed once the instance is initialized."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:102
msgid ""
"To correctly load the engine on some hosting providers and network "
"configurations you may need to change the default filename extension by "
"using :js:meth:`Engine.setWebAssemblyFilenameExtension`. By default, the "
"extension is assumed to be ``wasm``. If your hosting provider blocks this "
"extension, this static method can be used to change it to something that is "
"supported."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:113
msgid ""
"If a different filename extension is used, some web servers may "
"automatically set the MIME-type of the file to something other than :"
"mimetype:`application/wasm`. In that case some start-up optimizations may be "
"skipped."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:118
msgid "Customizing the behavior"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:119
msgid ""
"In the Web environment several methods can be used to guarantee that the "
"game will work as intended."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:121
msgid ""
"If you target a specific version of WebGL, or just want to check if WebGL is "
"available at all, you can call the :js:meth:`Engine.isWebGLAvailable` "
"method. It optionally takes an argument that allows to test for a specific "
"major version of WebGL."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:125
msgid ""
"As the real executable file does not exist in the Web environment, the "
"engine only stores a virtual filename formed from the base name of loaded "
"engine files. This value affects the output of the :ref:`OS."
"get_executable_path() <class_OS_method_get_executable_path>` method and "
"defines the name of the automatically started main pack. The :js:meth:"
"`engine.setExecutableName` method can be used to override this value."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:131
msgid ""
"If your project requires some files to be available the moment it is loaded, "
"you can preload them by calling the :js:meth:`engine.preloadFile` method "
"with a path to a file or by providing it with an ``ArrayBuffer`` object. In "
"case of the ``ArrayBuffer``, or one of its views, a second argument must be "
"specified to define an internal path for the loaded resource."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:137
msgid "Customizing the presentation"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:138
msgid ""
"Several methods can be used to further customize the look and behavior of "
"the game on your page."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:140
msgid ""
"By default, the first canvas element on the page is used for rendering. To "
"use a different canvas element the :js:meth:`engine.setCanvas` method can be "
"used. It requires a reference to the DOM element itself."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:149
msgid ""
"If the width and height of this canvas element differ from values set in the "
"project settings, it will be resized on the project start. This behavior can "
"be disabled by calling the :js:meth:`engine.setCanvasResizedOnStart` method."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:153
msgid ""
"If your game takes some time to load, it may be useful to display a custom "
"loading UI which tracks the progress. This can be achieved with the :js:meth:"
"`engine.setProgressFunc` method which allows to set up a callback function "
"to be called regularly as the engine loads new bytes."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:164
msgid ""
"Be aware that in some cases ``total`` can be ``0``. This means that it "
"cannot be calculated."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:166
msgid ""
"If your game supports multiple languages, the :js:meth:`engine.setLocale` "
"method can be used to set a specific locale, provided you have a valid "
"language code string. It may be good to use server-side logic to determine "
"which languages a user may prefer. This way the language code can be taken "
"from the ``Accept-Language`` HTTP header, or determined by a GeoIP service."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:173
msgid ""
"To debug exported projects, it may be useful to read the standard output and "
"error streams generated by the engine. This is similar to the output shown "
"in the editor console window. By default, standard ``console.log`` and "
"``console.warn`` are used for the output and error streams respectively. "
"This behavior can be customized by setting your own functions to handle "
"messages."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:178
msgid ""
"Use the :js:meth:`engine.setStdoutFunc` method to set a callback function "
"for the output stream. Default behavior is similar to this:"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:188
msgid ""
"Use the :js:meth:`engine.setStderrFunc` method to set a callback function "
"for the error stream. Default behavior is similar to this:"
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:198
msgid ""
"When handling the engine output keep in mind, that it may not be desirable "
"to print it out in the finished product. To control whether or not the "
"current execution is actually a debug build you can use ``"
"$GODOT_DEBUG_ENABLED`` placeholder."
msgstr ""

#: ../../docs/tutorials/platform/customizing_html5_shell.rst:202
msgid ""
"Further debugging options and a low level access to the execution "
"environment are available in a form of Emscripten's ``Module`` object. It "
"can be accessed using the :js:attr:`engine.rtenv` property on the engine "
"instance."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:4
#, fuzzy
msgid "Console support in Godot"
msgstr "אילו שפות נתמכות ב־Godot?"

#: ../../docs/tutorials/platform/consoles.rst:7
msgid "Console publishing process"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:9
msgid ""
"Regardless of the engine used to create the game, the process to publish a "
"game to a console platform is as follows:"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:12
msgid ""
"Register a developer account on the console manufacturer's website, then "
"sign NDAs and publishing contracts. This requires you to have a registered "
"legal entity."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:15
msgid ""
"Gain access to the publishing platform by passing the acceptance process. "
"This can take up to several months. Note that this step is significantly "
"easier if an established publisher is backing your game. Nintendo is "
"generally known to be more accepting of smaller developers, but this is not "
"guaranteed."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:19
msgid ""
"Get access to developer tools and order a console specially made for "
"developers (*devkit*). The cost of those devkits is confidential."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:21
msgid "Port the engine to the console platform or pay a company to do it."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:22
msgid ""
"To be published, your game needs to be rated in the regions you'd like to "
"sell it in. For example, in North America, the `ESRB <https://www.esrb.org/"
">`__ handles game ratings. In Europe, this is done by `PEGI <https://pegi."
"info/>`__. Indie developers can generally get a rating for cheaper compared "
"to more established developers."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:28
msgid ""
"Due to the complexity of the process, the budget to publish a game by "
"yourself on a single console often exceeds $1,000 (this is a rough figure)."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:32
msgid "Official support"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:34
msgid ""
"Godot currently does not officially support consoles. The reasons for this "
"are:"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:36
msgid ""
"To develop for consoles, one must be licensed as a company. As an open "
"source project, Godot does not have such a legal figure."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:38
msgid ""
"Console SDKs are secret and covered by non-disclosure agreements. Even if we "
"could get access to them, we could not publish the platform-specific code "
"under an open source license."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:41
msgid ""
"Consoles require specialized hardware to develop for, so regular individuals "
"can't create games for them anyway."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:44
msgid ""
"However, it is still possible to port your games to consoles thanks to "
"services provided by third-party companies."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:49
msgid ""
"In practice, the process is quite similar to Unity and Unreal Engine, except "
"that you need to contact a third-party developer to handle the porting "
"process. In other words, there is no engine that is legally allowed to "
"distribute console export templates without requiring the user to prove that "
"they are a licensed console developer. Doing so would violate the console "
"manufacturer's NDA."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:57
msgid "Third-party support"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:59
msgid ""
"Console ports of Godot are offered by third-party companies (which have "
"ported Godot on their own). These companies also offer publishing of your "
"games to various consoles."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:63
msgid "Following is the list of providers:"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:65
msgid ""
"`Lone Wolf Technology <http://www.lonewolftechnology.com/>`_ offers Switch, "
"PS4 and Xbox One porting and publishing of Godot games."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:67
msgid ""
"`Pineapple Works <https://pineapple.works/>`_ offers Switch and Xbox One "
"porting and publishing of Godot games."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:70
msgid ""
"If your company offers porting and/or publishing services for Godot games, "
"feel free to `open an issue or pull request <https://github.com/godotengine/"
"godot-docs>`_ to add your company to the list above."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:9
msgid ""
"Threads allow simultaneous execution of code. It allows off-loading work "
"from the main thread."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:12
msgid "Godot supports threads and provides many handy functions to use them."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:14
msgid ""
"If using other languages (C#, C++), it may be easier to use the threading "
"classes they support."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:18
#, fuzzy
msgid "Creating a Thread"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/threads/using_multiple_threads.rst:20
msgid "Creating a thread is very simple, just use the following code:"
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:45
msgid ""
"Your function will, then, run in a separate thread until it returns. Even if "
"the function has returned already, the thread must collect it, so call :ref:"
"`Thread.wait_to_finish()<class_Thread_method_wait_to_finish>`, which will "
"wait until the thread is done (if not done yet), then properly dispose of it."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:51
msgid "Mutexes"
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:53
msgid ""
"Accessing objects or data from multiple threads is not always supported (if "
"you do it, it will cause unexpected behaviors or crashes). Read the :ref:"
"`doc_thread_safe_apis` documentation to understand which engine APIs support "
"multiple thread access."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:58
msgid ""
"When processing your own data or calling your own functions, as a rule, try "
"to avoid accessing the same data directly from different threads. You may "
"run into synchronization problems, as the data is not always updated between "
"CPU cores when modified. Always use a :ref:`Mutex<class_Mutex>` when "
"accessing a piece of data from different threads."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:64
msgid ""
"When calling :ref:`Mutex.lock()<class_Mutex_method_lock>`, a thread ensures "
"that all other threads will be blocked (put on suspended state) if they try "
"to *lock* the same mutex. When the mutex is unlocked by calling :ref:`Mutex."
"unlock()<class_Mutex_method_unlock>`, the other threads will be allowed to "
"proceed with the lock (but only one at a time)."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:70
msgid "Here is an example of using a Mutex:"
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:102
msgid "Semaphores"
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:104
msgid ""
"Sometimes you want your thread to work *\"on demand\"*. In other words, tell "
"it when to work and let it suspend when it isn't doing anything. For this, :"
"ref:`Semaphores<class_Semaphore>` are used. The function :ref:`Semaphore."
"wait()<class_Semaphore_method_wait>` is used in the thread to suspend it "
"until some data arrives."
msgstr ""

#: ../../docs/tutorials/threads/using_multiple_threads.rst:110
msgid ""
"The main thread, instead, uses :ref:`Semaphore."
"post()<class_Semaphore_method_post>` to signal that data is ready to be "
"processed:"
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:4
msgid "Thread-safe APIs"
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:9
msgid ""
"Threads are used to balance processing power across CPUs and cores. Godot "
"supports multithreading, but not in the whole engine."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:12
msgid ""
"Below is a list of ways multithreading can be used in different areas of "
"Godot."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:17
msgid ""
":ref:`Global Scope<class_@GlobalScope>` singletons are all thread-safe. "
"Accessing servers from threads is supported (for VisualServer and Physics "
"servers, ensure threaded or thread-safe operation is enabled in the project "
"settings!)."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:19
msgid ""
"This makes them ideal for code that creates dozens of thousands of instances "
"in servers and controls them from threads. Of course, it requires a bit more "
"code, as this is used directly and not within the scene tree."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:24
msgid ""
"Interacting with the active scene tree is **NOT** thread-safe. Make sure to "
"use mutexes when sending data between threads. If you want to call functions "
"from a thread, the *call_deferred* function may be used:"
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:33
msgid ""
"However, creating scene chunks (nodes in tree arrangement) outside the "
"active tree is fine. This way, parts of a scene can be built or instantiated "
"in a thread, then added in the main thread:"
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:42
msgid ""
"Still, this is only really useful if you have **one** thread loading data. "
"Attempting to load or create scene chunks from multiple threads may work, "
"but you risk resources (which are only loaded once in Godot) tweaked by the "
"multiple threads, resulting in unexpected behaviors or crashes."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:47
msgid ""
"Only use more than one thread to generate scene data if you *really* know "
"what you are doing and you are sure that a single resource is not being used "
"or set in multiple ones. Otherwise, you are safer just using the servers API "
"(which is fully thread-safe) directly and not touching scene or resources."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:53
msgid "GDScript arrays, dictionaries"
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:55
msgid ""
"In GDScript, reading and writing elements from multiple threads is ok, but "
"anything that changes the container size (resizing, adding or removing "
"elements) requires locking a mutex."
msgstr ""

#: ../../docs/tutorials/threads/thread_safe_apis.rst:60
msgid ""
"Modifying a unique resource from multiple threads is not supported. However "
"handling references on multiple threads is supported, hence loading "
"resources on a thread is as well - scenes, textures, meshes, etc - can be "
"loaded and manipulated on a thread and then added to the active scene on the "
"main thread. The limitation here is as described above, one must be careful "
"not to load the same resource from multiple threads at once, therefore it is "
"easiest to use **one** thread for loading and modifying resources, and then "
"the main thread for adding them."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:2
msgid "Procedural geometry"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:4
msgid ""
"There are many ways to procedurally generate geometry in Godot. In this "
"tutorial series we will explore a few of them. Each technique has its own "
"benefits and drawbacks, so it is best to understand each one and how it can "
"be useful in a given situation."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:18
msgid "What is geometry?"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:20
msgid ""
"Geometry is a fancy way of saying shape. In computer graphics, geometry is "
"typically represented by an array of positions called \"vertices\". In "
"Godot, geometry is represented by Meshes."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:24
msgid "What is a Mesh?"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:26
msgid ""
"Many things in Godot have mesh in their name: the :ref:`Mesh <class_Mesh>`, "
"the :ref:`ArrayMesh <class_ArrayMesh>`, the :ref:`MeshInstance "
"<class_MeshInstance>`, the :ref:`MultiMesh <class_MultiMesh>`, and the :ref:"
"`MultiMeshInstance <class_MultiMeshInstance>`. While they are all related, "
"they have slightly different uses."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:30
msgid ""
"Meshes and ArrayMeshes are resources that are drawn using a MeshInstance "
"node. Resources like Meshes and ArrayMeshes cannot be added to the scene "
"directly. A MeshInstance represents one instance of a mesh in your scene. "
"You can reuse a single mesh in multiple MeshInstances to draw it in "
"different parts of your scene with different materials or transformations "
"(scale, rotation, position etc.)."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:36
msgid ""
"If you are going to draw the same object many times, it can be helpful to "
"use a MultiMesh with a MultiMeshInstance. The MultiMeshInstance draws meshes "
"thousands of times very cheaply. It takes advantage of hardware instancing "
"in order to do so. The drawback with using a MultiMeshInstance is that you "
"are limited to one material for all instances. It uses an instance array to "
"store different colors and transformations for each instance, but all the "
"instances use the same material."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:44
msgid "What a Mesh is"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:46
msgid ""
"A Mesh is composed of one or more surfaces. A surface is an array composed "
"of multiple sub-arrays containing vertices, normals, UVs, etc. Normally the "
"process of constructing surfaces and meshes is hidden from the user in the :"
"ref:`VisualServer <class_VisualServer>`, but with ArrayMeshes, the user can "
"construct a Mesh manually by passing in an array containing the surface "
"information."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:52
msgid "Surfaces"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:54
msgid ""
"Each surface has its own material. Alternatively, you can override the "
"material for all surfaces in the Mesh when you use a MeshInstance using "
"``MeshInstance.override_material``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:58
msgid "Surface array"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:60
msgid ""
"The surface array is an array of length ``ArrayMesh.ARRAY_MAX``. Each "
"position in the array is filled with a sub-array containing per-vertex "
"information. For example, the array located at ``ArrayMesh.ARRAY_NORMAL`` is "
"a :ref:`PoolVector3Array <class_PoolVector3Array>` of vertex normals."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:64
msgid ""
"The surface array can be indexed or non-indexed. Creating a non-indexed "
"array is as easy as not assigning an array at the index ``ArrayMesh."
"ARRAY_INDEX``. A non-indexed array stores unique vertex information for "
"every triangle, meaning that when two triangle share a vertex, the vertex is "
"duplicated in the array. An indexed surface array only stores vertex "
"information for each unique vertex and then also stores an array of indices "
"which maps out how to construct the triangles from the vertex array. In "
"general, using an indexed array is faster, but it means you have to share "
"vertex data between triangles, which is not always desired (e.g. when you "
"want per-face normals)."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:75
msgid ""
"Godot provides different ways of accessing and working with geometry. More "
"information on each will be provided in the following tutorials."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:79
#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:48
#: ../../docs/development/file_formats/tscn.rst:321
msgid "ArrayMesh"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:81
msgid ""
"The ArrayMesh resource extends Mesh to add a few different quality of life "
"functions, and most importantly, the ability to construct a Mesh surface "
"through scripting."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:84
msgid ""
"For more information about the ArrayMesh, please see the :ref:`ArrayMesh "
"tutorial <doc_arraymesh>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:87
msgid "MeshDataTool"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:89
msgid ""
"The MeshDataTool is a resource that converts Mesh data into arrays of "
"vertices, faces, and edges that can be modified at runtime."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:92
msgid ""
"For more information about the MeshDataTool, please see the :ref:"
"`MeshDataTool tutorial <doc_meshdatatool>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:95
msgid "SurfaceTool"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:97
msgid ""
"The SurfaceTool allows the creation of Meshes using an OpenGL 1.x immediate "
"mode style interface."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:99
msgid ""
"For more information about the SurfaceTool, please see the :ref:`SurfaceTool "
"tutorial <doc_surfacetool>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:102
msgid "ImmediateGeometry"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:104
msgid ""
"ImmediateGeometry is a node that uses an immediate mode style interface "
"(like SurfaceTool) to draw objects. The difference between ImmediateGeometry "
"and the SurfaceTool is that ImmediateGeometry is a node itself that can be "
"added to the scene tree and is drawn directly from the code. The SurfaceTool "
"generates a Mesh that needs to be added a MeshInstance to be seen."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:109
msgid ""
"ImmediateGeometry is useful for prototyping because of the straightforward "
"API, but it is slow because the geometry is rebuilt every frame. It is most "
"useful for quickly adding simple geometry to debug visually (e.g. by drawing "
"lines to visualize physics raycasts etc.)."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:113
msgid ""
"For more information about ImmediateGeometry, please see the :ref:"
"`ImmediateGeometry tutorial <doc_immediategeometry>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:116
#, fuzzy
msgid "Which one should I use?"
msgstr "מה הוא GDScript ומדוע עלי להשתמש בו?"

#: ../../docs/tutorials/content/procedural_geometry/index.rst:118
msgid ""
"Which method you use depends on what you are trying to do and what kind of "
"procedure you are comfortable with."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:120
msgid ""
"Both SurfaceTool and ArrayMesh are excellent for generating static geometry "
"(meshes) that don't change over time."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:122
msgid ""
"Using an ArrayMesh is slightly faster than using a SurfaceTool, but the API "
"is more a little more challenging. Additionally, SurfaceTool has a few "
"quality of life methods such as ``generate_normals()`` and ``index()``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:125
msgid ""
"ImmediateGeometry regenerates the mesh every frame, so it is much slower "
"than ArrayMesh or SurfaceTool. However, if you need the geometry to change "
"every frame anyway it provides a much easier interface that may even be a "
"little faster than generating an ArrayMesh every frame."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/index.rst:129
msgid ""
"The MeshDataTool is not fast, but it gives you access to all kinds of "
"properties of the mesh that you don't get with the others (edges, faces, "
"etc.). It is incredibly useful when you need that sort of data to transform "
"the mesh, but it is not a good idea to use if that information is not "
"needed. The MeshDataTool is best used if you are going to be using an "
"algorithm that requires access to the face or edge array."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:4
msgid "Using the ArrayMesh"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:6
msgid ""
"This tutorial will present the basics of using an :ref:`ArrayMesh "
"<class_arraymesh>`"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:8
msgid ""
"To do so, we will use the function :ref:`add_surface_from_arrays() "
"<class_ArrayMesh_method_add_surface_from_arrays>`, which takes up to four "
"parameters. The first two are required, while the second two are optional."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:11
msgid ""
"The first is the ``PrimitiveType``, this is an OpenGL concept that instructs "
"the GPU how to arrange the primitive based on the vertices given whether it "
"is triangles, lines, points, etc. A complete list can be found under the :"
"ref:`Mesh <class_mesh>` class reference page."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:16
msgid ""
"The second is the actual Array that stores the mesh information. The array "
"is a normal Godot array that is constructed with empty brackets ``[]``. It "
"stores a ``Pool**Array`` (e.g. PoolVector3Array, PoolIntArray, etc.) for "
"each type of information."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:20
msgid "``ARRAY_VERTEX`` = 0 | PoolVector3Array or PoolVector2Array"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:21
msgid "``ARRAY_NORMAL`` = 1 | PoolVector3Array"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:22
msgid ""
"``ARRAY_TANGENT`` = 2 | PoolRealArray of groups of 4 floats. first 3 floats "
"determine the tangent, and the last the binormal direction as -1 or 1."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:24
msgid "``ARRAY_COLOR`` = 3 | PoolColorArray"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:25
msgid "``ARRAY_TEX_UV`` = 4 | PoolVector2Array or PoolVector3Array"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:26
msgid "``ARRAY_TEX_UV2`` = 5 | PoolVector2Array or PoolVector3Array"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:27
msgid ""
"``ARRAY_BONES`` = 6 | PoolRealArray of groups of 4 floats or PoolIntArray of "
"groups of 4 ints"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:28
msgid "``ARRAY_WEIGHTS`` = 7 | PoolRealArray of groups of 4 floats"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:29
msgid "``ARRAY_INDEX`` = 8 | PoolIntArray"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:31
msgid ""
"The Array of vertices is always required. All the others are optional and "
"will only be used if included."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:33
msgid ""
"Each array needs to have the same number of elements as the vertex array "
"except for the index array. For arrays like tangents, an element is a group "
"of 4 floats. So the array size will be four times the size of the vertex "
"array size, but they will have the same number of elements"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:37
msgid "The index array is unique."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:39
msgid ""
"The third parameter is an array of blendshapes for the Mesh to use. While "
"this tutorial does not cover using blendshapes, it is possible to specify "
"them when creating a surface from arrays."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:42
msgid ""
"The last parameter is the compress flags which specifies which arrays to "
"store with half as many bits. The values can be found in the classref for :"
"ref:`VisualServer <class_visualserver>` under :ref:`ArrayFormat "
"<enum_visualserver_arrayformat>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:45
msgid ""
"For normal usage you will find it is best to leave the last two parameters "
"empty."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:50
msgid ""
"Add an :ref:`ArrayMesh <class_arraymesh>` to a MeshInstance. Normally, "
"adding an ArrayMesh in the editor is not useful, but in this case it allows "
"as to access the ArrayMesh from code without creating one."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:54
msgid "Next, add a script to the MeshInstance."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:56
msgid "Under ``_ready()``, create a new Array."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:63
msgid ""
"This will be the array that we keep our surface information in, it will hold "
"all the arrays of data that the surface needs. Godot will expect it to be of "
"size ``Mesh.ARRAY_MAX``, so resize it accordingly."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:73
msgid "Next create the arrays for each data type you will use."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:83
msgid ""
"Once you have filled your data arrays with your geometry you can create a "
"mesh by adding each array to ``surface_array`` and then committing to the "
"mesh."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:96
msgid ""
"In this example, we used ``Mesh.PRIMITIVE_TRIANGLES``, but you can use any "
"primitive type available from mesh."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:99
msgid "Put together the full code looks like:"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:130
msgid ""
"The code that goes in the middle can be whatever you want. Below we will "
"present some example code that could go in the middle."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:134
#, fuzzy
msgid "Generating geometry"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:136
msgid ""
"Here is sample code for generating a sphere. Although the code is presented "
"in GDScript, there is nothing Godot specific about the approach to "
"generating it. This implementation has nothing in particular to do with "
"ArrayMeshes and is just a generic approach to generating a sphere. If you "
"are having trouble understanding it or want to learn more about procedural "
"geometry in general, you can use any tutorial that you find online."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:203
msgid "Combined with the code above, this code will generate a sphere."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:205
msgid ""
"When it comes to generating geometry with the ArrayMesh you need to "
"understand what goes in each array and then you can follow tutorials for any "
"language/engine and convert it into Godot."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:209
msgid "Saving"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/arraymesh.rst:211
msgid ""
"Finally, Godot provides a single method to save ArrayMeshes using the :ref:"
"`ResourceSaver <class_resourcesaver>` class. This is useful when you want to "
"generate a mesh and then use it later without having to re-generate."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:4
msgid "Using the MeshDataTool"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:6
msgid ""
"The MeshDataTool is not used to generate geometry. But it is helpful for "
"dynamically altering geometry, for example if you want to write a script to "
"tessellate, simplify, or deform meshes."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:9
msgid ""
"The MeshDataTool is not as fast as altering arrays directly using ArrayMesh. "
"However, it provides more information and tools to work with meshes than the "
"ArrayMesh does. When the MeshDataTool is used, it calculates mesh data that "
"is not available in ArrayMeshes such as faces and edges, which are necessary "
"for certain mesh algorithms. If you do not need this extra information then "
"it may be better to use an ArrayMesh."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:14
msgid ""
"MeshDataTool can only be used on Meshes that use the PrimitiveType ``Mesh."
"PRIMITIVE_TRIANGLES``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:16
msgid ""
"As an example, let's walk through the process of deforming the mesh "
"generated in the :ref:`ArrayMesh tutorial <doc_arraymesh>`."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:18
msgid ""
"Assume the mesh is stored in an ArrayMesh named ``mesh``. We then initialize "
"the MeshDataTool from ``mesh`` by calling ``create_from_surface()``. If "
"there is already data initialized in the MeshDataTool calling "
"``create_from_surface()`` will clear it for you. Alternatively, you can call "
"``clear()`` yourself before re-using the MeshDataTool"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:29
msgid ""
"``create_from_surface()`` uses the vertex arrays from the ArrayMesh to "
"calculate two additional arrays, one for edges and one for faces."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:32
msgid ""
"An edge is a connection between any two vertices. Each edge in the edge "
"array contains a reference to the two vertices it is composed of, and up to "
"two faces that it is contained within."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:35
msgid ""
"A face is a triangle made up of three vertices and three corresponding "
"edges. Each face in the face array contains a reference to the three "
"triangles and three edges it is composed of."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:38
msgid ""
"The vertex array contains edges, faces, normals, color, tangent, uv, uv2, "
"bones, and weight information connected with each vertex."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:41
msgid ""
"To access information from these arrays you use a function of the form "
"``get_****()``:"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:51
msgid ""
"What you choose to do with these functions is up to you. A common use case "
"is to iterate over all vertices and transform them in some way:"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:62
msgid ""
"Finally, ``commit_to_surface()`` adds a new surface to the ArrayMesh. So if "
"you are dynamically updating an existing ArrayMesh, first delete the "
"existing surface before adding a new one."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/meshdatatool.rst:71
msgid ""
"Below is a complete example that creates a pulsing blob complete with new "
"normals and vertex colors."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:4
#, fuzzy
msgid "Using the SurfaceTool"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:6
msgid ""
"The :ref:`SurfaceTool <doc_surfacetool>` provides a useful interface for "
"constructing geometry. The interface is similar to the :ref:"
"`ImmediateGeometry <class_immediategeometry>` node. You set each per-vertex "
"attribute (e.g. normal, uv, color) and then when you add a vertex it "
"captures the attributes."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:11
msgid ""
"The SurfaceTool also provides some useful helper functions like ``index()`` "
"and ``generate_normals()``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:13
msgid "Attributes are added before each vertex is added:"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:24
msgid ""
"When finished generating your geometry with the :ref:`SurfaceTool "
"<class_surfacetool>` call ``commit()`` to finished generating the mesh. If "
"an :ref:`ArrayMesh <class_ArrayMesh>` is passed to ``commit()`` then it "
"appends a new surface to the end of the ArrayMesh. While if nothing is "
"passed in, ``commit()`` returns an ArrayMesh."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:36
msgid "Code creates a triangle with indices"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:62
msgid ""
"You can optionally add an index array, either by calling ``add_index()`` and "
"adding vertices to the index array or by calling ``index()`` which shrinks "
"the vertex array to remove duplicate vertices."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:82
msgid ""
"Similarly, if you have an index array, but you want each vertex to be unique "
"(e.g. because you want to use unique normals or colors per face instead of "
"per-vertex), you can call ``deindex()``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:90
msgid ""
"If you don't add custom normals yourself, you can add them using "
"``generate_normals()``. The same goes for tangents."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/surfacetool.rst:98
msgid ""
"By default, when generating normals, they will be calculated on a per-face "
"basis. If you want smooth vertex normals, when adding vertices, call "
"``add_smooth_group()``. ``add_smooth_group()`` needs to be called while "
"building the geometry, e.g. before the call to ``add_vertex()`` (if non-"
"indexed) or ``add_index()`` (if indexed)."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:4
msgid "Using ImmediateGeometry"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:6
msgid ""
"Unlike the SurfaceTool or ArrayMesh, :ref:`ImmediateGeometry "
"<class_ImmediateGeometry>` is an actual node. Being a node makes it quick to "
"add to a scene and get visual output. It uses an OpenGL 1.x-style API like "
"SurfaceTool, but it's actually designed to create meshes on the fly."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:10
msgid ""
"Generating complex geometry (several thousand vertices) with this node is "
"inefficient, even if it's done only once. Instead, it is designed to "
"generate simple geometry that changes every frame."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:13
msgid ""
"Before starting, you should clear the geometry by calling ``clear()``. This "
"ensures that you are not building upon the geometry from the previous frame. "
"If you want to keep geometry between frames, do not call ``clear()``."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:17
msgid ""
"To begin generating geometry you must call ``begin()``. ``begin()`` takes a "
"``PrimitiveType`` as an argument. ``PrimitiveType`` is an OpenGL concept "
"that instructs the GPU how to arrange the primitive based on the vertices "
"given whether it is triangles, lines, points, etc. A complete list can be "
"found under the :ref:`Mesh <class_mesh>` class reference page."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:22
msgid ""
"Once you have called ``begin()`` you are ready to start adding vertices. You "
"add vertices one at a time. First you add vertex specific attributes such as "
"normals or UVs using ``set_****()`` (e.g. ``set_normal()``). Then you call "
"``add_vertex()`` to add a vertex with those attributes. For example:"
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:34
msgid ""
"Only attributes added before the call to ``add_vertex()`` will be included "
"in that vertex."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:36
msgid ""
"Finally, once you have added all your vertices call ``end()`` to signal that "
"you have finished generating the mesh."
msgstr ""

#: ../../docs/tutorials/content/procedural_geometry/immediategeometry.rst:38
msgid "The example code below draws a single triangle."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:4
msgid "Making trees"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:6
msgid ""
"This is a short tutorial on how to make trees and other types of vegetation "
"from scratch."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:8
msgid ""
"The aim is to not focus on the modelling techniques (there are plenty of "
"tutorials about that), but how to make them look good in Godot."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:13
msgid "Start with a tree"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:15
msgid "I took this tree from SketchFab:"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:19
msgid "https://sketchfab.com/models/ea5e6ed7f9d6445ba69589d503e8cebf"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:21
msgid "and opened it in Blender."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:24
msgid "Paint with vertex colors"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:26
msgid ""
"The first thing you may want to do is to use the vertex colors to paint how "
"much the tree will sway when there is wind. Just use the vertex color "
"painting tool of your favorite 3D modelling program and paint something like "
"this:"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:30
msgid ""
"This is a bit exaggerated, but the idea is that color indicates how much "
"sway affects every part of the tree. This scale here represents it better:"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:35
msgid "Write a custom shader for the leaves"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:37
msgid "This is a simple example of a shader for leaves:"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:44
msgid ""
"This is a spatial shader. There is no front/back culling (so leaves can be "
"seen from both sides), and alpha prepass is used, so there are less depth "
"artifacts that result from using transparency (and leaves cast shadow). "
"Finally, for the sway effect, world coordinates are recommended, so the tree "
"can be duplicated, moved, etc. and it will still work together with other "
"trees."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:51
msgid ""
"Here, the texture is read, as well as a transmission color, which is used to "
"add some back-lighting to the leaves, simulating subsurface scattering."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:67
msgid ""
"This is the code to create the sway of the leaves. It's basic (just uses a "
"sinewave multiplying by the time and axis position, but works well). Notice "
"that the strength is multiplied by the color. Every axis uses a different "
"small near 1.0 multiplication factor so axes don't appear in sync."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:70
msgid "Finally, all that's left is the fragment shader:"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:83
msgid "And this is pretty much it."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:85
msgid ""
"The trunk shader is similar, except it does not write to the alpha channel "
"(thus no alpha prepass is needed) and does not require transmission to work. "
"Both shaders can be improved by adding normal mapping, AO and other maps."
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:88
msgid "Improving the shader"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:90
msgid ""
"There are many more resources on how to do this that you can read. Now that "
"you know the basics, a recommended read is the chapter from GPU Gems3 about "
"how Crysis does this (focus mostly on the sway code, as many other "
"techniques shown there are obsolete):"
msgstr ""

#: ../../docs/tutorials/content/making_trees.rst:93
msgid "https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch16.html"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:4
msgid "Optimization using Servers"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:6
msgid ""
"Engines like Godot provide increased ease of use thanks to their high level "
"constructs and features. Most of them are accessed and used via the :ref:"
"`Scene System<doc_scene_tree>`. Using nodes and resources simplifies project "
"organization and asset management in complex games."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:10
msgid "There are, of course, always drawbacks:"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:12
msgid "There is an extra layer of complexity"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:13
msgid "Performance is lower than using simple APIs directly"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:14
msgid "It is not possible to use multiple threads to control them"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:15
msgid "More memory is needed."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:17
msgid ""
"In many cases, this is not really a problem (Godot is very optimized, and "
"most operations are handled with signals, so no polling is required). Still, "
"sometimes it can be. For example, dealing with tens of thousands of "
"instances for something that needs to be processed every frame can be a "
"bottleneck."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:21
msgid ""
"This type of situation makes programmers regret they are using a game engine "
"and wish they could go back to a more handcrafted, low level implementation "
"of game code."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:24
msgid "Still, Godot is designed to work around this problem."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:27
msgid "Servers"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:29
msgid ""
"One of the most interesting design decisions for Godot, is the fact that the "
"whole scene system is *optional*. While it is not currently possible to "
"compile it out, it can be completely bypassed."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:32
msgid ""
"At the core, Godot uses the concept of Servers. They are very low level APIs "
"to control rendering, physics, sound, etc. The scene system is built on top "
"of them and uses them directly. The most common servers are:"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:36
msgid ""
":ref:`VisualServer <class_VisualServer>`: handles everything related to "
"graphics."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:37
msgid ""
":ref:`PhysicsServer <class_PhysicsServer>`: handles everything related to 3D "
"physics."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:38
msgid ""
":ref:`Physics2DServer <class_Physics2DServer>`: handles everything related "
"to 2D physics."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:39
msgid ""
":ref:`AudioServer <class_AudioServer>`: handles everything related to audio."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:41
msgid ""
"Just explore their APIs and you will realize that the all functions provided "
"are low-level implementations of everything Godot allows you to do."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:45
msgid "RIDs"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:47
msgid ""
"The key to using servers is understanding Resource ID (:ref:`RID "
"<class_RID>`) objects. These are opaque handles to the server "
"implementation. They are allocated and freed manually. Almost every function "
"in the servers requires RIDs to access the actual resource."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:51
msgid ""
"Most Godot nodes and resources contain these RIDs from the servers "
"internally, and they can be obtained with different functions. In fact, "
"anything that inherits :ref:`Resource <class_Resource>` can be directly "
"casted to an RID (not all resources contain an RID, though, in such cases "
"the RID will be empty). In fact, resources can be passed to server APIs as "
"RIDs. Just make sure to keep references to the resources outside the server, "
"because if the resource is erased, the internal RID is erased too."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:58
msgid "For nodes, there are many functions available:"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:60
msgid ""
"For CanvasItem, the :ref:`CanvasItem.get_canvas_item() "
"<class_CanvasItem_method_get_canvas_item>` method will return the canvas "
"item RID in the server."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:62
msgid ""
"For CanvasLayer, the :ref:`CanvasLayer.get_canvas() "
"<class_CanvasLayer_method_get_canvas>` method will return the canvas RID in "
"the server."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:64
msgid ""
"For Viewport, the :ref:`Viewport.get_viewport_rid() "
"<class_Viewport_method_get_viewport_rid>` method will return the viewport "
"RID in the server."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:66
msgid ""
"For 3D, the :ref:`World <class_World>` resource (obtainable in the :ref:"
"`Viewport <class_Viewport>` and :ref:`Spatial <class_Spatial>` nodes) "
"contains functions to get the *VisualServer Scenario*, and the "
"*PhysicsServer Space*. This allows creating 3D objects directly with the "
"server API and using them."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:70
msgid ""
"For 2D, the :ref:`World2D <class_World2D>` resource (obtainable in the :ref:"
"`Viewport <class_Viewport>` and :ref:`CanvasItem <class_CanvasItem>` nodes) "
"contains functions to get the *VisualServer Canvas*, and the "
"*Physics2DServer Space*. This allows creating 2D objects directly with the "
"server API and using them."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:74
msgid ""
"The :ref:`VisualInstance<class_VisualInstance>` class, allows getting the "
"scenario *instance* and *instance base* via the :ref:`VisualInstance."
"get_instance() <class_VisualInstance_method_get_instance>` and :ref:"
"`VisualInstance.get_base() <class_VisualInstance_method_get_base>` "
"respectively."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:78
msgid ""
"Just explore the nodes and resources you are familiar with and find the "
"functions to obtain the server *RIDs*."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:80
msgid ""
"It is not advised to control RIDs from objects that already have a node "
"associated. Instead, server functions should always be used for creating and "
"controlling new ones and interacting with the existing ones."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:84
#, fuzzy
msgid "Creating a sprite"
msgstr "יצירת תוכן"

#: ../../docs/tutorials/optimization/using_servers.rst:86
msgid ""
"This is a simple example of how to create a sprite from code and move it "
"using the low-level :ref:`CanvasItem <class_CanvasItem>` API."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:111
msgid ""
"The Canvas Item API in the server allows you to add draw primitives to it. "
"Once added, they can't be modified. The Item needs to be cleared and the "
"primitives re-added (this is not the case for setting the transform, which "
"can be done as many times as desired)."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:115
msgid "Primitives are cleared this way:"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:124
msgid "Instantiating a Mesh into 3D space"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:126
msgid ""
"The 3D APIs are different from the 2D ones, so the instantiation API must be "
"used."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:152
msgid "Creating a 2D RigidBody and moving a sprite with it"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:154
msgid ""
"This creates a :ref:`RigidBody2D <class_RigidBody2D>` using the :ref:"
"`Physics2DServer <class_Physics2DServer>` API, and moves a :ref:`CanvasItem "
"<class_CanvasItem>` when the body moves."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:186
msgid ""
"The 3D version should be very similar, as 2D and 3D physics servers are "
"identical (using :ref:`RigidBody <class_RigidBody>` and :ref:`PhysicsServer "
"<class_PhysicsServer>` respectively)."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:190
msgid "Getting data from the servers"
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:192
msgid ""
"Try to **never** request any information from ``VisualServer``, "
"``PhysicsServer`` or ``Physics2DServer`` by calling functions unless you "
"know what you are doing. These servers will often run asynchronously for "
"performance and calling any function that returns a value will stall them "
"and force them to process anything pending until the function is actually "
"called. This will severely decrease performance if you call them every frame "
"(and it won't be obvious why)."
msgstr ""

#: ../../docs/tutorials/optimization/using_servers.rst:198
msgid ""
"Because of this, most APIs in such servers are designed so it's not even "
"possible to request information back, until it's actual data that can be "
"saved."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:4
msgid "Optimization using MultiMeshes"
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:6
msgid ""
"For large amount of instances (in the thousands), that need to be constantly "
"processed (and certain amount of control needs to be retained), :ref:`using "
"servers directly <doc_using_servers>` is the recommended optimization."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:10
msgid ""
"When the amount of objects reach the hundreds of thousands or millions, none "
"of these approaches are efficient anymore. Still, depending on the "
"requirements, there is one more optimization possible."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:15
msgid "MultiMeshes"
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:17
msgid ""
"A :ref:`MultiMesh<class_MultiMesh>` is a single draw primitive that can draw "
"up to millions of objects in one go. It's extremely efficient because it "
"uses the GPU hardware to do this (in OpenGL ES 2.0, it's less efficient "
"because there is no hardware support for it, though)."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:21
msgid ""
"The only drawback is that there is no *screen* or *frustum* culling possible "
"for individual instances. This means, that millions of objects will be "
"*always* or *never* drawn, depending on the visibility of the whole "
"MultiMesh. It is possible to provide a custom visibility rect for them, but "
"it will always be *all-or-none* visibility."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:26
msgid ""
"If the objects are simple enough (just a couple of vertices), this is "
"generally not much of a problem as most modern GPUs are optimized for this "
"use case. A workaround is to create several MultiMeshes for different areas "
"of the world."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:30
msgid ""
"It is also possible to execute some logic inside the vertex shader (using "
"the ``INSTANCE_ID`` or ``INSTANCE_CUSTOM`` built-in constants). For an "
"example of animating thousands of objects in a MultiMesh, see the :ref:"
"`Animating thousands of fish <doc_animating_thousands_of_fish>` tutorial. "
"Information to the shader can be provided via textures (there are floating-"
"point :ref:`Image<class_Image>` formats which are ideal for this)."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:36
msgid ""
"Another alternative is to use GDNative and C++, which should be extremely "
"efficient (it's possible to set the entire state for all objects using "
"linear memory via the :ref:`VisualServer.multimesh_set_as_bulk_array() "
"<class_VisualServer_method_multimesh_set_as_bulk_array>` function). This "
"way, the array can be created with multiple threads, then set in one call, "
"providing high cache efficiency."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:42
msgid ""
"Finally, it's not required to have all MultiMesh instances visible. The "
"amount of visible ones can be controlled with the :ref:`MultiMesh."
"visible_instance_count <class_MultiMesh_property_visible_instance_count>` "
"property. The typical workflow is to allocate the maximum amount of "
"instances that will be used, then change the amount visible depending on how "
"many are currently needed."
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:48
msgid "Multimesh example"
msgstr ""

#: ../../docs/tutorials/optimization/using_multimesh.rst:50
msgid ""
"Here is an example of using a MultiMesh from code. Languages other than "
"GDScript may be more efficient for millions of objects, but for a few "
"thousands, GDScript should be fine."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:4
msgid "Fixing jitter and stutter"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:7
msgid "What are jitter and stutter?"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:9
msgid ""
"*Jitter* and *stutter* are two different alterations to visible motion of "
"objects on screen that may affect a game, even when running at full speed. "
"These effects are mostly visible in games where the world moves at a "
"constant speed in a fixed direction, like runners or platformers."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:14
msgid "Distinguishing between them"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:16
msgid ""
"A game running at a normal framerate without exhibiting any effect will "
"appear smooth:"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:20
msgid "A game exhibiting *jitter* will shake constantly in a very subtle way:"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:24
msgid ""
"Finally, a game exhibiting *stutter* will appear smooth, but appear to "
"*stop* or *roll back a frame* every few seconds:"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:30
msgid "Jitter"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:32
msgid ""
"There can be many causes of jitter, the most typical one happens when the "
"game *physics frequency* (usually 60 Hz) runs at a different resolution than "
"the monitor refresh rate. Check whether your monitor refresh rate is "
"different from 60 Hz."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:35
msgid ""
"This is generally not a problem, given that refresh rates higher than 60 Hz "
"are barely visible to the human eye, and starting with Godot 3.1, a frame "
"timer was introduced that tries to synchronize with refresh as well as "
"possible."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:38
msgid ""
"Sometimes only some objects appear to jitter (character or background). This "
"happens when they are processed in different time sources (one is processed "
"in the physics step while another is processed in the idle step). Godot 3.1 "
"does some improvements to this, from allowing kinematic bodies to be "
"animated in the regular _process loop, to further fixes in the frame timer."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:45
msgid ""
"You can use physics interpolation to mitigate physics-related jittering. See "
"`lawnjelly's smoothing-addon <https://github.com/lawnjelly/smoothing-"
"addon>`__ for an add-on that can be dropped into any project to enable "
"physics interpolation."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:50
msgid "Stutter"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:52
msgid ""
"Stutter may happen due to two different reasons. The first, and most obvious "
"one, is the game not being able to keep full framerate performance. Solving "
"this is game specific and will require optimization."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:55
msgid ""
"The second is more complicated, because it is often not associated to the "
"engine or game but the underlying operating system. Here is some information "
"regarding stutter on different OSs."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:61
msgid ""
"Windows is known to cause stutter in windowed games. This mostly depends on "
"the hardware installed, drivers version and processes running in parallel (e."
"g. having many browser tabs open may cause stutter in a running game). To "
"avoid this, starting with 3.1, Godot raises the game priority to \"Above "
"Normal\". This helps considerably but may not completely eliminate stutter."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:66
msgid ""
"Eliminating this completely requires giving your game full privileges to "
"become \"time critical\", which is not advised. Some games may do it, but it "
"is advised to learn to live with this problem, as it is common for Windows "
"games and most users won't play games windowed (games that are played in a "
"window, e.g. puzzle games, will usually not exhibit this problem anyway)."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:70
msgid ""
"For fullscreen, Windows gives special priority to the game so stutter is no "
"longer visible and very rare. This is how most games are played."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:74
msgid "Linux (X11)"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:76
msgid ""
"Stutter may be visible on Desktop Linux, but this is usually associated with "
"different video drivers and compositors. Nouveau drivers often exhibit this, "
"while AMD or NVidia proprietary don't. Some compositors may also trigger "
"this problem (e.g. KWin), so it is advised to try using a different one to "
"rule it out as the cause."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:80
msgid ""
"There is no workaround for driver or compositor stuttering other than "
"reporting it as an issue to the driver or compositor developers."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:86
msgid ""
"Generally, macOS is stutter-free, although recently some bugs were reported "
"when running on fullscreen (this is a macOS bug). If you have a machine "
"exhibiting this behavior, please let us know."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:92
msgid ""
"Generally, Android is stutter and jitter-free because the running activity "
"gets all the priority. That said, there may be problematic devices (older "
"Kindle Fire is known to be one). If you see this problem on Android, please "
"let us know."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:98
msgid ""
"iOS devices are generally stutter-free, but older devices running newer "
"versions of the operating system may exhibit problems. This is generally "
"unavoidable."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:102
msgid "Reporting stutter or jitter problems"
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:104
msgid ""
"If you are reporting a stutter or jitter problem (opening an issue) not "
"caused by any of the above reasons, please specify very clearly all the "
"information possible about device, operating system, driver versions, etc. "
"This may help to better troubleshoot it."
msgstr ""

#: ../../docs/tutorials/misc/jitter_stutter.rst:107
msgid ""
"Also make sure to use the correct term (jitter or stutter) based on the "
"exhibited behavior. This will help understand your issue much faster. "
"Provide a project that can be used to reproduce the issue, and if possible a "
"screen capture demonstrating the bug."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:4
msgid "Handling quit requests"
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:7
msgid "Quitting"
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:9
msgid ""
"Most platforms have the option to request the application to quit. On "
"desktops, this is usually done with the \"x\" icon on the window title bar. "
"On Android, the back button is used to quit when on the main screen (and to "
"go back otherwise)."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:15
msgid "Handling the notification"
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:17
msgid ""
"On desktop platforms, the :ref:`MainLoop <class_MainLoop>` has a special "
"``MainLoop.NOTIFICATION_WM_QUIT_REQUEST`` notification that is sent to all "
"nodes when quitting is requested."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:21
msgid ""
"On Android, ``MainLoop.NOTIFICATION_WM_GO_BACK_REQUEST`` is sent instead. "
"Pressing the Back button will exit the application if **Application > Config "
"> Quit On Go Back** is checked in the Project Settings (which is the "
"default)."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:28
msgid ""
"``MainLoop.NOTIFICATION_WM_GO_BACK_REQUEST`` isn't supported on iOS, as iOS "
"devices don't have a physical Back button."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:31
msgid "Handling the notification is done as follows (on any node):"
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:48
msgid ""
"When developing mobile apps, quitting is not desired unless the user is on "
"the main screen, so the behavior can be changed."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:51
msgid ""
"It is important to note that by default, Godot apps have the built-in "
"behavior to quit when quit is requested, this can be changed:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:4
msgid "Pausing games"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:7
msgid "Pause?"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:9
msgid ""
"In most games it is desirable to, at some point, interrupt the game to do "
"something else, such as taking a break or changing options. However, this is "
"not as simple as it seems. The game might be stopped, but it might be "
"desirable that some menus and animations continue working."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:15
msgid ""
"Implementing a fine-grained control for what can be paused (and what can "
"not) is a lot of work, so a simple framework for pausing is provided in "
"Godot."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:20
msgid "How pausing works"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:22
msgid ""
"To set pause mode, the pause state must be set. This is done by assigning "
"``true`` to the :ref:`SceneTree.paused <class_SceneTree_property_paused>` "
"property:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:34
msgid "Doing so will have the following behavior:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:36
msgid "2D and 3D physics will be stopped."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:37
msgid ""
"``_process`` and ``_physics_process`` will not be called anymore in nodes."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:38
msgid "``_input`` and ``_input_event`` will not be called anymore either."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:40
msgid ""
"This effectively stops the whole game. Calling this function from a script, "
"by default, will result in an unrecoverable state (nothing will work "
"anymore!)."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:45
msgid "White-listing nodes"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:47
msgid ""
"Before enabling pause, make sure that nodes that must keep working during "
"pause are white-listed. This is done by editing the \"Pause Mode\" property "
"in a node:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:53
msgid "You can achieve the same result in code:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:62
msgid ""
"By default all nodes have this property in the \"Inherit\" state. This "
"means, that they will only process (or not) depending on what this same "
"property is set on the parent node. If the parent is set to \"Inherit\" , "
"then the grandparent will be checked and so on. Ultimately, if a state can't "
"be found in any of the grandparents, the pause state in SceneTree is used. "
"This means that, by default, when the game is paused every node will be "
"paused."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:70
msgid "So the three possible states for a node are:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:72
msgid ""
"**Inherit**: Process depending on the state of the parent, grandparent, etc. "
"The first parent that has a non-Inherit state."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:74
msgid ""
"**Stop**: Stop the node no matter what (and children in Inherit mode). When "
"paused this node will not process."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:76
msgid ""
"**Process**: Process the node no matter what (and children in Inherit mode). "
"Paused or not this node will process."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:82
msgid ""
"An example of this is creating a popup or panel with controls inside, and "
"set its pause mode to \"Process\" then hide it:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:87
msgid ""
"Just by setting the root of the pause popup to \"Process\", all children and "
"grandchildren will inherit that state. This way, this branch of the scene "
"tree will continue working when paused."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:91
msgid ""
"Finally, make it so when a pause button is pressed (any button will do), "
"enable the pause and show the pause screen."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:109
msgid "To remove the pause, do the opposite when the pause screen is closed:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:127
msgid "And that should be all!"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:4
msgid "Binary serialization API"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:9
msgid ""
"Godot has a simple serialization API based on Variant. It's used for "
"converting data types to an array of bytes efficiently. This API is used in "
"the functions ``get_var`` and ``store_var`` of :ref:`class_File` as well as "
"the packet APIs for :ref:`class_PacketPeer`. This format is not used for "
"binary scenes and resources."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:16
msgid "Packet specification"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:18
msgid ""
"The packet is designed to be always padded to 4 bytes. All values are little "
"endian encoded. All packets have a 4 byte header representing an integer, "
"specifying the type of data:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:25
msgid "0"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:27
#: ../../docs/tutorials/misc/binary_serialization_api.rst:390
msgid "1"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:29
msgid "integer"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:35
msgid "vector2"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:37
msgid "rect2"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:39
msgid "vector3"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:41
msgid "transform2d"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:43
msgid "plane"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:45
msgid "quat"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:47
msgid "aabb"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:49
#: ../../docs/tutorials/misc/binary_serialization_api.rst:152
#: ../../docs/tutorials/misc/binary_serialization_api.rst:167
#: ../../docs/tutorials/misc/binary_serialization_api.rst:180
#: ../../docs/tutorials/misc/binary_serialization_api.rst:199
#: ../../docs/tutorials/misc/binary_serialization_api.rst:214
#: ../../docs/tutorials/misc/binary_serialization_api.rst:229
#: ../../docs/tutorials/misc/binary_serialization_api.rst:248
#: ../../docs/tutorials/misc/binary_serialization_api.rst:273
#: ../../docs/tutorials/misc/binary_serialization_api.rst:304
msgid "12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:49
msgid "basis"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:51
msgid "13"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:51
msgid "transform"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:53
msgid "14"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:53
msgid "color"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:55
msgid "15"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:55
msgid "node path"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:57
#: ../../docs/tutorials/misc/binary_serialization_api.rst:154
#: ../../docs/tutorials/misc/binary_serialization_api.rst:182
#: ../../docs/tutorials/misc/binary_serialization_api.rst:201
#: ../../docs/tutorials/misc/binary_serialization_api.rst:216
#: ../../docs/tutorials/misc/binary_serialization_api.rst:231
#: ../../docs/tutorials/misc/binary_serialization_api.rst:250
#: ../../docs/tutorials/misc/binary_serialization_api.rst:275
#: ../../docs/tutorials/misc/binary_serialization_api.rst:306
msgid "16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:57
msgid "rid"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:59
msgid "17"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:59
msgid "object"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:61
msgid "18"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:61
msgid "dictionary"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:63
msgid "19"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:63
msgid "array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:65
#: ../../docs/tutorials/misc/binary_serialization_api.rst:184
#: ../../docs/tutorials/misc/binary_serialization_api.rst:233
#: ../../docs/tutorials/misc/binary_serialization_api.rst:252
#: ../../docs/tutorials/misc/binary_serialization_api.rst:277
msgid "20"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:65
msgid "raw array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:67
msgid "21"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:67
msgid "int array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:69
msgid "22"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:69
msgid "real array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:71
msgid "23"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:71
msgid "string array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:73
#: ../../docs/tutorials/misc/binary_serialization_api.rst:186
#: ../../docs/tutorials/misc/binary_serialization_api.rst:235
#: ../../docs/tutorials/misc/binary_serialization_api.rst:254
#: ../../docs/tutorials/misc/binary_serialization_api.rst:279
msgid "24"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:73
msgid "vector2 array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:75
msgid "25"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:75
msgid "vector3 array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:77
msgid "26"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:77
msgid "color array"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:79
msgid "27"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:79
msgid "max"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:82
msgid ""
"Following this is the actual packet contents, which varies for each type of "
"packet. Note that this assumes Godot is compiled with single precision "
"floats. If instead doubles are used, the length of \"Float\" fields within "
"data structures should be 8, and the offset should be (offset - 4) * 2 + 4. "
"The \"float\" type itself is always double precision."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:89
msgid "0: null"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:92
msgid "1: :ref:`bool<class_bool>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:95
#: ../../docs/tutorials/misc/binary_serialization_api.rst:104
#: ../../docs/tutorials/misc/binary_serialization_api.rst:113
#: ../../docs/tutorials/misc/binary_serialization_api.rst:122
#: ../../docs/tutorials/misc/binary_serialization_api.rst:135
#: ../../docs/tutorials/misc/binary_serialization_api.rst:146
#: ../../docs/tutorials/misc/binary_serialization_api.rst:161
#: ../../docs/tutorials/misc/binary_serialization_api.rst:174
#: ../../docs/tutorials/misc/binary_serialization_api.rst:193
#: ../../docs/tutorials/misc/binary_serialization_api.rst:208
#: ../../docs/tutorials/misc/binary_serialization_api.rst:223
#: ../../docs/tutorials/misc/binary_serialization_api.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:267
#: ../../docs/tutorials/misc/binary_serialization_api.rst:298
#: ../../docs/tutorials/misc/binary_serialization_api.rst:313
#: ../../docs/tutorials/misc/binary_serialization_api.rst:322
#: ../../docs/tutorials/misc/binary_serialization_api.rst:333
#: ../../docs/tutorials/misc/binary_serialization_api.rst:343
#: ../../docs/tutorials/misc/binary_serialization_api.rst:362
#: ../../docs/tutorials/misc/binary_serialization_api.rst:374
#: ../../docs/tutorials/misc/binary_serialization_api.rst:386
#: ../../docs/tutorials/misc/binary_serialization_api.rst:399
#: ../../docs/tutorials/misc/binary_serialization_api.rst:410
#: ../../docs/tutorials/misc/binary_serialization_api.rst:421
#: ../../docs/tutorials/misc/binary_serialization_api.rst:429
#: ../../docs/tutorials/misc/binary_serialization_api.rst:442
#: ../../docs/tutorials/misc/binary_serialization_api.rst:455
#: ../../docs/tutorials/misc/binary_serialization_api.rst:470
msgid "Offset"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:95
#: ../../docs/tutorials/misc/binary_serialization_api.rst:104
#: ../../docs/tutorials/misc/binary_serialization_api.rst:113
#: ../../docs/tutorials/misc/binary_serialization_api.rst:122
#: ../../docs/tutorials/misc/binary_serialization_api.rst:135
#: ../../docs/tutorials/misc/binary_serialization_api.rst:146
#: ../../docs/tutorials/misc/binary_serialization_api.rst:161
#: ../../docs/tutorials/misc/binary_serialization_api.rst:174
#: ../../docs/tutorials/misc/binary_serialization_api.rst:193
#: ../../docs/tutorials/misc/binary_serialization_api.rst:208
#: ../../docs/tutorials/misc/binary_serialization_api.rst:223
#: ../../docs/tutorials/misc/binary_serialization_api.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:267
#: ../../docs/tutorials/misc/binary_serialization_api.rst:298
#: ../../docs/tutorials/misc/binary_serialization_api.rst:313
#: ../../docs/tutorials/misc/binary_serialization_api.rst:322
#: ../../docs/tutorials/misc/binary_serialization_api.rst:333
#: ../../docs/tutorials/misc/binary_serialization_api.rst:343
#: ../../docs/tutorials/misc/binary_serialization_api.rst:362
#: ../../docs/tutorials/misc/binary_serialization_api.rst:374
#: ../../docs/tutorials/misc/binary_serialization_api.rst:386
#: ../../docs/tutorials/misc/binary_serialization_api.rst:399
#: ../../docs/tutorials/misc/binary_serialization_api.rst:410
#: ../../docs/tutorials/misc/binary_serialization_api.rst:421
#: ../../docs/tutorials/misc/binary_serialization_api.rst:429
#: ../../docs/tutorials/misc/binary_serialization_api.rst:442
#: ../../docs/tutorials/misc/binary_serialization_api.rst:455
#: ../../docs/tutorials/misc/binary_serialization_api.rst:470
msgid "Len"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:97
msgid "0 for False, 1 for True"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:101
msgid "2: :ref:`int<class_int>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:106
msgid "Signed, 64-bit Integer"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:110
#, fuzzy
msgid "3: :ref:`float<class_float>`"
msgstr "אנימציות"

#: ../../docs/tutorials/misc/binary_serialization_api.rst:115
#: ../../docs/tutorials/misc/binary_serialization_api.rst:137
#: ../../docs/tutorials/misc/binary_serialization_api.rst:139
#: ../../docs/tutorials/misc/binary_serialization_api.rst:148
#: ../../docs/tutorials/misc/binary_serialization_api.rst:150
#: ../../docs/tutorials/misc/binary_serialization_api.rst:152
#: ../../docs/tutorials/misc/binary_serialization_api.rst:154
#: ../../docs/tutorials/misc/binary_serialization_api.rst:163
#: ../../docs/tutorials/misc/binary_serialization_api.rst:165
#: ../../docs/tutorials/misc/binary_serialization_api.rst:167
#: ../../docs/tutorials/misc/binary_serialization_api.rst:176
#: ../../docs/tutorials/misc/binary_serialization_api.rst:178
#: ../../docs/tutorials/misc/binary_serialization_api.rst:180
#: ../../docs/tutorials/misc/binary_serialization_api.rst:182
#: ../../docs/tutorials/misc/binary_serialization_api.rst:184
#: ../../docs/tutorials/misc/binary_serialization_api.rst:186
#: ../../docs/tutorials/misc/binary_serialization_api.rst:195
#: ../../docs/tutorials/misc/binary_serialization_api.rst:197
#: ../../docs/tutorials/misc/binary_serialization_api.rst:199
#: ../../docs/tutorials/misc/binary_serialization_api.rst:201
#: ../../docs/tutorials/misc/binary_serialization_api.rst:210
#: ../../docs/tutorials/misc/binary_serialization_api.rst:212
#: ../../docs/tutorials/misc/binary_serialization_api.rst:214
#: ../../docs/tutorials/misc/binary_serialization_api.rst:216
#: ../../docs/tutorials/misc/binary_serialization_api.rst:225
#: ../../docs/tutorials/misc/binary_serialization_api.rst:227
#: ../../docs/tutorials/misc/binary_serialization_api.rst:229
#: ../../docs/tutorials/misc/binary_serialization_api.rst:231
#: ../../docs/tutorials/misc/binary_serialization_api.rst:233
#: ../../docs/tutorials/misc/binary_serialization_api.rst:235
#: ../../docs/tutorials/misc/binary_serialization_api.rst:244
#: ../../docs/tutorials/misc/binary_serialization_api.rst:246
#: ../../docs/tutorials/misc/binary_serialization_api.rst:248
#: ../../docs/tutorials/misc/binary_serialization_api.rst:250
#: ../../docs/tutorials/misc/binary_serialization_api.rst:252
#: ../../docs/tutorials/misc/binary_serialization_api.rst:254
#: ../../docs/tutorials/misc/binary_serialization_api.rst:256
#: ../../docs/tutorials/misc/binary_serialization_api.rst:258
#: ../../docs/tutorials/misc/binary_serialization_api.rst:260
#: ../../docs/tutorials/misc/binary_serialization_api.rst:269
#: ../../docs/tutorials/misc/binary_serialization_api.rst:271
#: ../../docs/tutorials/misc/binary_serialization_api.rst:273
#: ../../docs/tutorials/misc/binary_serialization_api.rst:275
#: ../../docs/tutorials/misc/binary_serialization_api.rst:277
#: ../../docs/tutorials/misc/binary_serialization_api.rst:279
#: ../../docs/tutorials/misc/binary_serialization_api.rst:281
#: ../../docs/tutorials/misc/binary_serialization_api.rst:283
#: ../../docs/tutorials/misc/binary_serialization_api.rst:285
#: ../../docs/tutorials/misc/binary_serialization_api.rst:287
#: ../../docs/tutorials/misc/binary_serialization_api.rst:289
#: ../../docs/tutorials/misc/binary_serialization_api.rst:291
#: ../../docs/tutorials/misc/binary_serialization_api.rst:300
#: ../../docs/tutorials/misc/binary_serialization_api.rst:302
#: ../../docs/tutorials/misc/binary_serialization_api.rst:304
#: ../../docs/tutorials/misc/binary_serialization_api.rst:306
#: ../../docs/tutorials/misc/binary_serialization_api.rst:446
#: ../../docs/tutorials/misc/binary_serialization_api.rst:448
#: ../../docs/tutorials/misc/binary_serialization_api.rst:459
#: ../../docs/tutorials/misc/binary_serialization_api.rst:461
#: ../../docs/tutorials/misc/binary_serialization_api.rst:463
#: ../../docs/tutorials/misc/binary_serialization_api.rst:474
#: ../../docs/tutorials/misc/binary_serialization_api.rst:476
#: ../../docs/tutorials/misc/binary_serialization_api.rst:478
#: ../../docs/tutorials/misc/binary_serialization_api.rst:480
msgid "Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:115
msgid "IEE 754 32-Bits Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:119
msgid "4: :ref:`String<class_string>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:124
msgid "String Length (in Bytes)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:126
#: ../../docs/tutorials/misc/binary_serialization_api.rst:324
#: ../../docs/tutorials/misc/binary_serialization_api.rst:347
#: ../../docs/tutorials/misc/binary_serialization_api.rst:433
msgid "X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:126
#: ../../docs/tutorials/misc/binary_serialization_api.rst:324
#: ../../docs/tutorials/misc/binary_serialization_api.rst:347
#: ../../docs/tutorials/misc/binary_serialization_api.rst:433
msgid "Bytes"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:126
#: ../../docs/tutorials/misc/binary_serialization_api.rst:324
#: ../../docs/tutorials/misc/binary_serialization_api.rst:347
#: ../../docs/tutorials/misc/binary_serialization_api.rst:433
msgid "UTF-8 Encoded String"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:129
msgid "This field is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:132
msgid "5: :ref:`Vector2<class_vector2>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:137
#: ../../docs/tutorials/misc/binary_serialization_api.rst:148
#: ../../docs/tutorials/misc/binary_serialization_api.rst:163
#: ../../docs/tutorials/misc/binary_serialization_api.rst:225
#: ../../docs/tutorials/misc/binary_serialization_api.rst:446
#: ../../docs/tutorials/misc/binary_serialization_api.rst:459
msgid "X Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:139
#: ../../docs/tutorials/misc/binary_serialization_api.rst:150
#: ../../docs/tutorials/misc/binary_serialization_api.rst:165
#: ../../docs/tutorials/misc/binary_serialization_api.rst:227
#: ../../docs/tutorials/misc/binary_serialization_api.rst:448
#: ../../docs/tutorials/misc/binary_serialization_api.rst:461
msgid "Y Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:143
msgid "6: :ref:`Rect2<class_rect2>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:152
#: ../../docs/tutorials/misc/binary_serialization_api.rst:231
msgid "X Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:154
#: ../../docs/tutorials/misc/binary_serialization_api.rst:233
msgid "Y Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:158
msgid "7: :ref:`Vector3<class_vector3>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:167
#: ../../docs/tutorials/misc/binary_serialization_api.rst:229
#: ../../docs/tutorials/misc/binary_serialization_api.rst:463
msgid "Z Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:171
msgid "8: :ref:`Transform2D<class_transform2d>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:176
#: ../../docs/tutorials/misc/binary_serialization_api.rst:244
#: ../../docs/tutorials/misc/binary_serialization_api.rst:269
msgid "The X component of the X column vector, accessed via [0][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:178
#: ../../docs/tutorials/misc/binary_serialization_api.rst:246
#: ../../docs/tutorials/misc/binary_serialization_api.rst:271
msgid "The Y component of the X column vector, accessed via [0][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:180
#: ../../docs/tutorials/misc/binary_serialization_api.rst:250
#: ../../docs/tutorials/misc/binary_serialization_api.rst:275
msgid "The X component of the Y column vector, accessed via [1][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:182
#: ../../docs/tutorials/misc/binary_serialization_api.rst:252
#: ../../docs/tutorials/misc/binary_serialization_api.rst:277
msgid "The Y component of the Y column vector, accessed via [1][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:184
msgid "The X component of the origin vector, accessed via [2][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:186
msgid "The Y component of the origin vector, accessed via [2][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:190
msgid "9: :ref:`Plane<class_plane>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:195
msgid "Normal X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:197
msgid "Normal Y"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:199
msgid "Normal Z"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:201
msgid "Distance"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:205
msgid "10: :ref:`Quat<class_quat>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:210
msgid "Imaginary X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:212
msgid "Imaginary Y"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:214
msgid "Imaginary Z"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:216
msgid "Real W"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:220
msgid "11: :ref:`AABB<class_aabb>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:235
msgid "Z Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:239
msgid "12: :ref:`Basis<class_basis>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:248
#: ../../docs/tutorials/misc/binary_serialization_api.rst:273
msgid "The Z component of the X column vector, accessed via [0][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:254
#: ../../docs/tutorials/misc/binary_serialization_api.rst:279
msgid "The Z component of the Y column vector, accessed via [1][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:256
#: ../../docs/tutorials/misc/binary_serialization_api.rst:281
msgid "28"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:256
#: ../../docs/tutorials/misc/binary_serialization_api.rst:281
msgid "The X component of the Z column vector, accessed via [2][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:258
#: ../../docs/tutorials/misc/binary_serialization_api.rst:283
msgid "32"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:258
#: ../../docs/tutorials/misc/binary_serialization_api.rst:283
msgid "The Y component of the Z column vector, accessed via [2][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:260
#: ../../docs/tutorials/misc/binary_serialization_api.rst:285
msgid "36"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:260
#: ../../docs/tutorials/misc/binary_serialization_api.rst:285
msgid "The Z component of the Z column vector, accessed via [2][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:264
msgid "13: :ref:`Transform<class_transform>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:287
msgid "40"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:287
msgid "The X component of the origin vector, accessed via [3][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:289
msgid "44"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:289
msgid "The Y component of the origin vector, accessed via [3][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:291
msgid "48"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:291
msgid "The Z component of the origin vector, accessed via [3][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:295
msgid "14: :ref:`Color<class_color>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:300
#: ../../docs/tutorials/misc/binary_serialization_api.rst:474
msgid "Red (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:302
#: ../../docs/tutorials/misc/binary_serialization_api.rst:476
msgid "Green (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:304
#: ../../docs/tutorials/misc/binary_serialization_api.rst:478
msgid "Blue (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:306
#: ../../docs/tutorials/misc/binary_serialization_api.rst:480
msgid "Alpha (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:310
msgid "15: :ref:`NodePath<class_nodepath>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:315
msgid ""
"String Length, or New Format (val&0x80000000!=0 and NameCount=val&0x7FFFFFFF)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:319
msgid "For old format:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:327
msgid "Padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:330
msgid "For new format:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:335
msgid "Sub-Name Count"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:337
msgid "Flags (absolute: val&1 != 0 )"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:340
msgid "For each Name and Sub-Name"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:345
#: ../../docs/tutorials/misc/binary_serialization_api.rst:431
msgid "X+0"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:345
#: ../../docs/tutorials/misc/binary_serialization_api.rst:431
msgid "String Length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:347
#: ../../docs/tutorials/misc/binary_serialization_api.rst:433
msgid "X+4"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:350
msgid "Every name string is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:353
msgid "16: :ref:`RID<class_rid>` (unsupported)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:356
msgid "17: :ref:`Object<class_object>` (unsupported)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:359
msgid "18: :ref:`Dictionary<class_dictionary>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:364
#: ../../docs/tutorials/misc/binary_serialization_api.rst:376
msgid "val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:367
msgid ""
"Then what follows is, for amount of \"elements\", pairs of key and value, "
"one after the other, using this same format."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:371
msgid "19: :ref:`Array<class_array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:379
msgid ""
"Then what follows is, for amount of \"elements\", values one after the "
"other, using this same format."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:383
msgid "20: :ref:`PoolByteArray<class_poolbytearray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:388
msgid "Array Length (Bytes)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:390
msgid "8..8+length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:390
msgid "Byte"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:390
msgid "Byte (0..255)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:393
msgid "The array data is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:396
msgid "21: :ref:`PoolIntArray<class_poolintarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:401
msgid "Array Length (Integers)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:403
#: ../../docs/tutorials/misc/binary_serialization_api.rst:414
msgid "8..8+length\\*4"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:403
msgid "32 Bits Signed Integer"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:407
msgid "22: :ref:`PoolRealArray<class_poolrealarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:412
msgid "Array Length (Floats)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:414
msgid "32 Bits IEEE 754 Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:418
msgid "23: :ref:`PoolStringArray<class_poolstringarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:423
msgid "Array Length (Strings)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:426
msgid "For each String:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:436
msgid "Every string is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:439
msgid "24: :ref:`PoolVector2Array<class_poolvector2array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:444
#: ../../docs/tutorials/misc/binary_serialization_api.rst:457
#: ../../docs/tutorials/misc/binary_serialization_api.rst:472
msgid "Array Length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:446
msgid "8..8+length\\*8"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:448
msgid "8..12+length\\*8"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:452
msgid "25: :ref:`PoolVector3Array<class_poolvector3array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:459
msgid "8..8+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:461
msgid "8..12+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:463
msgid "8..16+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:467
msgid "26: :ref:`PoolColorArray<class_poolcolorarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:474
msgid "8..8+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:476
msgid "8..12+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:478
msgid "8..16+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:480
msgid "8..20+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:4
msgid "Running code in the editor"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:7
msgid "What is ``tool``?"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:9
msgid ""
"``tool`` is a powerful line of code that, when added at the top of your "
"script, makes it execute in the editor. You can also decide which parts of "
"the script execute in the editor, which in game, and which in both."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:11
msgid ""
"You can use it for doing many things, but it is mostly useful in level "
"design for visually presenting things that are hard to predict ourselves. "
"Here are some use cases:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:13
msgid ""
"If you have a cannon that shoots cannonballs affected by physics (gravity), "
"you can draw cannonball's trajectory in the editor, making level design a "
"lot easier."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:14
msgid ""
"If you have jumppads with varying jump heights, you can draw the maximum "
"jump height a player would reach if it jumped on one, also making level "
"design easier."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:15
msgid ""
"If your player doesn't use a sprite, but draws itself using code, you can "
"make that drawing code execute in the editor to see your player."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:19
msgid ""
"``tool`` scripts run inside the editor, and let you access the scene tree of "
"the currently edited scene. This is a powerful feature which also comes with "
"caveats, as the editor does not include protections for potential misuse of "
"``tool`` scripts. Be **extremely** cautious when manipulating the scene "
"tree, especially via :ref:`Node.queue_free<class_Node_method_queue_free>`, "
"as it can cause crashes if you free a node while the editor runs logic "
"involving it."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:28
msgid "How to use it"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:30
msgid ""
"To turn a script into a tool, add ``tool`` keyword at the top of your code."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:32
msgid ""
"To check if you are currently in the editor, use: ``Engine.editor_hint``."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:34
msgid "For example, if you want to execute some code only in editor, use:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:42
msgid ""
"On the other hand, if you want to execute code only in game, simply negate "
"previous expression:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:50
msgid ""
"Pieces of code that are not having any of the 2 conditions above will run "
"both in editor and in game."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:52
msgid "Here is how a ``_process()`` function might look like for you:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:66
msgid ""
"Modifications in editor are permanent. In our case, when we remove the "
"script, the node will keep its rotation direction. Be careful so that you "
"don't make unwanted modifications."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:69
msgid "Try it out"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:71
msgid ""
"Add a ``Sprite`` node to your scene and set the texture to Godot icon. "
"Attach and open a script, and change it to this:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:82
msgid ""
"Save the script and return to the editor. You should now see your object "
"rotate. If you run the game, it will also rotate."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:86
msgid ""
"If you don't see the changes, reload the scene (close it and open it again)."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:88
msgid ""
"Now let's choose which code runs when. Modify your ``_process()`` function "
"to look like this:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:99
msgid ""
"Save the script. Now the object will spin clockwise in the editor, but if "
"you run the game, it will spin counter-clockwise."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:102
#, fuzzy
msgid "Editing variables"
msgstr "נקודות ציון מקומיות"

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:103
msgid ""
"Add and export a variable speed to the script. The function set_speed after "
"\"setget\" is executed with your input to change the variable. Modify  "
"``_process()`` to include the rotation speed."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:125
msgid ""
"Code from other nodes doesn't run in the editor. Your access to other nodes "
"is limited. You can access the tree and nodes, and their default properties, "
"but you can't access user variables. If you want to do so, other nodes have "
"to run in the editor too. AutoLoad nodes cannot be accessed in the editor at "
"all."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:130
msgid ""
"You can instantiate packed scenes normally and add them to the scene "
"currently opened in the editor. Be sure to set the scene root as the owner "
"of all the nodes created this way or the nodes won't be visible in the "
"editor."
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:132
msgid "If you are using ``tool``:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:142
msgid "If you are using :ref:`EditorScript<class_EditorScript>`:"
msgstr ""

#: ../../docs/tutorials/misc/running_code_in_the_editor.rst:153
msgid ""
"Using ``tool`` improperly can yield many errors. It is advised to first "
"write the code how you want it, and only then add the ``tool`` keyword to "
"the top. Also make sure you divide your code into part that runs in editor "
"and part that runs in game. This way you can find your bug easier."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:4
msgid "Change scenes manually"
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:6
msgid ""
"Sometimes it helps to have more control over how one swaps scenes around. As "
"mentioned above, a :ref:`Viewport <class_Viewport>`'s child nodes will "
"render to the image it generates. This holds true even for nodes outside of "
"the \"current\" scene. Autoloads fall into this category, but so do scenes "
"which one instances and adds to the tree at runtime:"
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:38
msgid ""
"To complete the cycle and swap out the new scene with the old one, "
"developers have a choice to make. Many strategies exist for removing a scene "
"from view of the :ref:`Viewport <class_Viewport>`. The tradeoffs involve "
"balancing operation speed and memory consumption as well as balancing data "
"access and integrity."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:44
msgid ""
"**We can delete the existing scene.** :ref:`SceneTree.change_scene() "
"<class_SceneTree_method_change_scene>` and :ref:`SceneTree.change_scene_to() "
"<class_SceneTree_method_change_scene_to>` will delete the current scene "
"immediately. Developers can also delete the main scene though. Assuming the "
"root node's name is \"Main\", one could do ``get_node(\"/root/Main\")."
"free()`` to delete the whole scene."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:51
msgid "Unloads memory."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:53
msgid "Pro: RAM is no longer dragging the dead weight."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:55
msgid ""
"Con: Returning to that scene is now more expensive since it must be loaded "
"back into memory again (takes time AND memory). Not a problem if returning "
"soon is unnecessary."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:59
msgid ""
"Con: No longer have access to that scene's data. Not a problem if using that "
"data soon is unnecessary."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:62
msgid ""
"Note: It can be useful to preserve the data in a soon-to-be-deleted scene by "
"re-attaching one or more of its nodes to a different scene, or even directly "
"to the :ref:`SceneTree <class_SceneTree>`."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:66
msgid "Processing stops."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:68
msgid ""
"Pro: No nodes means no process, physics process, or input handling. The CPU "
"is available to work on the new scene's contents."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:71
msgid ""
"Con: Those nodes' processing and input handling no longer operate. Not a "
"problem if using the updated data is unnecessary."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:74
msgid ""
"**We can hide the existing scene.** By changing the visibility or collision "
"detection of the nodes, we can hide the entire node sub-tree from the "
"player's perspective."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:78
msgid "Memory still exists."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:80
msgid "Pro: One can still access the data if need be."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:82
msgid "Pro: There's no need to move any more nodes around to save data."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:84
msgid ""
"Con: More data is being kept in memory which will be become a problem on "
"memory-sensitive platforms like web or mobile."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:87
msgid "Processing continues."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:89
msgid ""
"Pro: Data continues to receive processing updates, so the scene will keep "
"updated any data within it that relies on delta time or frame data."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:93
msgid ""
"Pro: Nodes are still members of groups (since groups belong to the :ref:"
"`SceneTree <class_SceneTree>`)."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:96
msgid ""
"Con: The CPU's attention is now divided between both scenes. Too much load "
"could result in low frame rates. One should be sure to test performance as "
"they go to ensure the target platform can support the load they are giving "
"it."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:101
msgid ""
"**We can remove the existing scene from the tree.** Assign a variable to the "
"existing scene's root node. Then use :ref:`Node.remove_child(Node) "
"<class_Node_method_remove_child>` to detach the entire scene from the tree."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:106
msgid "Memory still exists (similar pros/cons as with hiding it from view)."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:108
msgid "Processing stops (similar pros/cons as with deleting it completely)."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:110
msgid ""
"Pro: This variation of \"hiding\" it is much easier to show/hide. Rather "
"than potentially keeping track of multiple changes to the scene, one must "
"only call the one method add/remove_child pair of methods. It is similar to "
"disabling game objects in other engines."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:115
msgid ""
"Con: Unlike with hiding it from view only, the data contained within the "
"scene will become stale if it relies on delta time, input, groups, or other "
"data that is derived from :ref:`SceneTree <class_SceneTree>` access."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:120
msgid ""
"There are also cases where one may wish to have many scenes present at the "
"same time. Perhaps one is adding their own singleton at runtime, or "
"preserving a a scene's data between scene changes (adding the scene to the "
"root node)."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:133
msgid ""
"Perhaps instead they wish to display multiple scenes at the same time using "
"a :ref:`ViewportContainers <class_ViewportContainer>`. This is optimal in "
"cases where the intent is to render different content in different parts of "
"the screen. Minimaps and split-screen multiplayer are good examples."
msgstr ""

#: ../../docs/tutorials/misc/change_scenes_manually.rst:138
msgid ""
"Each option will have cases where it is best appropriate, so one must "
"examine the effects of each and determine what path best fits their unique "
"situation."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:4
msgid "Differences between GLES2 and GLES3"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:6
msgid ""
"This page documents the differences between GLES2 and GLES3 that are by "
"design and are not the result of bugs. There may be differences that are "
"unintentional, but they should be reported as bugs."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:9
msgid ""
"\"GLES2\" and \"GLES3\" are the names used in Godot for the two OpenGL-based "
"rendering backends. In terms of graphics APIs, the GLES2 backend maps to "
"OpenGL 2.1 on desktop, OpenGL ES 2.0 on mobile and WebGL 1.0 on the web. The "
"GLES3 backend maps to OpenGL 3.3 on desktop, OpenGL ES 3.0 on mobile and "
"WebGL 2.0 on the web."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:15
msgid "Particles"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:17
msgid ""
"GLES2 cannot use the :ref:`Particles <class_Particles>` or :ref:`Particles2D "
"<class_Particles2D>` nodes as they require advanced GPU features. Instead, "
"use :ref:`CPUParticles <class_CPUParticles>` or :ref:`CPUParticles2D "
"<class_CPUParticles2D>`, which provides a similar interface to a :ref:"
"`ParticlesMaterial <class_ParticlesMaterial>`."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:22
msgid ""
"Particles and Particles2D can be converted to their CPU equivalent node with "
"the \"Convert to CPUParticles\" option in the editor."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:26
msgid "``SCREEN_TEXTURE`` mip-maps"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:28
msgid ""
"In GLES2, ``SCREEN_TEXTURE`` (accessed via a :ref:`ShaderMaterial "
"<class_ShaderMaterial>`) does not have computed mip-maps. So when accessing "
"at a different LOD, the texture will not appear blurry."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:32
msgid "``DEPTH_TEXTURE``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:34
msgid ""
"While GLES2 supports ``DEPTH_TEXTURE`` in shaders, it may not work on some "
"old hardware (especially mobile)."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:37
msgid "Color space"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:39
msgid ""
"GLES2 and GLES3 are in different color spaces. This means that colors will "
"appear slightly different between them  especially when lighting is used."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:42
msgid ""
"If your game is going to use both GLES2 and GLES3, you can use an ``if`` "
"statement check and see if the output is in sRGB, using ``OUTPUT_IS_SRGB``. "
"``OUTPUT_IS_SRGB`` is ``true`` in GLES2 and ``false`` in GLES3."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:47
msgid "HDR"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:49
msgid ""
"GLES2 is not capable of using High Dynamic Range (HDR) rendering features. "
"If HDR is set for your project, or for a given viewport, Godot will still "
"user Low Dynamic Range (LDR) which limits viewport values to the ``0-1`` "
"range."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:54
msgid "SpatialMaterial features"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:56
msgid ""
"In GLES2, the following advanced rendering features in the :ref:"
"`SpatialMaterial <class_SpatialMaterial>` are missing:"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:59
msgid "Subsurface scattering"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:62
msgid "Depth mapping"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:64
msgid "When using SpatialMaterials they will not even appear in the editor."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:66
msgid ""
"In custom :ref:`ShaderMaterials <class_ShaderMaterial>`, you can set values "
"for these features but they will be non-functional. For example, you will "
"still be able to set the ``SSS`` built-in (which normally adds subsurface "
"scattering) in your shader, but nothing will happen."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:71
msgid "Environment features"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:73
msgid ""
"In GLES2, the following features in the :ref:`Environment "
"<class_Environment>` are missing:"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:75
msgid "Auto exposure"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:76
msgid "Tonemapping"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:77
msgid "Screen space reflections"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:78
msgid "Screen space ambient occlusion"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:80
msgid "That means that in GLES2 environments you can only set:"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:82
msgid "Sky (including procedural sky)"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:83
msgid "Ambient light"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:85
msgid "Depth of field"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:86
msgid "Glow (also known as bloom)"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:87
msgid "Adjustment"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:90
msgid "GIProbes"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:92
msgid ""
":ref:`GIProbes <class_GIProbe>` do not work in GLES2. Instead use :ref:"
"`Baked Lightmaps <class_BakedLightmap>`. For a description of how baked "
"lightmaps work see the :ref:`Baked Lightmaps tutorial <doc_baked_lightmaps>`."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:96
msgid "Contact shadows"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:98
msgid ""
"The ``shadow_contact`` property of :ref:`Lights <class_Light>` is not "
"supported in GLES2 and so does nothing."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:101
msgid "Light performance"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:103
msgid ""
"In GLES2, performance scales poorly with several lights, as each light is "
"processed in a separate render pass (in opposition to GLES3 which is all "
"done in a single pass). Try to limit scenes to as few lights as possible in "
"order to achieve greatest performance."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:110
msgid ""
"On mobile, GLES2 requires ETC texture compression, while GLES3 requires "
"ETC2. ETC2 is enabled by default, so if exporting to mobile using GLES2 make "
"sure to set the project setting ``rendering/vram_compression/import_etc`` "
"and then reimport textures."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:116
msgid ""
"Since ETC doesn't support transparency, you must reimport textures that "
"contain an alpha channel to use the Uncompressed, Lossy or Lossless "
"compression mode (instead of Video RAM). This can be done in the Import dock "
"after selecting them in the FileSystem dock."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:122
msgid "Blend shapes"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:124
msgid "Blend shapes are not supported in GLES2."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:129
msgid ""
"GLES3 provides many built-in functions that GLES2 does not. Below is a list "
"of functions that are not available or are have limited support in GLES2."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:132
msgid ""
"For a complete list of built-in GLSL functions see the :ref:`Shading "
"Language doc <doc_shading_language>`."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:137
msgid "vec_type **modf** ( vec_type x, out vec_type i )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:139
msgid "vec_int_type **floatBitsToInt** ( vec_type x )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:141
msgid "vec_uint_type **floatBitsToUint** ( vec_type x )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:143
msgid "vec_type **intBitsToFloat** ( vec_int_type x )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:145
msgid "vec_type **uintBitsToFloat** ( vec_uint_type x )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:147
msgid "ivec2 **textureSize** ( sampler2D_type s, int lod )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:147
#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:149
msgid "See workaround below"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:149
msgid "ivec2 **textureSize** ( samplerCube s, int lod )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:151
msgid "vec4_type **texture** ( sampler_type s, vec_type uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:151
msgid "**bias** not available in vertex shader"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:153
msgid ""
"vec4_type **textureProj** ( sampler_type s, vec_type uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:155
msgid "vec4_type **textureLod** ( sampler_type s, vec_type uv, float lod )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:155
msgid "Only available in vertex shader on some hardware"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:157
msgid "vec4_type **textureProjLod** ( sampler_type s, vec_type uv, float lod )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:159
msgid ""
"vec4_type **textureGrad** ( sampler_type s, vec_type uv, vec_type dPdx, "
"vec_type dPdy)"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:161
msgid "vec_type **dFdx** ( vec_type p )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:163
msgid "vec_type **dFdy** ( vec_type p )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:165
msgid "vec_type **fwidth** ( vec_type p )"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:168
msgid ""
"Functions not in GLES2's GLSL were added with Godots own shader standard "
"library. These functions may perform worse in GLES2 compared to GLES3."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:171
msgid "``textureSize()`` workaround"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:173
msgid ""
"GLES2 does not support ``textureSize()``. You can get the size of a texture "
"the old fashioned way by passing in a uniform with the texture size yourself."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:189
msgid "Built in variables and render modes"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:191
msgid ""
"Godot also provides many built-in variables and render modes. Some cannot be "
"supported in GLES2. Below is a list of built-in variables and render modes "
"that, when written to, will have no effect or could even cause issues when "
"using the GLES2 backend."
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:196
msgid "Variable / Render Mode"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:198
msgid "``ensure_correct_normals``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:200
msgid "``INSTANCE_ID``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:202
msgid "``DEPTH``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:204
msgid "``ANISOTROPY``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:206
msgid "``ANISOTROPY_FLOW``"
msgstr ""

#: ../../docs/tutorials/misc/gles2_gles3_differences.rst:208
msgid "``SSS_STRENGTH``"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:7
msgid "Instancing with signals"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:9
msgid ""
"Signals provide a way to decouple game objects, allowing you to avoid "
"forcing a fixed arrangement of nodes. One sign that a signal might be called "
"for is when you find yourself using ``get_parent()``. Referring directly to "
"a node's parent means that you can't easily move that node to another "
"location in the scene tree. This can be especially problematic when you are "
"instancing objects at runtime and may want to place them in an arbitrary "
"location in the running scene tree."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:16
msgid "Below we'll consider an example of such a situation: firing bullets."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:19
msgid "Shooting example"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:21
msgid ""
"Consider a player character that can rotate and shoot towards the mouse. "
"Every time the mouse button is clicked, we create an instance of the bullet "
"at the player's location. See :ref:`doc_instancing` for details."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:25
msgid ""
"We'll use an ``Area2D`` for the bullet, which moves in a straight line at a "
"given velocity:"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:50
msgid ""
"However, if the bullets are added as children of the player, then they will "
"remain \"attached\" to the player as it rotates:"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:55
msgid ""
"Instead, we need the bullets to be independent of the player's movement - "
"once fired, they should continue traveling in a straight line and the player "
"can no longer affect them. Instead of being added to the scene tree as a "
"child of the player, it makes more sense to add the bullet as a child of the "
"\"main\" game scene, which may be the player's parent or even further up the "
"tree."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:61
msgid "You could do this by adding the bullet to the main scene directly:"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:74
msgid ""
"However, this will lead to a different problem. Now if you try to test your "
"\"Player\" scene independently, it will crash on shooting, because there is "
"no parent node to access. This makes it a lot harder to test your player "
"code independently and also means that if you decide to change your main "
"scene's node structure, the player's parent may no longer be the appropriate "
"node to receive the bullets."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:81
msgid ""
"The solution to this is to use a signal to \"emit\" the bullets from the "
"player. The player then has no need to \"know\" what happens to the bullets "
"after that - whatever node is connected to the signal can \"receive\" the "
"bullets and take the appropriate action to spawn them."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:86
msgid "Here is the code for the player using signals to emit the bullet:"
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:131
msgid ""
"In the main scene, we then connect the player's signal (it will appear in "
"the \"Node\" tab)."
msgstr ""

#: ../../docs/tutorials/misc/instancing_with_signals.rst:155
msgid ""
"Now the bullets will maintain their own movement independent of the player's "
"rotation:"
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:4
#, fuzzy
msgid "State design pattern"
msgstr "אותות"

#: ../../docs/tutorials/misc/state_design_pattern.rst:9
msgid ""
"Scripting a game can be difficult when there are many states that need to "
"handled, but only one script can be attached to a node at a time. Instead of "
"creating a state machine within the player's control script, it would make "
"development simpler if the states were separated out into different classes."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:14
msgid ""
"There are many ways to implement a state machine with Godot, and some other "
"methods are below:"
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:16
msgid ""
"The player can have a child node for each state, which are called when "
"utilized."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:17
msgid "Enums can be used in conjunction with a match statement."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:18
msgid ""
"The state scripts themselves could be swapped out from a node dynamically at "
"run-time."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:20
msgid ""
"This tutorial will focus only on adding and removing nodes which have a "
"state script attached. Each state script will be an implementation of a "
"different state."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:24
msgid ""
"There is a great resource explaining the concept of the state design pattern "
"here: https://gameprogrammingpatterns.com/state.html"
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:28
#, fuzzy
msgid "Script setup"
msgstr "נתיב"

#: ../../docs/tutorials/misc/state_design_pattern.rst:30
msgid ""
"The feature of inheritance is useful for getting started with this design "
"principle. A class should be created that describes the base features of the "
"player. For now, a player will be limited to two actions: **move left**, "
"**move right**. This means there will be two states: **idle** and **run**."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:35
msgid "Below is the generic state, from which all other states will inherit."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:66
msgid ""
"A few notes on the above script. First, this implementation uses a "
"``setup(change_state, animated_sprite, persistent_state)`` method to assign "
"references. These references will be instantiated in the parent of this "
"state. This helps with something in programming known as *cohesion*. The "
"state of the player does not want the responsibility of creating these "
"variables, but does want to be able to use them. However, this does make the "
"state *coupled* to the state's parent. This means that the state is highly "
"reliant on whether it has a parent which contains these variables. So, "
"remember that *coupling* and *cohesion* are important concepts when it comes "
"to code management."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:75
msgid ""
"See the following page for more details on cohesion and coupling: https://"
"courses.cs.washington.edu/courses/cse403/96sp/coupling-cohesion.html"
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:78
msgid ""
"Second, there are some methods in the script for moving, but no "
"implementation. The state script just uses ``pass`` to show that it will not "
"execute any instructions when the methods are called. This is important."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:81
msgid ""
"Third, the ``_physics_process(delta)`` method is actually implemented here. "
"This allows the states to have a default ``_physics_process(delta)`` "
"implementation where ``velocity`` is used to move the player. The way that "
"the states can modify the movement of the player is to use the ``velocity`` "
"variable defined in their base class."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:85
msgid ""
"Finally, this script is actually being designated as a class named "
"``State``. This makes refactoring the code easier, since the file path from "
"using the ``load()`` and ``preload()`` functions in godot will not be needed."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:88
msgid ""
"So, now that there is a base state, the two states discussed earlier can be "
"implemented."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:154
msgid ""
"The since the ``Run`` and ``Idle`` states extend from ``State`` which "
"extends ``Node2D``, the function ``_physics_process(delta)`` is called from "
"the **bottom-up** meaning ``Run`` and ``Idle`` will call their "
"implementation of ``_physics_process(delta)``, then ``State`` will call its "
"implementation, then ``Node2D`` will call its own implementation and so on. "
"This may seem strange, but it is only relevant for predefined functions such "
"as ``_ready()``, ``_process(delta)``, etc. Custom functions use the normal "
"inheritance rules of overriding the base implementation."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:161
msgid ""
"There is a round-about method for obtaining a state instance. A state "
"factory can be used."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:184
msgid ""
"This will look for states in a dictionary and return the state if found."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:186
msgid ""
"Now that all the states are defined with their own scripts, it is time to "
"figure out how those references that passed to them will be instantiated. "
"Since these references will not change it makes sense to call this new "
"script ``persistent_state.gd``."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:229
msgid ""
"The ``persistent_state.gd`` script contains code for detecting input. This "
"was to make the tutorial simple, but it is not usually best practice to do "
"this."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:235
msgid ""
"This tutorial made an assumption that the node it would be attached to "
"contained a child node which is an :ref:`AnimatedSprite "
"<class_AnimatedSprite>`. There is also the assumption that this :ref:"
"`AnimatedSprite <class_AnimatedSprite>` has at least two animations, the "
"idle and run animations. Also, the top-level node is assumed to be a :ref:"
"`KinematicBody2D <class_KinematicBody2D>`."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:242
msgid ""
"The zip file of the llama used in this tutorial is :download:`here <files/"
"llama.zip>`. The source was from `piskel_llama <https://www.piskelapp.com/p/"
"agxzfnBpc2tlbC1hcHByEwsSBlBpc2tlbBiAgICfx5ygCQw/edit>`_, but I couldn't find "
"the original creator information on that page though... There is also a good "
"tutorial for sprite animation already. See :ref:`2D Sprite Animation "
"<doc_2d_sprite_animation>`."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:247
msgid ""
"So, the only script that must be attached is ``persistent_state.gd``, which  "
"should be attached to the top node of the player, which is a :ref:"
"`KinematicBody2D <class_KinematicBody2D>`."
msgstr ""

#: ../../docs/tutorials/misc/state_design_pattern.rst:254
msgid ""
"Now the player has utilized the state design pattern to implement its two "
"different states. The nice part of this pattern is that if one wanted to add "
"another state, then it would involve creating another class that need only "
"focus on itself and how it changes to another state. Each state is "
"functionally separated and instantiated dynamically."
msgstr ""

#: ../../docs/tutorials/debug/index.rst:2
msgid "Debug"
msgstr "ניפוי שגיאות"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:4
msgid "Overview of debugging tools"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:6
msgid ""
"This guide will give you an overview of the available debugging tools in the "
"engine."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:9
msgid ""
"Godot comes with a powerful debugger and profilers to track down bugs, "
"inspect your game at runtime, monitor essential metrics, and measure "
"performances. It also offers options to visualize collision boxes and "
"navigation polygons in the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:14
msgid ""
"Finally, you have options to debug the game running on a remote device and "
"to reload changes to your scenes or your code while the game is running."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:18
#, fuzzy
msgid "Debugger Panel"
msgstr "ניפוי שגיאות"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:20
msgid ""
"Many of Godot's debugging tools are part of the Debugger panel, which you "
"can find information about in :ref:`doc_debugger_panel`."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:24
msgid "Debug menu options"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:26
msgid ""
"There are a few common debug options you can toggle on or off when running "
"your game in the editor, which can help you in debugging your game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:29
msgid "You can find these options in the **Debug** editor menu."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:33
msgid "Here are the descriptions of the options:"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:36
msgid "Deploy with Remote Debug"
msgstr "הטעמה עם ניפוי שגיאות מרחוק"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:38
msgid ""
"When exporting and deploying, the resulting executable will attempt to "
"connect to the IP of your computer for debugging."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:42
msgid "Small Deploy with Network FS"
msgstr "הטמעה קטנה עם מערכת קבצים ברשת"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:44
msgid ""
"This option speeds up testing for games with a large footprint on remote "
"devices."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:46
msgid ""
"When **Small Deploy with Network FS** is on, instead of exporting the full "
"game, deploying the game builds a minimal executable. The editor then "
"provides files from the project over the network."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:50
msgid ""
"Also, on Android, the game is deployed using the USB cable to speed up "
"deployment."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:53
msgid "Visible Collision Shapes"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:55
msgid ""
"This option makes collision shapes and raycast nodes visible in the running "
"game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:58
msgid "Visible Navigation"
msgstr "ניווט גלוי"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:60
msgid "Navigation meshes and polygons will be visible on the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:63
msgid "Sync Scene Changes"
msgstr "סנכרון השינויים בסצנה"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:65
msgid ""
"With this option, any change you make to a scene in the editor at runtime "
"appears instantly. When used remotely on a device, this is more efficient "
"with the network filesystem."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:70
msgid "Sync Script Changes"
msgstr "סנכרון השינויים בסקריפט"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:72
msgid ""
"Any script that is saved will be reloaded on the running game. When used "
"remotely on a device, this is more efficient with the network filesystem."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:76
msgid "Script editor debug tools and options"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:78
msgid ""
"The script editor has its own set of debug tools for use with breakpoints "
"and two options. The breakpoint tools can also be found in the **Debugger** "
"tab of the debugger."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:84
msgid ""
"The **Break** button causes a break in the script like a breakpoint would. "
"**Continue** makes the game continue after pausing at a breakpoint. **Step "
"Over** goes to the next line of code, and **Step Into** goes into a function "
"if possible. Otherwise, it does the same thing as **Step Over**."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:89
msgid ""
"The **Keep Debugger Open** option keeps the debugger open after a scene has "
"been closed. And the **Debug with External Editor** option lets you debug "
"your game with an external editor."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:94
msgid "Debug project settings"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:96
msgid ""
"In the project settings, there is a **Debug** category with three "
"subcategories which control different things."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:100
#, fuzzy
msgid "Settings"
msgstr "מתחילים"

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:102
msgid ""
"These are some general settings such as printing the current FPS to the "
"**Output** panel, the maximum amount of functions when profiling and others."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:109
msgid ""
"These settings allow you to toggle specific GDScript warnings, such as for "
"unused variables. You can also turn off warnings completely."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:113
msgid "Shapes"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:115
msgid ""
"Shapes are where you can adjust the color of shapes that only appear for "
"debugging purposes, such as collision and navigation shapes."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:119
msgid "Remote in scene dock"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:121
msgid ""
"When running a game in the editor two options appear at the top of the "
"**Scene** dock, **Remote** and **Local**. While using **Remote** you can "
"inspect or change the nodes' parameters in the running project."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:127
msgid ""
"Some editor settings related to debugging can be found inside the **Editor "
"Settings**, under the **Network > Debug** and **Debugger** sections."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:4
#, fuzzy
msgid "Debugger panel"
msgstr "ניפוי שגיאות"

#: ../../docs/tutorials/debug/debugger_panel.rst:6
msgid ""
"Many of Godot's debugging tools, including the debugger, can be found in the "
"debugger panel at the bottom of the screen. Click on **Debugger** to open it."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:11
msgid ""
"The debugger panel is split into several tabs, each focusing on a specific "
"task."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:16
msgid ""
"The Debugger tab opens automatically when the GDScript compiler reaches a "
"breakpoint in your code."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:19
msgid ""
"It gives you a `stack trace <https://en.wikipedia.org/wiki/Stack_trace>`__, "
"information about the state of the object, and buttons to control the "
"program's execution."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:23
msgid "You can use the buttons in the top-right corner to:"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:25
msgid ""
"Skip all breakpoints. That way, you can save breakpoints for future "
"debugging sessions."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:27
msgid "Copy the current error message."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:28
msgid ""
"**Step Into** the code. This button takes you to the next line of code, and "
"if it's a function, it steps line-by-line through the function."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:30
msgid ""
"**Step Over** the code. This button goes to the next line of code, but it "
"doesn't step line-by-line through functions."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:32
msgid "**Break**. This button pauses the game's execution."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:33
msgid "**Continue**. This button resumes the game after a breakpoint or pause."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:36
msgid "Errors"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:38
msgid ""
"This is where error and warning messages are printed while running the game."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:40
msgid ""
"You can disable specific warnings in **Project Settings > Debug > GDScript**."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:43
msgid "Profiler"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:45
msgid ""
"The debugger comes with three profilers for your processor, network "
"operations, and video memory."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:48
msgid ""
"The profiler is used to show why individual frames take as long as they do "
"to process and render."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:51
msgid ""
"Unlike other debugging tools, the profiler does not start automatically. It "
"can be started at any time during gameplay by pressing the start button. You "
"can even start the profiler before opening the game to profile startup "
"performance. It can also be started and stopped while the game is running "
"without losing information from when it was last running. The information it "
"records won't go away unless you click clear, or close the game, reopen it "
"and start the profiler again."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:59
msgid ""
"After starting and stopping the profiler, you should see things being kept "
"track of on the left and a graph on the right. The items listed on the left "
"are everything that contributes to frame time, and they should each have a "
"value for time and calls for the current frame you are looking at."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:64
msgid ""
"The frame number in the top right tells you which frame you are currently "
"looking at. You can change this by using the up or down arrows, typing in "
"the frame number, or clicking on the graph."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:68
msgid ""
"If you want to add something to your graph or think it looks too cluttered, "
"you can check and uncheck the box next to an item to add or remove it from "
"the graph."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:73
msgid "Network Profiler"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:75
msgid ""
"The Network Profiler contains a list of all the nodes that communicate over "
"the multiplayer API and, for each one, some counters on the amount of "
"incoming and outgoing network interactions. It also features a bandwidth "
"meter that displays the total bandwidth usage at any given moment."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:81
msgid "Monitors"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:83
msgid ""
"The monitors are graphs of several aspects of the game while its running "
"such as FPS, memory usage, how many nodes are in a scene and more. All "
"monitors keep track of stats automatically, so even if one monitor isn't "
"open while the game is running, you can open it later and see how the values "
"changed."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:89
msgid "Video RAM"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:91
msgid ""
"The **Video RAM** tab shows the video RAM usage of the game while it is "
"running. It provides a list of every resource using video RAM by resource "
"path, the type of resource it is, what format it is in, and how much Video "
"RAM that resource is using. There is also a total video RAM usage number at "
"the top right of the panel."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:99
msgid "Misc"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:101
msgid ""
"The **Misc** tab contains tools to identify the control nodes you are "
"clicking at runtime:"
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:104
msgid ""
"**Clicked Control** tells you where the clicked node is in the scene tree."
msgstr ""

#: ../../docs/tutorials/debug/debugger_panel.rst:105
msgid "**Clicked Control Type** tells you the type of the node you clicked is."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:4
msgid "Complying with Licenses"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:7
msgid "What are licenses?"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:9
msgid ""
"Godot is created and distributed under the `MIT License <https://opensource."
"org/licenses/MIT>`_. It doesn't have a sole owner either, as every "
"contributor that submits code to the project does it under this same license "
"and keeps ownership of the contribution."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:11
msgid ""
"The license is the legal requirement for you (or your company) to use and "
"distribute the software (and derivative projects, including games made with "
"it). Your game or project can have a different license, but it still needs "
"to comply with the original one."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:17
msgid ""
"In the case of the MIT license, the only requirement is to include the "
"license text somewhere in your game or derivative project."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:19
msgid "This text reads as follows:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:22
msgid "This game uses Godot Engine, available under the following license:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:24
msgid ""
"Copyright (c) 2007-2020 Juan Linietsky, Ariel Manzur. Copyright (c) "
"2014-2020 Godot Engine contributors."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:27
#: ../../docs/tutorials/legal/complying_with_licenses.rst:88
msgid ""
"Permission is hereby granted, free of charge, to any person obtaining a copy "
"of this software and associated documentation files (the \"Software\"), to "
"deal in the Software without restriction, including without limitation the "
"rights to use, copy, modify, merge, publish, distribute, sublicense, and/or "
"sell copies of the Software, and to permit persons to whom the Software is "
"furnished to do so, subject to the following conditions:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:29
#: ../../docs/tutorials/legal/complying_with_licenses.rst:90
msgid ""
"The above copyright notice and this permission notice shall be included in "
"all copies or substantial portions of the Software."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:31
#: ../../docs/tutorials/legal/complying_with_licenses.rst:92
msgid ""
"THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR "
"IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, "
"FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE "
"AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER "
"LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING "
"FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS "
"IN THE SOFTWARE."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:34
msgid ""
"Your games do not need to be under the same license. You are free to release "
"your Godot projects under any license and to create commercial games with "
"the engine."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:37
msgid "Inclusion"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:39
msgid ""
"The license does not specify how it has to be included, so anything is valid "
"as long as it can be displayed under some condition. These are the most "
"common approaches (only need to implement one of them, not all)."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:42
msgid "Credits screen"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:44
msgid ""
"Include the above license text somewhere in the credits screen. It can be at "
"the bottom after showing the rest of the credits. Most large studios use "
"this approach with open source licenses."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:47
#, fuzzy
msgid "Licenses screen"
msgstr "רישיון"

#: ../../docs/tutorials/legal/complying_with_licenses.rst:49
msgid ""
"Some games have a special menu (often in the settings) to display licenses."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:52
msgid "Output log"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:54
msgid ""
"Just printing the licensing text using a :ref:`print() "
"<class_@GDScript_method_print>` function may be enough on platforms where a "
"global output log is readable (as an example, mobile devices)."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:57
msgid "Accompanying file"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:59
msgid ""
"If the game is distributed on desktop operating systems, a file containing "
"the license can be added to the software that is installed to the user PC."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:62
msgid "Printed manual"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:64
msgid ""
"If the game includes printed manuals, license text can be included there."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:67
msgid "Third Party licenses"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:69
msgid ""
"Godot itself contains software written by `third parties <https://github.com/"
"godotengine/godot/blob/master/COPYRIGHT.txt>`_. Most of it does not require "
"license inclusion, but some do. Make sure to do it if you are using them. "
"Here is a list of which ones require it:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:72
msgid "FreeType"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:74
msgid ""
"Godot uses `FreeType <https://www.freetype.org/>`_ to render fonts. Its "
"license requires attribution, so the following text must be included "
"together with the Godot license:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:77
msgid ""
"Portions of this software are copyright © <year> The FreeType Project (www."
"freetype.org).  All rights reserved."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:81
msgid "ENet"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:83
msgid ""
"If the project being created is a multiplayer game using the `ENet <http://"
"enet.bespin.org/>`_ driver, ENet has similar licensing terms as Godot"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:86
msgid "Copyright (c) 2002-2016 Lee Salzman"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:95
msgid "MBedTLS"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:97
msgid ""
"If the project is done with Godot 3.1 or above and it utilizes SSL (usually "
"through HTTP requests), the `MBedTLS <https://tls.mbed.org>`_ Apache license "
"needs to be complied by including the following text:"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:100
msgid "MBedTLS is Copyright (C) 2013-2019 ARM"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:102
msgid ""
"Licensed under the Apache License, Version 2.0 (the \"License\"); you may "
"not use this file except in compliance with the License. You may obtain a "
"copy of the License at"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:104
msgid "http://www.apache.org/licenses/LICENSE-2.0"
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:106
msgid ""
"Unless required by applicable law or agreed to in writing, software "
"distributed under the License is distributed on an \"AS IS\" BASIS, WITHOUT "
"WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the "
"License for the specific language governing permissions and limitations "
"under the License."
msgstr ""

#: ../../docs/tutorials/legal/complying_with_licenses.rst:108
msgid ""
"Keep in mind that Godot 2.x and 3.0 use `OpenSSL <https://www.openssl.org>`_ "
"instead."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:4
msgid "Getting the source"
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:9
msgid "Downloading the Godot source code"
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:11
msgid ""
"Before :ref:`getting into the SCons build system "
"<doc_introduction_to_the_buildsystem>` and compiling Godot, you need to "
"actually download the Godot source code."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:14
msgid ""
"The source code is available on `GitHub <https://github.com/godotengine/"
"godot>`__ and while you can manually download it via the website, in general "
"you want to do it via the ``git`` version control system."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:18
msgid ""
"If you are compiling in order to make contributions or pull requests, you "
"should follow the instructions from the :ref:`Pull Request workflow "
"<doc_pr_workflow>`."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:21
msgid ""
"If you don't know much about ``git`` yet, there are a great number of "
"`tutorials <https://git-scm.com/book>`__ available on various websites."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:24
msgid ""
"In general, you need to install ``git`` and/or one of the various GUI "
"clients."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:26
msgid ""
"Afterwards, to get the latest development version of the Godot source code "
"(the unstable ``master`` branch), you can use ``git clone``."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:29
msgid ""
"If you are using the ``git`` command line client, this is done by entering "
"the following in a terminal:"
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:36
msgid ""
"For any stable release, visit the `release page <https://github.com/"
"godotengine/godot/releases>`__ and click on the link for the release you "
"want. You can then download and extract the source from the download link on "
"the page."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:40
msgid ""
"There are also generally branches besides ``master`` for each major version."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:42
msgid ""
"After downloading the Godot source code, you can :ref:`continue to compiling "
"Godot <doc_introduction_to_the_buildsystem>`."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:4
msgid "Introduction to the buildsystem"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:9
msgid "SCons"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:11
msgid ""
"Godot uses `SCons <https://www.scons.org/>`__ to build. We love it, we are "
"not changing it for anything else. We are not even sure other build systems "
"are up to the task of building Godot. We constantly get requests to move the "
"build system to CMake, or Visual Studio, but this is not going to happen. "
"There are many reasons why we have chosen SCons over other alternatives, for "
"example:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:18
msgid ""
"Godot can be compiled for a dozen different platforms: all PC platforms, all "
"mobile platforms, many consoles, and WebAssembly."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:20
msgid ""
"Developers often need to compile for several of the platforms **at the same "
"time**, or even different targets of the same platform. They can't afford "
"reconfiguring and rebuilding the project each time. SCons can do this with "
"no sweat, without breaking the builds."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:24
msgid ""
"SCons will *never* break a build no matter how many changes, configurations, "
"additions, removals etc. You have more chances to die struck by lightning "
"than needing to clean and rebuild in SCons."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:27
msgid ""
"Godot build process is not simple. Several files are generated by code "
"(binders), others are parsed (shaders), and others need to offer "
"customization (plugins). This requires complex logic which is easier to "
"write in an actual programming language (like Python) rather than using a "
"mostly macro-based language only meant for building."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:32
msgid ""
"Godot build process makes heavy use of cross-compiling tools. Each platform "
"has a specific detection process, and all these must be handled as specific "
"cases with special code written for each."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:36
msgid ""
"So, please try to keep an open mind and get at least a little familiar with "
"it if you are planning to build Godot yourself."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:42
msgid ""
"Please refer to the documentation for :ref:`doc_compiling_for_android`, :ref:"
"`doc_compiling_for_ios`, :ref:`doc_compiling_for_osx`, :ref:"
"`doc_compiling_for_uwp`, :ref:`doc_compiling_for_web`, :ref:"
"`doc_compiling_for_windows` and :ref:`doc_compiling_for_x11`."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:47
msgid ""
"Note that for **Windows/Visual Studio**, you need to use ``x86_x64 Cross "
"Tools Command Prompt for VS 2017`` or similar, depending on your install, "
"instead of the standard Windows command prompt to enter the commands below."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:52
msgid "Platform selection"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:54
msgid ""
"Godot's build system will begin by detecting the platforms it can build for. "
"If not detected, the platform will simply not appear on the list of "
"available platforms. The build requirements for each platform are described "
"in the rest of this tutorial section."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:59
msgid ""
"SCons is invoked by just calling ``scons``. If no platform is specified, "
"SCons will detect the target platform automatically based on the host "
"platform. It will then start building for the target platform right away."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:63
msgid "To list the available target platforms, use ``scons platform=list``::"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:77
msgid ""
"To build for a platform (for example, x11), run with the ``platform=`` (or "
"``p=`` to make it short) argument:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:84
msgid ""
"This will start the build process, which will take a while. If you want "
"SCons to build faster, use the ``-j <cores>`` parameter to specify how many "
"cores will be used for the build. Or leave it using one core, so you can use "
"your computer for something else :)"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:89
msgid "Example for using 4 cores:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:96
msgid "Resulting binary"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:98
msgid ""
"The resulting binaries will be placed in the ``bin/`` subdirectory, "
"generally with this naming convention::"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:103
msgid "For the previous build attempt, the result would look like this::"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:108
msgid ""
"This means that the binary is for X11, is not optimized, has tools (the "
"whole editor) compiled in, and is meant for 64 bits."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:111
msgid "A Windows binary with the same configuration will look like this:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:118
msgid ""
"Copy that binary to any location you like, as it contains the project "
"manager, editor and all means to execute the game. However, it lacks the "
"data to export it to the different platforms. For that the export templates "
"are needed (which can be either downloaded from `godotengine.org <https://"
"godotengine.org/>`__, or you can build them yourself)."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:124
msgid ""
"Aside from that, there are a few standard options that can be set in all "
"build targets, and which will be explained below."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:132
msgid ""
"Tools are enabled by default in all PC targets (Linux, Windows, macOS), "
"disabled for everything else. Disabling tools produces a binary that can run "
"projects but that does not include the editor or the project manager."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:144
msgid "Target"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:146
msgid "Target controls optimization and debug flags. Each mode means:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:148
msgid ""
"**debug**: Build with C++ debugging symbols, runtime checks (performs checks "
"and reports error) and none to little optimization."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:150
msgid ""
"**release_debug**: Build without C++ debugging symbols and optimization, but "
"keep the runtime checks (performs checks and reports errors). Official "
"editor binaries use this configuration."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:153
msgid ""
"**release**: Build without symbols, with optimization and with little to no "
"runtime checks. This target can't be used together with ``tools=yes``, as "
"the editor requires some debug functionality and run-time checks to run."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:162
msgid ""
"This flag appends the ``.debug`` suffix (for debug), or ``.tools`` (for "
"debug with tools enabled). When optimization is enabled (release), it "
"appends the ``.opt`` suffix."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:167
msgid "Bits"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:169
msgid ""
"Bits is meant to control the CPU or OS version intended to run the binaries. "
"It is focused mostly on desktop platforms and ignored everywhere else."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:173
msgid "**32**: Build binaries for 32-bit platforms."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:174
msgid "**64**: Build binaries for 64-bit platforms."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:175
msgid "**default**: Build for the architecture that matches the host platform."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:181
msgid ""
"This flag appends ``.32`` or ``.64`` suffixes to resulting binaries when "
"relevant. If ``bits=default`` is used, the suffix will match the detected "
"architecture."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:188
#, fuzzy
msgid "Custom modules"
msgstr "אותות"

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:190
msgid ""
"It's possible to compile modules residing outside of Godot's directory tree, "
"along with the built-in modules."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:193
msgid ""
"A ``custom_modules`` build option can be passed to the command line before "
"compiling. The option represents a comma-separated list of directory paths "
"containing a collection of independent C++ modules that can be seen as C++ "
"packages, just like the built-in ``modules/`` directory."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:198
msgid ""
"For instance, it's possible to provide both relative, absolute, and user "
"directory paths containing such modules:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:207
msgid ""
"If there's any custom module with the exact directory name as a built-in "
"module, the engine will only compile the custom one. This logic can be used "
"to override built-in module implementations."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:213
#, fuzzy
msgid ":ref:`doc_custom_modules_in_c++`"
msgstr "Android"

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:216
msgid "Other build options"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:218
msgid ""
"There are several other build options that you can use to configure the way "
"Godot should be built (compiler, debug options, etc.) as well as the "
"features to include/disable."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:222
msgid ""
"Check the output of ``scons --help`` for details about each option for the "
"version you are willing to compile."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:228
msgid "Overriding the build options"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:231
#, fuzzy
msgid "Using a file"
msgstr "יצירת תוכן"

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:233
msgid ""
"The default ``custom.py`` file can be created at the root of the Godot "
"Engine source to initialize any SCons build options passed via the command "
"line:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:245
msgid ""
"You can also disable some of the builtin modules before compiling, saving "
"some time it takes to build the engine, see :ref:`doc_optimizing_for_size` "
"page for more details."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:248
msgid ""
"Another custom file can be specified explicitly with the ``profile`` command "
"line option, both overriding the default build configuration:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:255
msgid ""
"Build options set from the file can be overridden by the command line "
"options."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:258
msgid "It's also possible to override the options conditionally:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:273
msgid "Using the SCONSFLAGS"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:275
msgid ""
"``SCONSFLAGS`` is an environment variable which is used by the SCons to set "
"the options automatically without having to supply them via the command line."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:278
msgid ""
"For instance, you may want to build Godot in parallel with the "
"aforementioned ``-j`` option for all the future builds:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:297
msgid ""
"Official export templates are downloaded from the Godot Engine site: "
"`godotengine.org <https://godotengine.org/>`__. However, you might want to "
"build them yourself (in case you want newer ones, you are using custom "
"modules, or simply don't trust your own shadow)."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:302
msgid ""
"If you download the official export templates package and unzip it, you will "
"notice that most files are optimized binaries or packages for each platform:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:325
msgid ""
"To create those yourself, follow the instructions detailed for each platform "
"in this same tutorial section. Each platform explains how to create its own "
"template."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:329
msgid ""
"The ``version.txt`` file should contain the corresponding Godot version "
"identifier. This file is used to install export templates in a version-"
"specific directory to avoid conflicts. For instance, if you are building "
"export templates for Godot 3.1.1, ``version.txt`` should contain ``3.1.1."
"stable`` on the first line (and nothing else). This version identifier is "
"based on the ``major``, ``minor``, ``patch`` (if present) and ``status`` "
"lines of the `version.py file in the Godot Git repository <https://github."
"com/godotengine/godot/blob/master/version.py>`__."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:337
msgid ""
"If you are developing for multiple platforms, macOS is definitely the most "
"convenient host platform for cross-compilation, since you can cross-compile "
"for almost every target (except for UWP). Linux and Windows come in second "
"place, but Linux has the advantage of being the easier platform to set this "
"up."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:4
msgid "Compiling for Windows"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:11
msgid "For compiling under Windows, the following is required:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:13
msgid ""
"`Visual Studio Community <https://www.visualstudio.com/vs/community/>`_, "
"version 2017 or later. VS 2019 is recommended. **Make sure to read "
"\"Installing Visual Studio caveats\" below or you will have to run/download "
"the installer again.**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:17
msgid ""
"`MinGW-w64 <http://mingw-w64.org/>`__ with GCC can be used as an alternative "
"to Visual Studio. Be sure to install/configure it to use the ``posix`` "
"thread model."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:19
msgid "`Python 3.5+ <https://www.python.org/downloads/windows/>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:20
msgid ""
"`SCons 3.0 <https://www.scons.org/>`_ build system. If using Visual Studio "
"2019, you need at least SCons 3.1.1."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:22
msgid ""
"*Optional* - `yasm <https://yasm.tortall.net/>`_ (for WebM SIMD "
"optimizations)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:24
msgid ""
"If you have `Scoop <https://scoop.sh/>`_ installed, you can easily install "
"MinGW and other dependencies using the following command::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:29
msgid ""
"If you have `MSYS2 <https://www.msys2.org/>`_ installed, you can easily "
"install MinGW and other dependencies using the following command::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:37
msgid ""
"For each MSYS2 MinGW subsystem, you should then run `pip install scons` in "
"its shell."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:40
#: ../../docs/development/compiling/compiling_for_x11.rst:29
#: ../../docs/development/compiling/compiling_for_osx.rst:27
#: ../../docs/development/compiling/compiling_for_android.rst:38
#: ../../docs/development/compiling/compiling_for_ios.rst:15
#: ../../docs/development/compiling/compiling_for_uwp.rst:29
#: ../../docs/development/compiling/compiling_for_web.rst:17
msgid ""
"For a general overview of SCons usage for Godot, see :ref:"
"`doc_introduction_to_the_buildsystem`."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:44
msgid "Setting up Python"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:46
msgid ""
"First you need to install Python 3.5 or newer. Make sure to enable the "
"option to add Python to the ``PATH`` in the Python installer. The SCons "
"installer should then detect and use the existing Python installation."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:51
msgid "Setting up SCons"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:53
msgid "To install SCons open the command prompt and run the following command."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:55
msgid "``python -m pip install scons``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:57
msgid ""
"To check whether you have installed Python and SCons correctly, you can type "
"``python --version`` and ``scons --version`` into a command prompt (``cmd."
"exe``)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:61
msgid ""
"If the commands above don't work, make sure to add Python to your ``PATH`` "
"environment variable after installing it, then check again. You can do so by "
"running the Python installer again and enabling the option to add Python to "
"the ``PATH``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:69
msgid "Installing Visual Studio caveats"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:71
msgid ""
"If installing Visual Studio 2017 or 2019, make sure to enable **C++** in the "
"list of workflows to install."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:74
msgid ""
"If installing Visual Studio 2015, make sure to run a **Custom** installation "
"instead of **Typical** and select **C++** as a language there."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:77
msgid ""
"If you've already made the mistake of installing Visual Studio without C++ "
"support, run the installer again; it should present you a **Modify** button. "
"Running the installer from *Add/Remove Programs* will only give you a "
"**Repair** option, which won't let you install C++ tools."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:83
msgid "Downloading Godot's source"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:85
msgid ""
"Godot's source code is `hosted on GitHub <https://github.com/godotengine/"
"godot>`_. Downloading it (cloning) using `Git <https://git-scm.com/>`_ is "
"recommended."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:88
msgid ""
"The tutorial will assume from now on that you placed the source code in ``C:"
"\\godot``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:95
msgid "Selecting a compiler"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:97
msgid ""
"SCons will automatically find and use an existing Visual Studio "
"installation. If you do not have Visual Studio installed, it will attempt to "
"use MinGW instead. If you already have Visual Studio installed and want to "
"use MinGW, pass ``use_mingw=yes`` to the SCons command line."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:102
msgid ""
"During development, using the Visual Studio compiler is usually a better "
"idea, as it links the Godot binary much faster than MinGW. However, MinGW "
"can produce more optimized binaries using link-time optimization (see "
"below), making it a better choice for production use."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:108
msgid "Running SCons"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:110
msgid ""
"After opening a command prompt, change to the root directory of the engine "
"source code (using ``cd``) and type::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:115
msgid "You can specify a number of CPU threads to use to speed up the build::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:119
msgid ""
"In general, it is OK to have at least as many threads compiling Godot as you "
"have cores in your CPU, if not one or two more. Feel free to add the ``-j`` "
"option to any SCons command you see below."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:123
msgid ""
"When compiling with multiple CPU threads, SCons may warn about pywin32 being "
"missing. You can safely ignore this warning."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:126
msgid ""
"If all goes well, the resulting binary executable will be placed in ``C:"
"\\godot\\bin\\`` with the name ``godot.windows.tools.32.exe`` or ``godot."
"windows.tools.64.exe``. By default, SCons will build a binary matching your "
"CPU architecture, but this can be overridden using ``bits=64`` or "
"``bits=32``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:132
msgid ""
"This executable file contains the whole engine and runs without any "
"dependencies. Running it will bring up the Project Manager."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:135
#: ../../docs/development/compiling/compiling_for_x11.rst:117
msgid ""
"If you are compiling Godot for production use, then you can make the final "
"executable smaller and faster by adding the SCons option "
"``target=release_debug``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:139
msgid ""
"If you are compiling Godot with MinGW, you can make the binary even smaller "
"and faster by adding the SCons option ``use_lto=yes``. As link-time "
"optimization is a memory-intensive process, this will require about 3 GB of "
"available RAM while compiling."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:144
#: ../../docs/development/compiling/compiling_for_x11.rst:126
#: ../../docs/development/compiling/compiling_for_osx.rst:42
msgid ""
"If you want to use separate editor settings for your own Godot builds and "
"official releases, you can enable :ref:`doc_data_paths_self_contained_mode` "
"by creating a file called ``._sc_`` or ``_sc_`` in the ``bin/`` folder."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:150
msgid "Development in Visual Studio or other IDEs"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:152
msgid ""
"For most projects, using only scripting is enough but when development in C+"
"+ is needed, for creating modules or extending the engine, working with an "
"IDE is usually desirable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:156
msgid ""
"You can create a Visual Studio solution via SCons by running SCons with the "
"``vsproj=yes`` parameter, like this::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:161
msgid ""
"You will be able to open Godot's source in a Visual Studio solution now, and "
"able to build Godot using Visual Studio's **Build** button."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:164
msgid ""
"If you need to edit the build commands, they are located in \"Godot\" "
"project settings, NMAKE sheet. SCons is called at the end of the commands. "
"If you make a mistake, copy the command from one of the other build "
"configurations (debug, release_debug, release) or architectures (Win32/x64); "
"they are equivalent."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:171
msgid "Cross-compiling for Windows from other operating systems"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:173
msgid ""
"If you are a Linux or macOS user, you need to install `MinGW-w64 <https://"
"mingw-w64.org/doku.php>`__, which typically comes in 32-bit and 64-bit "
"variants. The package names may differ based on your distribution, here are "
"some known ones:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:179
#: ../../docs/development/compiling/compiling_for_x11.rst:40
msgid "**Arch Linux**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:179
msgid "Install `mingw-w64-gcc from the AUR`_."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:181
#: ../../docs/development/compiling/compiling_for_x11.rst:45
msgid "**Debian** / **Ubuntu**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:185
#: ../../docs/development/compiling/compiling_for_x11.rst:50
msgid "**Fedora**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:190
msgid "**macOS**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:194
#: ../../docs/development/compiling/compiling_for_x11.rst:67
msgid "**Mageia**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:202
msgid ""
"Before attempting the compilation, SCons will check for the following "
"binaries in your ``PATH`` environment variable::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:208
msgid ""
"If the binaries are not located in the ``PATH`` (e.g. ``/usr/bin``), you can "
"define the following environment variables to give a hint to the build "
"system::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:215
msgid ""
"To make sure you are doing things correctly, executing the following in the "
"shell should result in a working compiler (the version output may differ "
"based on your system)::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:225
msgid ""
"Cross-compiling from some Ubuntu versions may lead to `this bug <https://"
"github.com/godotengine/godot/issues/9258>`_, due to a default configuration "
"lacking support for POSIX threading."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:229
msgid ""
"You can change that configuration following those instructions, for 64-bit::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:237
msgid "And for 32-bit::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:245
msgid "Creating Windows export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:247
msgid ""
"Windows export templates are created by compiling Godot without the editor, "
"with the following flags::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:255
msgid ""
"If you plan on replacing the standard export templates, copy these to the "
"following location, replacing ``<version>`` with the version identifier "
"(such as ``3.1.1.stable`` or ``3.2.dev``)::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:261
msgid "With the following names::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:268
msgid ""
"However, if you are using custom modules or custom engine code, you may "
"instead want to configure your binaries as custom export templates here:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:274
msgid ""
"You don't need to copy them in this case, just reference the resulting files "
"in the ``bin\\`` directory of your Godot source folder, so the next time you "
"build, you will automatically have the custom templates referenced."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:4
msgid "Compiling for X11 (Linux, \\*BSD)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:11
msgid ""
"For compiling under Linux or other Unix variants, the following is required:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:14
msgid "GCC 7+ or Clang 6+."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:15
msgid "Python 3.5+."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:16
msgid ""
"SCons 3.0+ build system. If your distribution uses Python 2 by default, or "
"you are using a version of SCons prior to 3.1.2, you will need to change the "
"version of Python that SCons uses by changing the shebang (the first line) "
"of the SCons script file to ``#! /usr/bin/python3``. Use the command ``which "
"scons`` to find the location of the SCons script file."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:21
msgid "pkg-config (used to detect the dependencies below)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:22
msgid "X11, Xcursor, Xinerama, Xi and XRandR development libraries."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:23
msgid "MesaGL development libraries."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:24
msgid "ALSA development libraries."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:25
msgid "PulseAudio development libraries."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:26
msgid "*Optional* - libudev (build with ``udev=yes``)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:27
msgid "*Optional* - yasm (for WebM SIMD optimizations)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:33
msgid "Distro-specific one-liners"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:35
msgid "**Alpine Linux**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:56
msgid "**FreeBSD**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:62
msgid "**Gentoo**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:73
msgid "**OpenBSD**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:77
msgid "**openSUSE**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:82
msgid "**Solus**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:91
msgid ""
"Start a terminal, go to the root dir of the engine source code and type:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:97
msgid ""
"A good rule of thumb for the ``-j`` (*jobs*) flag, is to have at least as "
"many threads compiling Godot as you have cores in your CPU, if not one or "
"two more. Feel free to add the ``-j`` option to any SCons command you see "
"below."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:101
msgid ""
"If all goes well, the resulting binary executable will be placed in the \"bin"
"\" subdirectory. This executable file contains the whole engine and runs "
"without any dependencies. Executing it will bring up the project manager."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:108
msgid "If you wish to compile using Clang rather than GCC, use this command:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:114
msgid ""
"Using Clang appears to be a requirement for OpenBSD, otherwise fonts would "
"not build."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:121
msgid ""
"If you are compiling Godot with GCC, you can make the binary even smaller "
"and faster by adding the SCons option ``use_lto=yes``. As link-time "
"optimization is a memory-intensive process, this will require about 3 GB of "
"available RAM while compiling."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:132
#: ../../docs/development/compiling/compiling_for_osx.rst:57
msgid "Compiling a headless/server build"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:134
#: ../../docs/development/compiling/compiling_for_osx.rst:59
msgid ""
"To compile a *headless* build which provides editor functionality to export "
"projects in an automated manner, use::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:139
#: ../../docs/development/compiling/compiling_for_osx.rst:64
msgid ""
"To compile a *server* build which is optimized to run dedicated game "
"servers, use::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:145
#: ../../docs/development/compiling/compiling_for_web.rst:21
msgid "Building export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:147
msgid ""
"Linux binaries usually won't run on distributions that are older than the "
"distribution they were built on. If you wish to distribute binaries that "
"work on most distributions, you should build them on an old distribution "
"such as Ubuntu 16.04. You can use a virtual machine or a container to set up "
"a suitable build environment."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:155
msgid ""
"To build X11 (Linux, \\*BSD) export templates, run the build system with the "
"following parameters:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:158
msgid "(32 bits)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:165
msgid "(64 bits)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:172
msgid ""
"Note that cross-compiling for the opposite bits (64/32) as your host "
"platform is not always straight-forward and might need a chroot environment."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:175
msgid ""
"To create standard export templates, the resulting files must be copied to:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:181
msgid ""
"and named like this (even for \\*BSD which is seen as \"Linux X11\" by "
"Godot):"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:190
msgid ""
"However, if you are writing your custom modules or custom C++ code, you "
"might instead want to configure your binaries as custom export templates "
"here:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:196
msgid ""
"You don't even need to copy them, you can just reference the resulting files "
"in the ``bin/`` directory of your Godot source folder, so the next time you "
"build, you automatically have the custom templates referenced."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:201
msgid "Using Clang and LLD for faster development"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:203
msgid ""
"You can also use Clang and LLD to build Godot. This has two upsides compared "
"to the default GCC + GNU ld setup:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:206
msgid ""
"LLD links Godot significantly faster compared to GNU ld or gold. This leads "
"to faster iteration times."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:208
msgid "Clang tends to give more useful error messages compared to GCC."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:210
msgid ""
"To do so, install Clang and the ``lld`` package from your distribution's "
"package manager then use the following SCons command::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:215
msgid ""
"It's still recommended to use GCC for production builds as they can be "
"compiled using link-time optimization, making the resulting binaries smaller "
"and faster."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:4
msgid "Compiling for macOS"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:11
msgid "For compiling under macOS, the following is required:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:13
msgid "`Python 3.5+ <https://www.python.org>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:14
msgid "`SCons 3.0+ <https://www.scons.org>`_ build system."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:15
msgid ""
"`Xcode <https://apps.apple.com/us/app/xcode/id497799835>`_ (or the more "
"lightweight Command Line Tools for Xcode)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:17
msgid ""
"*Optional* - `yasm <https://yasm.tortall.net/>`_ (for WebM SIMD "
"optimizations)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:19
msgid ""
"If you have `Homebrew <https://brew.sh/>`_ installed, you can easily install "
"SCons and yasm using the following command::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:24
msgid ""
"Installing Homebrew will also fetch the Command Line Tools for Xcode "
"automatically if you don't have them already."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:33
msgid ""
"Start a terminal, go to the root directory of the engine source code and "
"type::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:37
msgid ""
"If all goes well, the resulting binary executable will be placed in the "
"``bin/`` subdirectory. This executable file contains the whole engine and "
"runs without any dependencies. Executing it will bring up the project "
"manager."
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:47
msgid ""
"To create an ``.app`` bundle like in the official builds, you need to use "
"the template located in ``misc/dist/osx_tools.app``. Typically, for an "
"optimized editor binary built with ``scons p=osx target=release_debug``::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:70
msgid "Cross-compiling for macOS from Linux"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:72
msgid ""
"It is possible to compile for macOS in a Linux environment (and maybe also "
"in Windows using the Windows Subsystem for Linux). For that, you'll need to "
"install `OSXCross <https://github.com/tpoechtrager/osxcross>`__ to be able "
"to use macOS as a target. First, follow the instructions to install it:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:77
msgid ""
"Clone the `OSXCross repository <https://github.com/tpoechtrager/osxcross>`__ "
"somewhere on your machine (or download a ZIP file and extract it somewhere), "
"e.g.::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:83
msgid ""
"Follow the instructions to package the SDK: https://github.com/tpoechtrager/"
"osxcross#packaging-the-sdk"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:85
msgid ""
"Follow the instructions to install OSXCross: https://github.com/tpoechtrager/"
"osxcross#installation"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:88
msgid ""
"After that, you will need to define the ``OSXCROSS_ROOT`` as the path to the "
"OSXCross installation (the same place where you cloned the repository/"
"extracted the zip), e.g.::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:94
msgid "Now you can compile with SCons like you normally would::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:98
msgid ""
"If you have an OSXCross SDK version different from the one expected by the "
"SCons buildsystem, you can specify a custom one with the ``osxcross_sdk`` "
"argument::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:4
msgid "Compiling for Android"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:9
msgid "Note"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:11
msgid ""
"In most cases, using the built-in deployer and export templates is good "
"enough. Compiling the Android APK manually is mostly useful for custom "
"builds or custom packages for the deployer."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:15
msgid ""
"Also, you still need to follow the steps mentioned in the :ref:"
"`doc_exporting_for_android` tutorial before attempting to build a custom "
"export template."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:22
msgid "For compiling under Windows, Linux or macOS, the following is required:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:24
msgid "`Python 3.5+ <https://www.python.org/downloads/>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:25
msgid "`SCons 3.0+ <https://scons.org/pages/download.html>`_ build system."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:26
msgid ""
"`Android SDK <https://developer.android.com/studio/#command-tools>`_ "
"(command-line tools are sufficient)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:29
msgid ""
"Required SDK components will be automatically installed by Gradle (except "
"the NDK)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:31
msgid ""
"`Android NDK <https://developer.android.com/ndk/downloads/>`_ r17 or later."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:32
msgid "Gradle (will be downloaded and installed automatically if missing)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:33
msgid "JDK 8 (either OpenJDK or Oracle JDK)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:35
msgid "JDK 9 or later are not currently supported."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:36
msgid ""
"You can download a build from `ojdkbuild <https://github.com/ojdkbuild/"
"ojdkbuild>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:44
msgid "Setting up the buildsystem"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:46
msgid ""
"Set the environment variable ``ANDROID_HOME`` to point to the Android SDK. "
"If you downloaded the Android command-line tools, this would be the folder "
"where you extracted the contents of the ZIP archive. Later on, ``gradlew`` "
"will install necessary SDK components in this folder. However, you need to "
"accept the SDK component licenses before they can be downloaded by Gradle. "
"This can be done by running the following command from the root of the SDK "
"directory, then answering all the prompts with ``y``:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:60
msgid ""
"Set the environment variable ``ANDROID_NDK_ROOT`` to point to the Android "
"NDK. You also might need to set the variable ``ANDROID_NDK_HOME`` to the "
"same path, especially if you are using custom Android modules, since some "
"Gradle plugins rely on the NDK and use this variable to determine its "
"location."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:66
msgid ""
"To set those environment variables on Windows, press :kbd:`Windows + R`, "
"type \"control system\", then click on **Advanced system settings** in the "
"left pane, then click on **Environment variables** on the window that "
"appears."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:71
msgid ""
"To set those environment variables on Linux or macOS, use ``export "
"ANDROID_HOME=/path/to/android-sdk`` and ``export ANDROID_NDK_ROOT=/path/to/"
"android-ndk`` where ``/path/to/android-sdk`` and ``/path/to/android-ndk`` "
"point to the root of the SDK and NDK directories."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:78
msgid "Building the export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:80
msgid ""
"Godot needs two export templates for Android: the optimized \"release\" "
"template (``android_release.apk``) and the debug template (``android_debug."
"apk``). As Google will require all APKs to include ARMv8 (64-bit) libraries "
"starting from August 2019, the commands below will build an APK containing "
"both ARMv7 and ARMv8 libraries."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:86
msgid ""
"Compiling the standard export templates is done by calling SCons from the "
"Godot root directory with the following arguments:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:89
msgid ""
"Release template (used when exporting with **Debugging Enabled** unchecked)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:102
msgid "The resulting APK will be located at ``bin/android_release.apk``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:104
msgid "Debug template (used when exporting with **Debugging Enabled** checked)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:117
msgid "The resulting APK will be located at ``bin/android_debug.apk``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:120
msgid "Adding support for x86 devices"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:122
msgid ""
"If you also want to include support for x86 and x86-64 devices, run the "
"SCons command a third and fourth time with the ``android_arch=x86``, and "
"``android_arch=x86_64`` arguments before building the APK with Gradle. For "
"example, for the release template:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:140
msgid ""
"This will create a fat binary that works on all platforms. The final APK "
"size of exported projects will depend on the platforms you choose to support "
"when exporting; in other words, unused platforms will be removed from the "
"APK."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:146
#, fuzzy
msgid "Cleaning the generated export templates"
msgstr "יצירת תוכן"

#: ../../docs/development/compiling/compiling_for_android.rst:148
msgid ""
"You can use the following commands to remove the generated export templates:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:160
msgid "Using the export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:162
msgid ""
"Godot needs release and debug APKs that were compiled against the same "
"version/commit as the editor. If you are using official binaries for the "
"editor, make sure to install the matching export templates, or build your "
"own from the same version."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:167
msgid ""
"When exporting your game, Godot opens the APK, changes a few things inside "
"and adds your files."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:171
msgid "Installing the templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:173
msgid ""
"The newly-compiled templates (``android_debug.apk`` and ``android_release."
"apk``) must be copied to Godot's templates folder with their respective "
"names. The templates folder can be located in:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:177
msgid "Windows: ``%APPDATA%\\Godot\\templates\\<version>\\``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:178
msgid "Linux: ``$HOME/.local/share/godot/templates/<version>/``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:179
msgid "macOS: ``$HOME/Library/Application Support/Godot/templates/<version>/``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:181
msgid ""
"``<version>`` is of the form ``major.minor[.patch].status`` using values "
"from ``version.py`` in your Godot source repository (e.g. ``3.0.5.stable`` "
"or ``3.1.dev``). You also need to write this same version string to a "
"``version.txt`` file located next to your export templates."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:188
msgid ""
"However, if you are writing your custom modules or custom C++ code, you "
"might instead want to configure your APKs as custom export templates here:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:194
msgid ""
"You don't even need to copy them, you can just reference the resulting file "
"in the ``bin\\`` directory of your Godot source folder, so that the next "
"time you build you will automatically have the custom templates referenced."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:203
msgid "Platform doesn't appear in SCons"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:205
msgid ""
"Double-check that you've set both the ``ANDROID_HOME`` and "
"``ANDROID_NDK_ROOT`` environment variables. This is required for the "
"platform to appear in SCons' list of detected platforms. See :ref:`Setting "
"up the buildsystem <doc_android_setting_up_the_buildsystem>` for more "
"information."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:212
msgid "Application not installed"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:214
msgid ""
"Android might complain the application is not correctly installed. If so:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:217
msgid "Check that the debug keystore is properly generated."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:218
msgid "Check that the jarsigner executable is from JDK 8."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:220
msgid ""
"If it still fails, open a command line and run `logcat <https://developer."
"android.com/studio/command-line/logcat>`_:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:226
msgid ""
"Then check the output while the application is installed; the error message "
"should be presented there. Seek assistance if you can't figure it out."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:231
msgid "Application exits immediately"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:233
msgid ""
"If the application runs but exits immediately, this might be due to one of "
"the following reasons:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:236
msgid ""
"Make sure to use export templates that match your editor version; if you use "
"a new Godot version, you *have* to update the templates too."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:238
msgid ""
"``libgodot_android.so`` is not in ``libs/<android_arch>/`` where "
"``<android_arch>`` is the device's architecture."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:240
msgid ""
"The device's architecture does not match the exported one(s). Make sure your "
"templates were built for that device's architecture, and that the export "
"settings included support for that architecture."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:244
msgid "In any case, ``adb logcat`` should also show the cause of the error."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:4
msgid "Compiling for iOS"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:11
msgid ""
"SCons 3.0+ (you can install it via Homebrew or Macports, you should be able "
"to run ``scons`` in a terminal when installed)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:13
msgid ""
"Xcode 10.0 (or later) with the iOS (10.0) SDK and the command line tools."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:21
msgid "Open a Terminal, go to the root dir of the engine source code and type:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:27
msgid "for a debug build, or:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:33
msgid ""
"for a release build (check ``platform/iphone/detect.py`` for the compiler "
"flags used for each configuration)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:36
msgid "Alternatively, you can run"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:42
msgid "for a Simulator executable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:44
msgid ""
"For recent devices, Apple requires 64-bit versions of application binaries "
"when you are uploading to the Apple Store. The best way to provide these is "
"to create a bundle in which there are both 32-bit and 64-bit binaries, so "
"every device will be able to run the game."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:47
msgid ""
"It can be done in three steps: first compile the 32-bit version, then "
"compile the 64-bit version and then use ``lipo`` to bundle them into one "
"\"universal\" binary. All those steps can be performed with following "
"commands:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:58
msgid ""
"If you also want to provide a simulator build (reduces the chance of any "
"linker errors with dependencies), you'll need to build and lipo the "
"``x86_64`` architecture as well."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:72
msgid ""
"To run on a device or simulator, follow these instructions: :ref:"
"`doc_exporting_for_ios`."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:75
msgid ""
"Replace or add your executable to the Xcode project, and change the "
"\"executable name\" property on Info.plist accordingly if you use an "
"alternative build."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:4
msgid "Cross-compiling for iOS on Linux"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:8
msgid ""
"The procedure for this is somewhat complex and requires a lot of steps, but "
"once you have the environment properly configured it will be easy to compile "
"Godot for iOS anytime you want."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:13
msgid "Disclaimer"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:15
msgid ""
"While it is possible to compile for iOS on a Linux environment, Apple is "
"very restrictive about the tools to be used (especially hardware-wise), "
"allowing pretty much only their products to be used for development. So this "
"is **not official**. However, a `statement from Apple in 2010 <http://www."
"apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-"
"Guidelines.html>`__ says they relaxed some of the `App Store review "
"guidelines <https://developer.apple.com/app-store/review/guidelines/>`__ to "
"allow any tool to be used, as long as the resulting binary does not download "
"any code, which means it should be OK to use the procedure described here "
"and cross-compiling the binary."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:29
msgid ""
"`XCode with the iOS SDK <https://developer.apple.com/xcode/download>`__ (a "
"dmg image)"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:31
msgid ""
"`Clang >= 3.5 <http://clang.llvm.org>`__ for your development machine "
"installed and in the ``PATH``. It has to be version >= 3.5 to target "
"``arm64`` architecture."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:34
msgid ""
"`Fuse <https://github.com/libfuse/libfuse>`__ for mounting and umounting the "
"dmg image."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:36
msgid ""
"`darling-dmg <https://github.com/darlinghq/darling-dmg>`__, which needs to "
"be built from source. The procedure for that is explained below."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:40
msgid ""
"For building darling-dmg, you'll need the development packages of the "
"following libraries: fuse, icu, openssl, zlib, bzip2."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:43
msgid ""
"`cctools-port <https://github.com/tpoechtrager/cctools-port>`__ for the "
"needed build tools. The procedure for building is quite peculiar and is "
"described below."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:47
msgid "This also has some extra dependencies: automake, autogen, libtool."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:50
msgid "Configuring the environment"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:53
msgid "darling-dmg"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:55
msgid "Clone the repository on your machine:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:61
msgid "Build it:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:73
msgid "Preparing the SDK"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:75
msgid "Mount the XCode image:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:84
msgid "Extract the iOS SDK:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:93
msgid "Pack the SDK:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:101
msgid "Toolchain"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:103
msgid "Build cctools:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:111
msgid ""
"Copy the tools to a nicer place. Note that the SCons scripts for building "
"will look under ``usr/bin`` inside the directory you provide for the "
"toolchain binaries, so you must copy to such subdirectory, akin to the "
"following commands:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:121
msgid ""
"Now you should have the iOS toolchain binaries in ``/home/user/iostoolchain/"
"usr/bin``."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:125
msgid "Compiling Godot for iPhone"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:127
msgid ""
"Once you've done the above steps, you should keep two things in your "
"environment: the built toolchain and the iPhoneOS SDK directory. Those can "
"stay anywhere you want since you have to provide their paths to the SCons "
"build command."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:132
msgid ""
"For the iPhone platform to be detected, you need the ``OSXCROSS_IOS`` "
"environment variable defined to anything."
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:139
msgid ""
"Now you can compile for iPhone using SCons like the standard Godot way, with "
"some additional arguments to provide the correct paths:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:148
msgid "Producing fat binaries"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:150
msgid ""
"Apple requires a fat binary with both architectures (``armv7`` and "
"``arm64``) in a single file. To do this, use the ``arm-apple-darwin11-lipo`` "
"executable. The following example assumes you are in the root Godot source "
"directory:"
msgstr ""

#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:162
msgid "Then you will have iOS fat binaries in ``bin`` directory."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:4
msgid "Compiling for Universal Windows Platform"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:11
msgid "SCons 3.0+ (see :ref:`doc_compiling_for_windows` for more details)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:12
msgid ""
"Visual Studio 2017 or later. See :ref:`doc_compiling_for_windows` about the "
"caveats of installing it and the various prompts."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:14
msgid "Windows 10 SDK (can be selected in Visual Studio installation)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:15
msgid ""
"`ANGLE source <https://github.com/Microsoft/angle>`__. Use the ``ms_master`` "
"(default) branch. Keep it in a path without spaces to avoid problems."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:19
msgid ""
"The ANGLE repo by Microsoft has been discontinued and the ``ms_master`` "
"branch has been cleared out."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:22
msgid ""
"As a temporary workaround however, it is still possible to download an older "
"state of the source code via commit `c61d048 <https://github.com/microsoft/"
"angle/tree/c61d0488abd9663e0d4d2450db7345baa2c0dfb6>`__."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:26
msgid ""
"This page will eventually be updated in the future to reflect the new build "
"instructions."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:35
msgid ""
"You need to open a proper Visual Studio prompt for the target architecture "
"you want to build. Check :ref:`doc_compiling_for_windows` to see how these "
"prompts work."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:39
msgid ""
"There are three target architectures for UWP: x86 (32-bits), x64 (64-bits) "
"and ARM (32-bits). For the latter, you can run ``vcvarsall.bat`` with "
"``x86_arm`` or ``amd64_arm`` as argument to set the environment."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:43
msgid ""
"Set the ``ANGLE_SRC_PATH`` to the directory where you downloaded the ANGLE "
"source code. The build process will also build ANGLE to produce the required "
"DLLs for the selected architecture."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:47
msgid ""
"Once you're set, run the SCons command similarly to the other platforms::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:52
msgid "Creating UWP export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:54
msgid ""
"To export using the editor you need to properly build package the templates. "
"You need all three architectures with ``debug`` and ``release`` templates to "
"be able to export."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:58
msgid ""
"Open the command prompt for one architecture and run SCons twice (once for "
"each target)::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:64
msgid "Repeat for the other architectures."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:66
msgid ""
"In the end your ``bin`` folder will have the ``.exe`` binaries with a name "
"like ``godot.uwp.opt.debug.32.x86.exe`` (with variations for each target/"
"arch)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:70
msgid ""
"Copy one of these to ``misc/dist/uwp_template`` inside the Godot source "
"folder and rename the binary to ``godot.uwp.exe``. From the ANGLE source, "
"under ``winrt/10/src/Release_%arch%`` (where ``%arch%`` can be ``Win32``, "
"``x64`` or ``ARM``), get the ``libEGL.dll`` and the ``libGLESv2.dll``, "
"putting them along with the executable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:76
msgid ""
"Add the files in the ``uwp_template`` folder to a ZIP. Rename the resulting "
"Zip according to the target/architecture of the template::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:86
msgid ""
"Move those templates to the ``[versionstring]\\templates`` folder in Godot "
"settings path, where `versionstring` is the version of Godot you have "
"compiled the export templates for - e.g. `3.0.alpha` for the alpha version "
"of Godot 3. If you don't want to replace the templates, you can set the "
"\"Custom Package\" property in the export window."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:93
msgid "Running UWP apps with Visual Studio"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:95
msgid ""
"If you want to debug the UWP port or simply run your apps without packaging "
"and signing, you can deploy and launch them using Visual Studio. It might be "
"the easiest way if you are testing on a device such as a Windows Phone or an "
"Xbox One."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:100
msgid ""
"Within the ANGLE source folder, open ``templates`` and double-click the "
"``install.bat`` script file. This will install the Visual Studio project "
"templates for ANGLE apps."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:104
msgid ""
"If you have not built Godot yet, open the ``winrt/10/src/angle.sln`` "
"solution from the ANGLE source and build it to Release/Win32 target. You may "
"also need to build it for ARM if you plan to run on a device. You can also "
"use MSBuild if you're comfortable with the command line."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:109
msgid ""
"Create a new Windows App project using the \"App for OpenGL ES (Windows "
"Universal)\" project template, which can be found under the ``Visual C++/"
"Windows/Universal`` category."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:113
msgid ""
"This is a base project with the ANGLE dependencies already set up. However, "
"by default it picks the debug version of the DLLs which usually have poor "
"performance. So in the \"Binaries\" filter, click in each of the DLLs there "
"and in the \"Properties\" window and change the relative path from "
"``Debug_Win32`` to ``Release_Win32`` (or ``Release_ARM`` for devices)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:119
msgid ""
"In the same \"Binaries\" filter, select \"Add > Existing Item\" and point to "
"the Godot executable for UWP you have. In the \"Properties\" window, set "
"\"Content\" to ``True`` so it's included in the project."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:123
msgid ""
"Right-click the ``Package.appxmanifest`` file and select \"Open With... > "
"XML (Text) Editor\". In the ``Package/Applications/Application`` element, "
"replace the ``Executable`` attribute from ``$targetnametoken$.exe`` to "
"``godot.uwp.exe`` (or whatever your Godot executable is called). Also change "
"the ``EntryPoint`` attribute to ``GodotUWP.App``. This will ensure that the "
"Godot executable is correctly called when the app starts."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:130
msgid ""
"Create a folder (*not* a filter) called ``game`` in your Visual Studio "
"project folder and there you can put either a ``data.pck`` file or your "
"Godot project files. After that, make sure to include it all with the \"Add "
"> Existing Item\" command and set their \"Content\" property to ``True`` so "
"they're copied to the app."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:136
msgid ""
"To ease the workflow, you can open the \"Solution Properties\" and in the "
"\"Configuration\" section untick the \"Build\" option for the app. You still "
"have to build it at least once to generate some needed files, you can do so "
"by right-clicking the project (*not* the solution) in the \"Solution Explorer"
"\" and selecting \"Build\"."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:142
msgid ""
"Now you can just run the project and your app should open. You can also use "
"the \"Start Without Debugging\" option from the \"Debug\" menu (or press :"
"kbd:`Ctrl + F5`) to make it launch faster."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:4
msgid "Compiling for the Web"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:11
msgid "To compile export templates for the Web, the following is required:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:13
msgid "`Emscripten 1.39.0+ <https://emscripten.org>`__."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:14
msgid "`Python 3.5+ <https://www.python.org/>`__."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:15
msgid "`SCons 3.0+ <https://www.scons.org>`__ build system."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:23
msgid ""
"Before starting, confirm that the Emscripten configuration file exists and "
"specifies all settings correctly. This file is available as ``~/."
"emscripten`` on UNIX-like systems and ``%USERPROFILE%\\.emscripten`` on "
"Windows. It's usually written by the Emscripten SDK, e.g. when invoking "
"``emsdk activate latest``, or by your package manager. It's also created "
"when starting Emscripten's ``emcc`` program if the file doesn't exist."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:30
msgid ""
"On Windows, make sure to escape backslashes of paths within the Emscripten "
"configuration file as double backslashes ``\\\\`` or use Unix-style paths "
"with a single forward slash ``/``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:34
msgid ""
"Open a terminal and navigate to the root directory of the engine source "
"code. Then instruct SCons to build the JavaScript platform. Specify "
"``target`` as either ``release`` for a release build or ``release_debug`` "
"for a debug build::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:41
msgid ""
"By default, the :ref:`JavaScript singleton <doc_javascript_eval>` will be "
"built into the engine. Since ``eval()`` calls can be a security concern, the "
"``javascript_eval`` option can be used to build without the singleton::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:48
msgid ""
"The engine will now be compiled to WebAssembly by Emscripten. Once finished, "
"the resulting file will be placed in the ``bin`` subdirectory. Its name is "
"``godot.javascript.opt.zip`` for release or ``godot.javascript.opt.debug."
"zip`` for debug."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:53
msgid ""
"Finally, rename the zip archive to ``webassembly_release.zip`` for the "
"release template::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:58
msgid "And ``webassembly_debug.zip`` for the debug template::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:63
msgid "Building per asm.js translation or LLVM backend"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:65
msgid ""
"WebAssembly can be compiled in two ways: The default is to first compile to "
"asm.js, a highly optimizable subset of JavaScript, using Emscripten's "
"*fastcomp* fork of LLVM. This code is then translated to WebAssembly using a "
"tool called ``asm2wasm``. Emscripten automatically takes care of both "
"processes, we simply run SCons."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:71
msgid ""
"The other method uses LLVM's WebAssembly backend. This backend is available "
"starting with LLVM 8 or in development builds. Emscripten manages this "
"process as well, so we just invoke SCons."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:75
msgid ""
"In order to choose one of the two methods, the ``LLVM_ROOT`` variable in the "
"Emscripten configuration file is used. If it points to a directory "
"containing binaries of Emscripten's *fastcomp* fork of clang, ``asm2wasm`` "
"is used. This is the default in a normal Emscripten installation. Otherwise, "
"LLVM binaries built with the WebAssembly backend will be expected and the "
"LLVM's WebAssembly backend is used."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:4
msgid "Compiling with Mono"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:11
msgid "Mono 5.12.0 or greater"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:12
msgid "MSBuild"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:13
msgid "NuGet"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:14
msgid "**On Linux/macOS only:** pkg-config"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:16
msgid ""
"You may need to import necessary certificates for NuGet to perform HTTPS "
"requests."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:19
msgid ""
"The recommended method is to use **curl**'s CA (Certificate Autorities) "
"certificate bundle."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:21
msgid ""
"Run the following commands to download and import it. On Windows, you can "
"run it from the Mono command line prompt (or the regular prompt if you added "
"Mono's ``bin`` directory to your ``PATH`` environment variable)::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:29
msgid ""
"Alternatively, you can use the following command, though it's deprecated and "
"may not work correctly::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:34
msgid "Environment variables"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:36
msgid ""
"By default, SCons will try to find Mono in the Windows Registry on Windows "
"or via ``pkg-config`` on other platforms. You can specify a different "
"installation directory by passing the ``mono_prefix`` command-line option to "
"SCons; e.g. ``scons [...] mono_prefix=%ProgramFiles%/Mono``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:41
msgid ""
"This is the directory that contains the subdirectories ``include`` and "
"``lib``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:44
msgid "Enable the Mono module"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:46
msgid ""
"By default, the Mono module is disabled when building. To enable it, add the "
"option ``module_mono_enabled=yes`` to the SCons command line."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:50
msgid "Generate the glue"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:52
msgid ""
"Glue sources are the wrapper functions that will be called by managed "
"methods. These source files must be generated before building your final "
"binaries. In order to generate them, first, you must build a temporary Godot "
"binary with the options ``tools=yes`` and ``mono_glue=no``::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:59
msgid ""
"After the build finishes, you need to run the compiled executable with the "
"parameter ``--generate-mono-glue`` followed by the path to an output "
"directory. This path must be ``modules/mono/glue`` in the Godot directory::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:65
msgid ""
"This command will tell Godot to generate the file ``modules/mono/glue/"
"mono_glue.gen.cpp`` and the C# solution for the Godot API at ``modules/mono/"
"glue/Managed/Generated``. Once these files are generated, you can build "
"Godot for all the desired targets without having to repeat this process."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:70
msgid ""
"``<godot_binary>`` refers to the tools binary you compiled above with the "
"Mono module enabled. Its exact name will differ based on your system and "
"configuration, but should be of the form ``bin/godot.<platform>.tools.<bits>."
"mono``, e.g. ``bin/godot.x11.tools.64.mono`` or ``bin/godot.windows.tools.64."
"mono.exe``. Be especially aware of the **.mono** suffix! If you've "
"previously compiled Godot without Mono support, you might have similarly "
"named binaries without this suffix. These binaries can't be used to generate "
"the Mono glue."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:80
#: ../../docs/development/cpp/custom_godot_servers.rst:506
msgid "Notes"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:82
msgid ""
"**Do not build your final binaries with** ``mono_glue=no``. This disables C# "
"scripting. This option must be used only for the temporary binary that will "
"generate the glue. Godot will print a warning at startup if it was built "
"without the glue sources."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:86
msgid ""
"The glue sources must be regenerated every time the ClassDB-registered API "
"changes. That is, for example, when a new method is registered to the "
"scripting API or one of the parameters of such a method changes. Godot will "
"print an error at startup if there is an API mismatch between ClassDB and "
"the glue sources."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:94
msgid "Rebuild with Mono glue"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:96
msgid ""
"Once you have generated the Mono glue, you can build the final binary with "
"``mono_glue=yes``. This is the default value for ``mono_glue``, so you can "
"also omit it. To build a Mono-enabled editor::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:102
msgid "And Mono-enabled export templates::"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:106
msgid ""
"If everything went well, apart from the normal output, SCons should have "
"created the following files in the ``bin`` directory:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:109
msgid ""
"If you're not linking the Mono runtime statically, the build script will "
"place the Mono runtime shared library (``monosgen-2.0``) next to the Godot "
"binary in the output directory. Make sure to include this library when "
"distributing Godot. When targeting Android, no extra steps are required as "
"this library is automatically copied to ``#platform/android/java/libs`` and "
"Gradle takes care of the rest."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:115
msgid ""
"Unlike \"classical\" Godot builds, when building with the Mono module "
"enabled (and depending on the target platform), a data directory may be "
"created both for the editor and for export templates. This directory is "
"important for proper functioning and must be distributed together with "
"Godot. More details about this directory in :ref:`Data "
"directory<compiling_with_mono_data_directory>`."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:126
msgid "Example (Windows)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:143
msgid "Example (X11)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:162
msgid "Data directory"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:164
msgid ""
"The data directory is a dependency for Godot binaries built with the Mono "
"module enabled. It contains important files for the correct functioning of "
"Godot. It must be distributed together with the Godot executable."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:168
msgid ""
"The information below doesn't apply for Android, iOS and WASM, as there is "
"no data directory for these platforms."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:174
msgid ""
"The name of the data directory for an export template differs based on the "
"configuration it was built with. The format is ``data.mono.<platform>.<bits>."
"<target>``, e.g. ``data.mono.x11.32.release_debug`` or ``data.mono."
"windows.64.release``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:179
msgid ""
"This directory must be placed with its original name next to the Godot "
"export templates. When exporting a project, Godot will also copy this "
"directory with the game executable but the name will be changed to "
"``data_<APPNAME>``, where ``<APPNAME>`` is the application name as specified "
"in the project setting ``application/config/name``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:185
msgid ""
"In the case of macOS, where the export template is compressed as a ZIP "
"archive, the contents of the data directory can be placed in the following "
"locations inside the ZIP archive:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:190
#: ../../docs/development/compiling/compiling_with_mono.rst:212
msgid "``bin/data.mono.<platform>.<bits>.<target>/Mono/lib``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:190
msgid "``/osx_template.app/Contents/Frameworks/GodotSharp/Mono/lib``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:192
#: ../../docs/development/compiling/compiling_with_mono.rst:214
msgid "``bin/data.mono.<platform>.<bits>.<target>/Mono/etc``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:192
msgid "``/osx_template.app/Contents/Resources/GodotSharp/Mono/etc``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:198
msgid ""
"The name of the data directory for the Godot editor will always be "
"``GodotSharp``. The contents of this directory are the following:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:201
msgid "``Api``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:202
msgid "``Mono`` (optional)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:203
#, fuzzy
msgid "``Tools``"
msgstr "כלים"

#: ../../docs/development/compiling/compiling_with_mono.rst:205
msgid ""
"The ``Api`` subdirectory contains the Godot API assemblies. On macOS, if the "
"Godot editor is distributed as a bundle, the contents of the data directory "
"may be placed in the following locations:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:210
msgid "``bin/data.mono.<platform>.<bits>.<target>/Api``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:210
msgid "``<bundle_name>.app/Contents/Frameworks/GodotSharp/Api``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:212
msgid "``<bundle_name>.app/Contents/Frameworks/GodotSharp/Mono/lib``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:214
msgid "``<bundle_name>.app/Contents/Resources/GodotSharp/Mono/etc``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:216
msgid "``bin/data.mono.<platform>.<bits>.<target>/Tools``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:216
msgid "``<bundle_name>.app/Contents/Frameworks/GodotSharp/Tools``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:219
msgid ""
"The ``Mono`` subdirectory is optional. It will be needed when distributing "
"the editor, as issues can arise when the user-installed Mono version isn't "
"identical to the one the Godot editor was built with. Pass "
"``copy_mono_root=yes`` to SCons when building the editor in order to create "
"this folder and its contents."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:224
msgid ""
"The ``Tools`` subdirectory contains tools required by the editor, like the "
"``GodotTools`` assemblies and its dependencies."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:228
#, fuzzy
msgid "Building the Mono runtime"
msgstr "אנימציות"

#: ../../docs/development/compiling/compiling_with_mono.rst:230
msgid ""
"When building Godot for the desktop, you will likely use the pre-built Mono "
"runtime that is installed on your system. This likely won't be the case when "
"targeting other platforms like Android, iOS and WebAssembly. You will have "
"to build the Mono runtime yourself for those platforms."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:235
msgid ""
"We recommend using these `build scripts <https://github.com/godotengine/"
"godot-mono-builds>`_. They simplify this process but also include some "
"patches needed for proper functioning with Godot. See the README on the link "
"above for instructions on how to use the scripts."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:241
#, fuzzy
msgid "Targeting Android"
msgstr "אנימציות"

#: ../../docs/development/compiling/compiling_with_mono.rst:243
msgid ""
"Compiling the Android export templates with Mono is a bit simpler than it is "
"for the desktop platforms, as there are no additional steps required after "
"building. There is no need to worry about run-time dependencies like a data "
"directory or the shared library (when dynamically linking) as those are "
"automatically added to the Gradle project."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:249
msgid ""
"Once you've built Mono, you can proceed to build Godot with the instructions "
"described in this page and the :ref:`Compiling for "
"Android<doc_compiling_for_android>` page. Make sure to let SCons know about "
"the location of the Mono runtime you've just built, e.g.: ``scons [...] "
"mono_prefix=\"$HOME/mono-installs/android-armeabi-v7a-release\"`` (This path "
"may be different on your system)."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:257
#, fuzzy
msgid "Targeting iOS"
msgstr "אנימציות"

#: ../../docs/development/compiling/compiling_with_mono.rst:259
msgid ""
"Once you've built Mono, you can proceed to build Godot with the instructions "
"described in this page and the :ref:`Compiling for "
"iOS<doc_compiling_for_ios>` page. Make sure to let SCons know about the "
"location of the Mono runtime you've just built, e.g.: ``scons [...] "
"mono_prefix=\"$HOME/mono-installs/ios-arm64-release\"`` (This path may be "
"different on your system)."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:266
msgid ""
"After building Godot for each architecture, you will notice SCons has copied "
"the Mono libraries for each of them to the output directory:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:279
msgid ""
"The last three are only for iOS devices and are not available for the iOS "
"simulator."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:281
msgid ""
"These libraries must be put in universal (multi-architecture) \"fat\" files "
"to be distributed with the export templates."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:284
msgid ""
"The following bash script will create the \"fat\" libraries in the directory "
"``#bin/ios/iphone-mono-libs``:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:300
msgid ""
"The ``iphone-mono-libs`` folder must be distributed with the export "
"templates. The Godot editor will look for the libraries in ``<templates>/"
"iphone-mono-libs/lib<name>.iphone.fat.a``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:304
msgid "Targeting WebAssembly"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:306
msgid ""
"Building for WebAssembly currently involves the same process regardless of "
"whether the Mono module is enabled."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:308
msgid ""
"Once you've built Mono, you can proceed to build Godot with the instructions "
"described in this page and the :ref:`Compiling for the "
"Web<doc_compiling_for_web>` page. Make sure to let SCons know about the "
"location of the Mono runtime you've just built, e.g.: ``scons [...] "
"mono_prefix=\"$HOME/mono-installs/wasm-runtime-release\"`` (This path may be "
"different on your system)."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:316
msgid "Base Class Library"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:318
msgid ""
"The export templates must also include the BCL (Base Class Library) for each "
"target platform. Godot looks for the BCL folder at ``<templates>/bcl/"
"<target_platform>``, where ``<target_platform>`` is the same name passed to "
"the SCons ``platform`` option, e.g.: ``<templates>/bcl/windows``, "
"``<templates>/bcl/javascript``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:323
msgid "Alternatively, Godot will look for them in the following locations:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:326
msgid "``<templates>/bcl/monodroid``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:328
msgid "``<templates>/bcl/monotouch``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:330
msgid "WebAssembly"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:330
msgid "``<templates>/bcl/wasm``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:332
msgid "Linux and macOS"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:332
msgid "``<templates>/bcl/net_4_x``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:334
msgid "``<templates>/bcl/net_4_x_win``"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:337
msgid ""
"As of now, we're assuming the same BCL profile can be used for both Linux "
"and macOS, but this may change in the future as they're not guaranteed to be "
"the same (as is the case with the Windows BCL)."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:341
msgid ""
"If the target platform is the same as the platform of the Godot editor, then "
"the editor will use the BCL it's running on (``<data_folder>/Mono/lib/"
"mono/4.5``) if it cannot find the BCL in the export templates."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:346
msgid "AOT cross-compilers"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:348
msgid ""
"To perform ahead-of-time (AOT) compilation for other platforms, Godot needs "
"to have access to the Mono cross-compilers for that platform and "
"architecture."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:351
msgid ""
"Godot will look for the cross-compiler executable in the AOT compilers "
"folder. The location of this folder is ``<data_folder>/Tools/aot-compilers/"
"``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:354
msgid ""
"In order to build the cross-compilers we recommend using these `build "
"scripts <https://github.com/godotengine/godot-mono-builds>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:357
msgid ""
"After building them, copy the executable to the Godot AOT compilers "
"directory. The executable name is ``<triple>-mono-sgen``, e.g.: ``aarch64-"
"apple-darwin-mono-sgen``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:361
msgid "Command-line options"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:363
msgid ""
"The following is the list of command-line options available when building "
"with the Mono module:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:366
msgid "**module_mono_enabled**\\ =yes | **no**"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:368
msgid "Build Godot with the Mono module enabled."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:370
msgid "**mono_glue**\\ =\\ **yes** | no"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:372
msgid ""
"Whether to include the glue source files in the build and define "
"``MONO_GLUE_DISABLED`` as a preprocessor macro."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:375
msgid "**mono_prefix**\\ =path"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:377
msgid ""
"Path to the Mono installation directory for the target platform and "
"architecture."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:379
msgid "**xbuild_fallback**\\ =yes | **no**"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:381
msgid "Whether to fallback to xbuild if MSBuild is not available."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:383
msgid "**mono_static**\\ =yes | no"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:385
msgid "Whether to link the Mono runtime statically."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:386
msgid ""
"The default is **yes** for iOS and WASM, and **no** for other platforms."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:388
msgid "**copy_mono_root**\\ =yes | **no**"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:390
msgid ""
"Whether to copy the Mono framework assemblies and configuration files "
"required by the Godot editor."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:4
msgid "Optimizing a build for size"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:9
msgid "Rationale"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:11
msgid ""
"Sometimes, it is desired to optimize a build for size rather than speed. "
"This means not compiling unused functions from the engine, as well as using "
"specific compiler flags to aid on decreasing build size. Common situations "
"include creating builds for mobile and Web platforms."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:16
msgid ""
"This tutorial aims to give an overview on different methods to create a "
"smaller binary. Before continuing, it is recommended to read the previous "
"tutorials on compiling Godot for each platform."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:21
msgid "Disabling 3D"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:23
msgid ""
"For 2D games, having the whole 3D engine available usually makes no sense. "
"Because of this, there is a build flag to disable it:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:29
msgid ""
"Tools must be disabled in order to use this flag, as the editor is not "
"designed to operate without 3D support. Without it, the binary size can be "
"reduced by about 15%."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:34
msgid "Disabling advanced GUI nodes"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:36
msgid ""
"Most small games don't require complex GUI controls such as Tree, ItemList, "
"TextEditor or GraphEdit. They can be disabled using a build flag:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:44
msgid "Disabling unwanted modules"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:46
msgid ""
"A lot of Godot's functions are offered as modules. You can see a list of "
"modules with the following command:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:53
msgid ""
"The list of modules that can be disabled will appear, together with all "
"build options. If you are working on a simple 2D game, you could disable a "
"lot of them:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:61
msgid ""
"If this proves not to work for your use case, you should review the list of "
"modules and see which ones you actually still need for your game (e.g. you "
"might want to keep networking-related modules, regex support, or theora/webm "
"to play videos)."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:66
msgid ""
"Alternatively, you can supply a list of disabled modules by creating "
"``custom.py`` at the root of the source, with the contents similar to the "
"following:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:110
#, fuzzy
msgid ":ref:`doc_overriding_build_options`."
msgstr "Android"

#: ../../docs/development/compiling/optimizing_for_size.rst:113
msgid "Optimizing for size instead of speed"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:115
msgid ""
"Godot 3.1 onwards allows compiling using size optimizations (instead of "
"speed). To enable this, set the ``optimize`` flag to ``size``:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:122
msgid "Some platforms such as WebAssembly already use this mode by default."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:125
msgid "Compiling with link-time optimization"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:127
msgid ""
"Enabling link-time optimization produces more efficient binaries, both in "
"terms of performance and file size. It works by eliminating duplicate "
"template functions and unused code. It can currently be used with the GCC "
"and MSVC compilers:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:136
msgid ""
"Linking becomes much slower with this option, so it should be used only for "
"release builds."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:140
msgid "Stripping binaries"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:142
msgid ""
"If you build from source, remember to strip debug symbols from binaries:"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:149
msgid "Using UPX to compress binaries"
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:151
msgid ""
"If you are targeting desktop platforms, the `UPX <https://upx.github.io/>`_ "
"compressor can be used. This can reduce binary size considerably."
msgstr ""

#: ../../docs/development/compiling/optimizing_for_size.rst:155
msgid ""
"However, keep in mind that some antivirus programs may detect UPX-packed "
"binaries as a virus. Therefore, if you are releasing a commercial game, make "
"sure to sign your binaries or use a platform that will distribute them."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:4
msgid "Compiling with script encryption key"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:8
msgid ""
"The export dialog gives you the option to encrypt your scripts with an "
"256bit AES key, when releasing your game. This will make sure your scripts "
"are not stored in plain text and can not easily be ripped by some script "
"kiddie. Of course the key needs to be stored in the binary, but if it's "
"compiled, optimized and without symbols, it would take some effort to find "
"it."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:14
msgid ""
"For this to work, you need to build the export templates from source, with "
"that same key."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:20
msgid ""
"Generate a 256bit AES key in HEX. You can use the aes-256-cbc variant from "
"`this service <https://asecuritysite.com/encryption/keygen>`_."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:23
msgid "Alternatively, you can generate it yourself by using OpenSSL:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:29
msgid "This should output the following to ``godot.gdkey`` file:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:37
msgid ""
"You can generate the key without redirecting the output to a file, but that "
"way you can minimize the risk of exposing the key."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:40
msgid ""
"Set this key as environment variable in the console that you will use to "
"compile Godot, like this:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:52
msgid ""
"Compile Godot export templates and set them as custom export templates in "
"the export preset options."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:55
msgid "Set the encryption key in the ``Script`` tab of the export preset:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:59
msgid "Export the project. The game should run with encrypted scripts now."
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:62
msgid "Possible Errors"
msgstr ""

#: ../../docs/development/compiling/compiling_with_script_encryption_key.rst:64
msgid ""
"If you get an error like below, it means the key wasn't properly included in "
"your Godot build. Godot is encrypting the scripts during export, but can't "
"read them at runtime."
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:4
msgid "Introduction to Godot development"
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:6
msgid ""
"This page is meant to introduce the global organization of Godot Engine's "
"source code, and give useful tips for extending/fixing the engine on the C++ "
"side."
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:11
msgid "Architecture diagram"
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:13
msgid ""
"The following diagram describes the architecture used by Godot, from the "
"core components down to the abstracted drivers, via the scene structure and "
"the servers."
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:20
msgid "Debugging the editor with gdb"
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:22
msgid ""
"If you are writing or correcting bugs affecting Godot Engine's editor, "
"remember that the binary will by default run the project manager first, and "
"then only run the editor in another process once you've selected a project. "
"To launch a project directly, you need to run the editor by passing the ``-"
"e`` argument to Godot Engine's binary from within your project's folder. "
"Typically:"
msgstr ""

#: ../../docs/development/cpp/introduction_to_godot_development.rst:35
msgid "Or:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/index.rst:2
msgid "Configuring an IDE"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/index.rst:4
msgid ""
"We assume that you have already `cloned <https://github.com/godotengine/"
"godot>`_ and :ref:`compiled <toc-devel-compiling>` Godot."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/index.rst:7
msgid ""
"You can easily develop Godot with any text editor and by invoking ``scons`` "
"on the command line, but if you want to work with an IDE (Integrated "
"Development Environment), here are setup instructions for some popular ones:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/index.rst:24
msgid ""
"It is possible to use other IDEs, but their setup is not documented yet."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:4
#, fuzzy
msgid "Android Studio"
msgstr "Android"

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:6
msgid ""
"`Android Studio <https://developer.android.com/studio>`_ is a free "
"`JetBrains <https://www.jetbrains.com/>`_ IDE for Android development. It "
"has a feature-rich editor which supports Java and C/C++. It can be used to "
"work on Godot's core engine as well as the Android platform codebase."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:12
#: ../../docs/development/cpp/configuring_an_ide/clion.rst:10
#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:9
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:9
#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:12
#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:10
#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:10
msgid "Importing the project"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:14
msgid ""
"From the Android Studio's welcome window select **Open an existing Android "
"Studio project**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:21
#, fuzzy
msgid "Android Studio's welcome window."
msgstr "Android"

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:23
msgid ""
"Navigate to ``<Godot root directory>/platform/android/java`` and select the "
"``settings.gradle`` file."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:24
msgid "Android Studio will import and index the project."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:25
msgid ""
"To build the project, follow the :ref:`compiling instructions <toc-devel-"
"compiling>`."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/android_studio.rst:27
#: ../../docs/development/cpp/configuring_an_ide/clion.rst:43
#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:86
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:110
#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:67
#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:107
#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:109
#, fuzzy
msgid ""
"If you run into any issues, ask for help in one of `Godot's community "
"channels <https://godotengine.org/community>`__."
msgstr "ראה גם  `את דף הרישיון באתר גודוט <https://godotengine.org/license>`_."

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:4
msgid "CLion"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:6
msgid ""
"`CLion <https://www.jetbrains.com/clion/>`_ is a commercial `JetBrains "
"<https://www.jetbrains.com/>`_ IDE for C++."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:12
msgid ""
"CLion requires a ``CMakeLists.txt`` file as a project file, which is "
"problematic for Godot because it uses the SCons buildsystem instead of "
"CMake. However, there is a ``CMakeLists.txt`` configuration for :ref:"
"`Android Studio <doc_configuring_an_ide_android_studio>` which can also be "
"used by CLion."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:17
msgid ""
"From the CLion's welcome window choose the option to import an existing "
"project. If you've already opened another project, choose **File > Open** "
"from the top menu."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:20
msgid ""
"Navigate to ``<Godot root directory>/platform/android/java/lib`` (the "
"``CMakeLists.txt`` file is located there) and select it (but *not* the "
"``CMakeLists.txt`` file itself), then click **OK**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:27
msgid "The folder containing the ``CMakeLists.txt`` file."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:29
msgid ""
"If this popup window appears, select **This Window** to open the project:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:34
msgid ""
"Choose **Tools > CMake > Change Project Root** from the top menu and select "
"the Godot root folder."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/clion.rst:40
msgid ""
"You should be now be able to see all the project files. Autocomplete should "
"work once the project has finished indexing."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:4
msgid "Code::Blocks"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:6
msgid ""
"`Code::Blocks <https://codeblocks.org/>`_ is a free, open source, cross "
"platform IDE."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:9
#, fuzzy
msgid "Creating a new project"
msgstr "יצירת תוכן"

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:11
msgid ""
"From Code::Blocks' main screen, click **Create a new project** or select "
"**File > New > Project...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:17
msgid ""
"In the **New from template** window, from **Projects**, select **Empty "
"project**, and click **Go**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:23
msgid "Click Next, to pass the welcome to the new empty project wizard."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:29
msgid ""
"The project file should be created in the root of the cloned project folder. "
"To achieve this, first, ensure that the **Project title** is the same as the "
"folder name that Godot was cloned into. Unless you cloned the project into a "
"folder with a different name, this will be ``godot``."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:31
msgid ""
"Second, ensure that the **Folder to create project in** is the folder you "
"ran the Git clone command from, not the ``godot`` project folder. Confirm "
"that the **Resulting filename** field will create the project file in the "
"root of the cloned project folder."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:37
msgid ""
"The compiler and configuration settings are managed through **SCons** and "
"will be configured later. However, it's worth deselecting the **Create "
"\"Release\" configuration** option; so only a single build target is created "
"before clicking **Finish**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:44
msgid "Configuring the build"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:46
msgid ""
"The first step is to change the project properties. Right-click on the new "
"project and select **Properties...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:52
msgid ""
"Check the **This is a custom Makefile** property. Click OK to save the "
"changes."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:58
msgid ""
"The next step is to change the build options. Right-click on the new project "
"and select **Build Options...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:64
msgid ""
"Select the **\"Make\" commands** tab and remove all the existing commands "
"for all the build targets. For each build target enter the **SCons** command "
"for creating the desired build in the **Build project/target** field. The "
"minimum is ``scons``. For details on the **SCons** build options, see :ref:"
"`doc_introduction_to_the_buildsystem`. It's also useful to add the ``scons --"
"clean`` command in the **Clean project/target** field to the project's "
"default commmands."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:66
msgid ""
"If you're using Windows, all the commands need to be preceded with ``cmd /"
"c`` to iniitalize the command interpreter."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:76
#, fuzzy
msgid "Windows example:"
msgstr "וינדוס (Windows)"

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:82
msgid ""
"Code::Blocks should now be configured to build Godot; so either select "
"**Build > Build**, click the gear button, or press :kbd:`Ctrl + F9`."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:85
msgid "Configuring the run"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:87
msgid ""
"Once **SCons** has successfully built the desired target, reopen the project "
"**Properties...** and select the **Build targets** tab. In the **Output "
"filename** field, browse to the ``bin`` folder and select the compiled file."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:89
msgid ""
"Deselect the **Auto-generate filename prefix** and **Auto-generate filename "
"extension** options."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:95
msgid ""
"Code::Blocks should now be configured to run your compiled Godot executable; "
"so either select **Build > Run**, click the green arrow button, or press :"
"kbd:`Ctrl + F10`."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:97
msgid ""
"There are two additional points worth noting. First, if required, the "
"**Execution working dir** field can be used to test specific projects, by "
"setting it to the folder containing the ``project.godot`` file. Second, the "
"**Build targets** tab can be used to add and remove build targets for "
"working with and creating different builds."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:100
#, fuzzy
msgid "Adding files to the project"
msgstr "יצירת תוכן"

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:102
msgid ""
"To add all the Godot code files to the project, right-click on the new "
"project and select **Add files recursively...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:108
msgid ""
"It should automatically select the project folder; so simply click **Open**. "
"By default, all code files are included, so simply click **OK**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:115
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:91
msgid "Code style configuration"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:117
msgid ""
"Before editing any files, remember that all code needs to comply with the :"
"ref:`doc_code_style_guidelines`. One important difference with Godot is the "
"use of tabs for indents. Therefore, the key default editor setting that "
"needs to be changed in Code::Blocks is to enable tabs for indents. This "
"setting can be found by selecting **Settings > Editor**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:123
msgid ""
"Under **General Settings**, on the **Editor Settings** tab, under **Tab "
"Options** check **Use TAB character**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/code_blocks.rst:129
#, fuzzy
msgid ""
"That's it. You're ready to start contributing to Godot using the Code::"
"Blocks IDE. Remember to save the project file and the **Workspace**.  If you "
"run into any issues, ask for help in one of `Godot's community channels "
"<https://godotengine.org/community>`__."
msgstr "ראה גם  `את דף הרישיון באתר גודוט <https://godotengine.org/license>`_."

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:4
msgid "KDevelop"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:6
msgid ""
"`KDevelop <https://www.kdevelop.org>`_ is a free, open source IDE for all "
"desktop platforms."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:11
msgid "From the KDevelop's main screen select **Open Project**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:17
msgid "KDevelop's main screen."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:19
msgid "Navigate to the Godot root folder and select it."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:20
msgid ""
"On the next screen, choose **Custom Build System** for the **Project "
"Manager**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:26
msgid ""
"After the project has been imported, open the project configuration by right-"
"clicking on it in the **Projects** panel and selecting **Open Configuration.."
"** option."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:33
msgid ""
"Under **Language Support** open the **Includes/Imports** tab and add the "
"following paths:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:49
msgid "Apply the changes."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:50
msgid ""
"Under **Custom Build System** add a new build configuration with the "
"following settings:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:53
msgid "Build Directory"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:53
msgid "*blank*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:55
msgid "Enable"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:55
msgid "**True**"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:57
msgid "Executable"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:57
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:59
msgid "**scons**"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:59
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:61
#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:24
msgid ""
"See :ref:`doc_introduction_to_the_buildsystem` for a full list of arguments."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:66
msgid "Apply the changes and close the configuration window."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:69
#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:73
#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:30
#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:58
#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:72
#, fuzzy
msgid "Debugging the project"
msgstr "יצירת תוכן"

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:71
msgid "Select **Run > Configure Launches...** from the top menu."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:77
msgid "Click **Add** to create a new launch configuration."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/kdevelop.rst:78
msgid ""
"Select **Executable** option and specify the path to your executable located "
"in the ``<Godot root directory>/bin`` folder. The name depends on your build "
"configuration, e.g. ``godot.x11.tools.64`` for 64-bit X11 platform with "
"``tools`` enabled."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:4
msgid "Qt Creator"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:6
msgid ""
"`Qt Creator <https://doc.qt.io/qtcreator/index.html>`_ is a free, open "
"source IDE for all desktop platforms."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:11
msgid ""
"From the Qt Creator's main screen select **New Project > Import Project > "
"Import Existing Project**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:17
msgid "Under **Location** select the Godot root folder."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:23
msgid ""
"Next, you can choose which folders and files will be visible to the project. "
"While C/C++ files are added automatically, other extensions can be "
"potentially useful: ``*.py`` for buildsystem files, ``*.java`` for Android "
"platform development, ``*.mm`` for macOS platform development."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:32
msgid ""
"You can change this configuration later by right-clicking on your project "
"and selecting the **Edit Files...** option."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:40
msgid "Finish the import."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:41
msgid ""
"Open the ``project_name.includes`` file and add a line containing ``.`` to "
"it to correctly enable the code completion."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:48
msgid "From the left-side menu select **Projects** and open the **Build** tab."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:49
msgid "Delete the predefined ``make`` build step."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:55
msgid ""
"Click **Add Build Step > Custom Process Step** to add a new build step with "
"the following settings:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:68
msgid ""
"If the build fails with ``Could not start process \"scons\"``, it can mean "
"that ``scons`` is not in your ``PATH`` environment variable. In this case, "
"you'll have to specify the full path to the SCons binary."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:75
msgid "From the left-side menu select **Projects** and open the **Run** tab."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:76
msgid ""
"Under **Executable** specify the path to your executable located in the "
"``<Godot root directory>/bin`` folder. The name depends on your build "
"configuration, e.g. ``godot.x11.tools.64`` for 64-bit X11 platform with "
"``tools`` enabled. You can use ``%{buildDir}`` to reference the project "
"root, e.g: ``%{buildDir}/bin/godot.x11.opt.tools.64``."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:80
msgid ""
"If you want to run a specific project, specify its root folder under "
"**Working directory**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:81
msgid ""
"If you want to run the editor, add ``-e`` to the **Command line arguments** "
"field."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:87
#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:55
msgid ""
"To learn more about command line arguments, refer to the :ref:`command line "
"tutorial <doc_command_line_tutorial>`."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:93
msgid ""
"Developers must follow the project's :ref:`code style "
"<doc_code_style_guidelines>` and the IDE should help them follow it. By "
"default, Qt Creator uses spaces for indentation which doesn't match the "
"Godot code style guidelines. You can change this behavior by changing the "
"**Code Style** in **Options > C++**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/qt_creator.rst:102
msgid ""
"Click on **Edit** to change the current settings, then click on **Copy Built-"
"in Code Style** button to set a new code style. Set a name for it (e.g. "
"Godot) and change the Tab policy to be **Tabs Only**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:4
#, fuzzy
msgid "Visual Studio"
msgstr "Android"

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:6
msgid ""
"`Visual Studio Community <https://visualstudio.microsoft.com>`__ is a "
"Windows-only IDE by `Microsoft <https://microsoft.com>`_ that's free for non-"
"commercial use. It has many useful features, such as memory view, "
"performance view, source control and more."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:14
msgid ""
"Visual Studio requires a solution file to work on a project. While Godot "
"does not come with the solution file, it can be generated using SCons."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:17
msgid ""
"Navigate to the Godot root folder and open a Command Prompt or PowerShell "
"window."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:18
msgid "Run ``scons platform=windows vsproj=yes`` to generate the solution."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:19
msgid ""
"You can now open the project by double-clicking on the ``godot.sln`` in the "
"project root or by using the **Open a project or solution** option inside of "
"the Visual Studio."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:21
msgid "Use the **Build** top menu to build the project."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:23
msgid ""
"Visual Studio must be configured with the C++ package. It can be selected in "
"the intaller:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:32
msgid ""
"Visual Studio features a powerful debugger. This allows the user to examine "
"Godot's source code, stop at specific points in the code, inspect the "
"current execution context, and make live changes to the codebase."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:36
msgid ""
"You can launch the project with the debugger attached using the **Debug > "
"Start Debugging** option from the top menu. However, unless you want to "
"debug the project manager specifically, you'd need to configure debugging "
"options first. This is due to the fact that when the Godot project manager "
"opens a project, the initial process is terminated and the debugger gets "
"detached."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:41
msgid ""
"To configure the launch options to use with the debugger use **Project > "
"Properties** from the top menu:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:47
msgid ""
"Open the **Debugging** section and under **Command Arguments** add two new "
"arguments: the ``-e`` flag opens the editor instead of the project manager, "
"and the ``--path`` argument tells the executable to open the specified "
"project (must be provided as an *absolute* path to the project root, not the "
"``project.godot`` file)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:58
msgid ""
"Even if you start the project without a debugger attached it can still be "
"connected to the running process using **Debug > Attach to Process...** menu."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio.rst:61
msgid ""
"To check that everything is working, put a breakpoint in ``main.cpp`` and "
"press :kbd:`F5` to start debugging."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:6
msgid ""
"`Visual Studio Code <https://code.visualstudio.com>`_ is a free cross-"
"platform IDE by `Microsoft <https://microsoft.com>`_ (not to be confused "
"with :ref:`doc_configuring_an_ide_vs`)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:12
msgid ""
"Make sure the C/C++ extension is installed. You can find instructions in the "
"`official documentation <https://code.visualstudio.com/docs/languages/cpp>`_."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:14
msgid ""
"From the Visual Studio Code's main screen open the Godot root folder with "
"**File > Open Folder...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:16
msgid ""
"Press :kbd:`Ctrl + Shift + P` to open the command prompt window and enter "
"*Configure Task*."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:21
msgid "Select the **Create tasks.json file from template** option."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:26
msgid "Then select **Others**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:31
msgid ""
"Within the ``tasks.json`` file find the ``\"tasks\"`` array and add a new "
"section to it:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:52
msgid "An example of a filled out ``tasks.json``."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:54
msgid ""
"Arguments can be different based on your own setup and needs. See :ref:"
"`doc_introduction_to_the_buildsystem` for a full list of arguments."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:60
msgid ""
"To run and debug the project you need to create a new configuration in the "
"``launch.json`` file."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:62
msgid "Press :kbd:`Ctrl + Shift + D` to open the Run panel."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:63
msgid ""
"If ``launch.json`` file is missing you will be prompted to create a new one."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:68
msgid ""
"Select **C++ (GDB/LLDB)**. There may be another platform specific option "
"here. If selected, adjust the configuration example provided accordingly."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:70
msgid ""
"Within the ``launch.json`` file find the ``\"configurations\"`` array and "
"add a new section to it:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:102
msgid "An example of a filled out ``launch.json``."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/visual_studio_code.rst:104
msgid ""
"The name under ``program`` depends on your build configuration, e.g. ``godot."
"x11.tools.64`` for 64-bit X11 platform with ``tools`` enabled."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:4
msgid "Xcode"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:6
msgid ""
"`Xcode <https://developer.apple.com/xcode>`_ is a free macOS-only IDE. You "
"can download it from the Mac App Store."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:12
msgid ""
"From Xcode's main screen create a new project using the **Other > External "
"Build System** template."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:18
msgid ""
"Open your build targets from the **Targets** section and select the **Info** "
"tab."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:19
#, fuzzy
msgid "Fill out the form with the following settings:"
msgstr "התיעוד העיקרי בשביל האתר מסודר לפי הסעיפים הבאים:"

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:22
msgid "Build Tool"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:22
msgid "A full path to the **scons** executable, e.g. **/usr/local/bin/scons**"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:26
msgid "Directory"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:26
msgid "A full path to the Godot root folder"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:33
msgid ""
"Add a Command Line Tool target which will be used for indexing the project "
"by choosing **File > New > Target...**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:40
msgid "Select **OS X > Application > Command Line Tool**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:46
msgid ""
"Name it something so you know not to compile with this target (e.g. "
"``GodotXcodeIndex``)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:48
msgid ""
"For this target open the **Build Settings** tab and look for **Header Search "
"Paths**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:49
msgid ""
"Set **Header Search Paths** to the absolute path to the Godot root folder. "
"You need to include subdirectories as well. To achieve that, add two two "
"asterisks (``**``) to the end of the path, e.g. ``/Users/me/repos/godot-"
"source/**``."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:53
msgid ""
"Add the Godot source to the project by dragging and dropping it into the "
"project file browser."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:54
msgid "Uncheck **Create external build system project**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:60
msgid ""
"Next select **Create groups** for the **Added folders** option and check "
"*only* your command line indexing target in the **Add to targets** section."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:67
msgid "Xcode will now index the files. This may take a few minutes."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:68
msgid ""
"Once Xcode is done indexing, you should have jump-to-definition, "
"autocompletion, and full syntax highlighting."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:74
msgid ""
"To enable debugging support you need to edit the external build target's "
"build and run schemes."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:76
msgid "Open the scheme editor of the external build target."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:77
msgid "Locate the **Build > Post Actions** section."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:78
msgid "Add a new script run action"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:79
msgid ""
"Under **Provide build settings from** select your project. This allows to "
"reference the project directory within the script."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:81
msgid ""
"Create a script that will give the binary a name that Xcode can recognize, e."
"g.:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:91
msgid "Build the external build target."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:93
msgid "Open the scheme editor again and select **Run**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:99
msgid ""
"Set the **Executable** to the file you linked in your post-build action "
"script."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:100
msgid "Check **Debug executable**."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:101
msgid ""
"You can add two arguments on the **Arguments** tab: the ``-e`` flag opens "
"the editor instead of the project manager, and the ``--path`` argument tells "
"the executable to open the specified project (must be provided as an "
"*absolute* path to the project root, not the ``project.godot`` file)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide/xcode.rst:106
msgid ""
"To check that everything is working, put a breakpoint in ``platform/osx/"
"godot_main_osx.mm`` and run the project."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:4
msgid "Common engine methods and macros"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:6
msgid ""
"Godot's C++ codebase makes use of dozens of custom methods and macros which "
"are used in almost every file. This page is geared towards beginner "
"contributors, but it can also be useful for those writing custom C++ modules."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:11
msgid "Print text"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:31
msgid ""
"If you need to add placeholders in your messages, use format strings as "
"described below."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:35
msgid "Format a string"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:37
msgid ""
"The ``vformat()`` function returns a formatted :ref:`class_String`. It "
"behaves in a way similar to C's ``sprintf()``:"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:51
msgid ""
"In most cases, try to use ``vformat()`` instead of string concatenation as "
"it makes for more readable code."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:55
msgid "Convert an integer or float to a string"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:57
msgid "This is mainly useful when printing numbers directly."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:68
msgid "Internationalize a string"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:70
#, fuzzy
msgid "There are two types of internationalization in Godot's codebase:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:72
msgid ""
"``TTR()``: **Editor (\"tools\") translations** will only be processed in the "
"editor. If an user uses the same text in one of their projects, it won't be "
"translated if they provide a translation for it. When contributing to the "
"engine, this is generally the macro you should use for localizable strings."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:76
msgid ""
"``RTR()``: **Run-time translations** will be automatically localized in "
"projects if they provide a translation for the given string. This kind of "
"translation shouldn't be used in editor-only code."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:87
msgid ""
"To insert placeholders in localizable strings, wrap the localization macro "
"in a ``vformat()`` call as follows:"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:97
msgid ""
"When using ``vformat()`` and a translation macro together, always wrap the "
"translation macro in ``vformat()``, not the other way around. Otherwise, the "
"string will never match the translation as it will have the placeholder "
"already replaced when it's passed to TranslationServer."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:103
msgid "Clamp a value"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:105
msgid ""
"Godot has provides macros for clamping a value with a lower bound (``MAX``), "
"an upper bound (``MIN``) or both (``CLAMP``):"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:117
msgid ""
"This works with any type that can be compared to other values (like ``int`` "
"and ``float``)."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:121
msgid "Microbenchmarking"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:123
msgid ""
"If you want to benchmark a piece of code but don't know how to use a "
"profiler, use this snippet:"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:135
msgid ""
"This will print the time spent between the ``begin`` declaration and the "
"``end`` declaration."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:140
msgid ""
"You may have to ``#include \"core/os/os.h\"`` if it's not present already."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:142
msgid ""
"When opening a pull request, make sure to remove this snippet as well as the "
"include if it wasn't there previously."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:146
#, fuzzy
msgid "Get project/editor settings"
msgstr "עורך"

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:148
#, fuzzy
msgid "There are four macros available for this:"
msgstr "אין מגבלות שימוש בגודוט"

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:160
msgid ""
"If a default value has been specified elsewhere, don't specify it again to "
"avoid repetition:"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:170
msgid ""
"It's recommended to use ``GLOBAL_DEF``/``EDITOR_DEF`` only once per setting "
"and use ``GLOBAL_GET``/``EDITOR_GET`` in all other places where it's "
"referenced."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:174
msgid "Error macros"
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:176
msgid ""
"Godot features many error macros to make error reporting more convenient."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:180
msgid ""
"Conditions in error macros work in the **opposite** way of GDScript's built-"
"in ``assert()`` function. An error is reached if the condition inside "
"evaluates to ``true``, not ``false``."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:186
msgid ""
"Only variants with custom messages are documented here, as these should "
"always be used in new contributions. Make sure the custom message provided "
"includes enough information for people to diagnose the issue, even if they "
"don't know C++. In case a method was passed invalid arguments, you can print "
"the invalid value in question to ease debugging."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:192
msgid ""
"For internal error checking where displaying a human-readable message isn't "
"necessary, remove ``_MSG`` at the end of the macro name and don't supply a "
"message argument."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:196
msgid ""
"Also, always try to return processable data so the engine can keep running "
"well."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:240
msgid ""
"See `core/error_macros.h <https://github.com/godotengine/godot/blob/master/"
"core/error_macros.h>`__ in Godot's codebase for more information about each "
"error macro."
msgstr ""

#: ../../docs/development/cpp/common_engine_methods_and_macros.rst:243
msgid ""
"Some functions return an error code (materialized by a return type of "
"``Error``). This value can be returned directly from an error macro. See the "
"list of available error codes in `core/error_list.h <https://github.com/"
"godotengine/godot/blob/master/core/error_list.h>`__."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:4
msgid "Core types"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:6
msgid ""
"Godot has a rich set of classes and templates that compose its core, and "
"everything is built upon them."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:9
msgid ""
"This reference will try to list them in order for their better understanding."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:13
msgid "Definitions"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:15
msgid ""
"Godot uses the standard C98 datatypes, such as ``uint8_t``, ``uint32_t``, "
"``int64_t``, etc. which are nowadays supported by every compiler. "
"Reinventing the wheel for those is not fun, as it makes code more difficult "
"to read."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:20
msgid ""
"In general, care is not taken to use the most efficient datatype for a given "
"task unless using large structures or arrays. ``int`` is used through most "
"of the code unless necessary. This is done because nowadays every device has "
"at least a 32 bits bus and can do such operations in one cycle. It makes "
"code more readable too."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:26
msgid ""
"For files or memory sizes, ``size_t`` is used, which is warranted to be 64 "
"bits."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:29
msgid ""
"For Unicode characters, CharType instead of wchar_t is used, because many "
"architectures have 4 bytes long wchar_t, where 2 bytes might be desired. "
"However, by default, this has not been forced and CharType maps directly to "
"wchar_t."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:35
#: ../../docs/development/cpp/core_types.rst:132
#: ../../docs/development/cpp/core_types.rst:166
#: ../../docs/development/cpp/core_types.rst:182
#: ../../docs/development/cpp/core_types.rst:198
#: ../../docs/development/cpp/core_types.rst:209
#: ../../docs/development/cpp/core_types.rst:220
#: ../../docs/development/cpp/core_types.rst:233
#: ../../docs/development/cpp/variant_class.rst:38
#: ../../docs/development/cpp/variant_class.rst:57
#: ../../docs/development/cpp/object_class.rst:31
#: ../../docs/development/cpp/object_class.rst:89
#: ../../docs/development/cpp/object_class.rst:254
#: ../../docs/development/cpp/object_class.rst:270
#: ../../docs/development/cpp/object_class.rst:291
#: ../../docs/development/cpp/object_class.rst:310
#: ../../docs/development/cpp/custom_audiostreams.rst:23
#: ../../docs/development/cpp/custom_audiostreams.rst:117
#: ../../docs/development/cpp/custom_audiostreams.rst:348
#: ../../docs/development/cpp/custom_godot_servers.rst:475
msgid "References:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:37
msgid ""
"`core/typedefs.h <https://github.com/godotengine/godot/blob/master/core/"
"typedefs.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:40
msgid "Memory model"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:42
msgid ""
"PC is a wonderful architecture. Computers often have gigabytes of RAM, "
"terabytes of storage and gigahertz of CPU, and when an application needs "
"more resources the OS will swap out the inactive ones. Other architectures "
"(like mobile or consoles) are in general more limited."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:47
msgid ""
"The most common memory model is the heap, where an application will request "
"a region of memory, and the underlying OS will try to fit it somewhere and "
"return it. This often works best and is flexible, but over time and with "
"abuse, this can lead to segmentation."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:52
msgid ""
"Segmentation slowly creates holes that are too small for most common "
"allocations, so that memory is wasted. There is a lot of literature about "
"heap and segmentation, so this topic will not be developed further here. "
"Modern operating systems use paged memory, which helps mitigate the problem "
"of segmentation but doesn't solve it."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:58
msgid ""
"However, in many studies and tests, it is shown that given enough memory, if "
"the maximum allocation size is below a given threshold in proportion to the "
"maximum heap size and proportion of memory intended to be unused, "
"segmentation will not be a problem over time as it will remain constant. In "
"other words, leave 10-20% of your memory free and perform all small "
"allocations and you are fine."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:65
msgid ""
"Godot ensures that all objects that can be allocated dynamically are small "
"(less than a few kb at most). But what happens if an allocation is too large "
"(like an image or mesh geometry or large array)? In this case Godot has the "
"option to use a dynamic memory pool. This memory needs to be locked to be "
"accessed, and if an allocation runs out of memory, the pool will be "
"rearranged and compacted on demand. Depending on the need of the game, the "
"programmer can configure the dynamic memory pool size."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:74
msgid "Allocating memory"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:76
msgid ""
"Godot has many tools for tracking memory usage in a game, especially during "
"debug. Because of this, the regular C and C++ library calls should not be "
"used. Instead, a few other ones are provided."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:80
msgid "For C-style allocation, Godot provides a few macros:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:88
msgid ""
"These are equivalent to the usual malloc, realloc, free of the standard C "
"library."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:91
msgid "For C++-style allocation, special macros are provided:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:101
msgid "which are equivalent to new, delete, new[] and delete[]."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:103
msgid ""
"memnew/memdelete also use a little C++ magic and notify Objects right after "
"they are created, and right before they are deleted."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:106
msgid ""
"For dynamic memory, the PoolVector<> template is provided. PoolVector is a "
"standard vector class, and is very similar to vector in the C++ standard "
"library. To create a PoolVector buffer, use this:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:114
msgid ""
"PoolVector can be accessed using the [] operator and a few helpers exist for "
"this:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:126
msgid ""
"These operations allow fast read/write from PoolVectors and keep it locked "
"until they go out of scope. However, PoolVectors should be used for small, "
"dynamic memory operations, as read() and write() are too slow for a large "
"amount of accesses."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:134
msgid ""
"`core/os/memory.h <https://github.com/godotengine/godot/blob/master/core/os/"
"memory.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:135
msgid ""
"`core/pool_vector.h <https://github.com/godotengine/godot/blob/master/core/"
"pool_vector.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:140
msgid "Godot provides also a set of common containers:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:142
msgid "Vector"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:143
msgid "List"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:144
msgid "Set"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:145
msgid "Map"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:147
msgid ""
"They are simple and aim to be as minimal as possible, as templates in C++ "
"are often inlined and make the binary size much fatter, both in debug "
"symbols and code. List, Set and Map can be iterated using pointers, like "
"this:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:158
msgid "The Vector<> class also has a few nice features:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:160
msgid ""
"It does copy on write, so making copies of it is cheap as long as they are "
"not modified."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:162
msgid ""
"It supports multi-threading, by using atomic operations on the reference "
"counter."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:168
msgid ""
"`core/vector.h <https://github.com/godotengine/godot/blob/master/core/vector."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:169
msgid ""
"`core/list.h <https://github.com/godotengine/godot/blob/master/core/list."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:170
msgid ""
"`core/set.h <https://github.com/godotengine/godot/blob/master/core/set.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:171
msgid ""
"`core/map.h <https://github.com/godotengine/godot/blob/master/core/map.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:176
msgid ""
"Godot also provides a String class. This class has a huge amount of "
"features, full Unicode support in all the functions (like case operations) "
"and utf8 parsing/extracting, as well as helpers for conversion and "
"visualization."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:184
msgid ""
"`core/ustring.h <https://github.com/godotengine/godot/blob/master/core/"
"ustring.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:187
msgid "StringName"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:189
msgid ""
"StringNames are like a String, but they are unique. Creating a StringName "
"from a string results in a unique internal pointer for all equal strings. "
"StringNames are useful for using strings as identifier, as comparing them is "
"basically comparing a pointer."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:194
msgid ""
"Creation of a StringName (especially a new one) is slow, but comparison is "
"fast."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:200
msgid ""
"`core/string_name.h <https://github.com/godotengine/godot/blob/master/core/"
"string_name.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:203
msgid "Math types"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:205
msgid ""
"There are several linear math types available in the core/math directory."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:211
msgid ""
"`core/math <https://github.com/godotengine/godot/tree/master/core/math>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:214
#: ../../docs/development/file_formats/tscn.rst:134
msgid "NodePath"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:216
msgid ""
"This is a special datatype used for storing paths in a scene tree and "
"referencing them fast."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:222
msgid ""
"`core/node_path.h <https://github.com/godotengine/godot/blob/master/core/"
"node_path.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:225
msgid "RID"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:227
msgid ""
"RIDs are resource IDs. Servers use these to reference data stored in them. "
"RIDs are opaque, meaning that the data they reference can't be accessed "
"directly. RIDs are unique, even for different types of referenced data."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:235
#: ../../docs/development/cpp/custom_godot_servers.rst:319
msgid ""
"`core/rid.h <https://github.com/godotengine/godot/blob/master/core/rid.h>`__"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:4
msgid "Variant class"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:9
msgid ""
"Variant is the most important datatype of Godot, it's the most important "
"class in the engine. A Variant takes up only 20 bytes and can store almost "
"any engine datatype inside of it. Variants are rarely used to hold "
"information for long periods of time, instead they are used mainly for "
"communication, editing, serialization and generally moving data around."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:16
msgid "A Variant can:"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:18
msgid "Store almost any datatype"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:19
msgid ""
"Perform operations between many variants (GDScript uses Variant as its "
"atomic/native datatype)."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:21
msgid "Be hashed, so it can be compared quickly to other variants"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:22
msgid "Be used to convert safely between datatypes"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:23
msgid ""
"Be used to abstract calling methods and their arguments (Godot exports all "
"its functions through variants)"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:25
msgid "Be used to defer calls or move data between threads."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:26
msgid "Be serialized as binary and stored to disk, or transferred via network."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:28
msgid ""
"Be serialized to text and use it for printing values and editable settings."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:30
msgid "Work as an exported property, so the editor can edit it universally."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:31
msgid "Be used for dictionaries, arrays, parsers, etc."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:33
msgid ""
"Basically, thanks to the Variant class, writing Godot itself was a much, "
"much easier task, as it allows for highly dynamic constructs not common of C+"
"+ with little effort. Become a friend of Variant today."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:40
msgid ""
"`core/variant.h <https://github.com/godotengine/godot/blob/master/core/"
"variant.h>`__"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:43
msgid "Containers: Dictionary and Array"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:45
msgid ""
"Both are implemented using variants. A Dictionary can match any datatype "
"used as key to any other datatype. An Array just holds an array of Variants. "
"Of course, a Variant can also hold a Dictionary and an Array inside, making "
"it even more flexible."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:50
msgid ""
"Modifications to a container will modify all references to it. A Mutex "
"should be created to lock it if multi threaded access is desired."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:54
msgid ""
"Copy-on-write (COW) mode support for containers was dropped with Godot 3.0."
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:59
msgid ""
"`core/dictionary.h <https://github.com/godotengine/godot/blob/master/core/"
"dictionary.h>`__"
msgstr ""

#: ../../docs/development/cpp/variant_class.rst:60
msgid ""
"`core/array.h <https://github.com/godotengine/godot/blob/master/core/array."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:4
msgid "Object class"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:7
msgid "General definition"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:9
msgid ""
":ref:`Object <class_object>` is the base class for almost everything. Most "
"classes in Godot inherit directly or indirectly from it. Objects provide "
"reflection and editable properties, and declaring them is a matter of using "
"a single macro like this."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:21
msgid "This makes Objects gain a lot of functionality, like for example"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:33
msgid ""
"`core/object.h <https://github.com/godotengine/godot/blob/master/core/object."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:36
msgid "Registering an Object"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:38
msgid ""
"ClassDB is a static class that holds the entire list of registered classes "
"that inherit from Object, as well as dynamic bindings to all their methods "
"properties and integer constants."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:42
msgid "Classes are registered by calling:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:48
msgid ""
"Registering it will allow the class to be instanced by scripts, code, or "
"creating them again when deserializing."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:51
msgid "Registering as virtual is the same but it can't be instanced."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:57
msgid ""
"Object-derived classes can override the static function ``static void "
"_bind_methods()``. When one class is registered, this static function is "
"called to register all the object methods, properties, constants, etc. It's "
"only called once. If an Object derived class is instanced but has not been "
"registered, it will be registered as virtual automatically."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:64
msgid ""
"Inside ``_bind_methods``, there are a couple of things that can be done. "
"Registering functions is one:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:71
msgid "Default values for arguments can be passed in reverse order:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:77
msgid ""
"``D_METHOD`` is a macro that converts \"methodname\" to a StringName for "
"more efficiency. Argument names are used for introspection, but when "
"compiling on release, the macro ignores them, so the strings are unused and "
"optimized away."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:82
msgid "Check ``_bind_methods`` of Control or Object for more examples."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:84
msgid ""
"If just adding modules and functionality that is not expected to be "
"documented as thoroughly, the ``D_METHOD()`` macro can safely be ignored and "
"a string passing the name can be passed for brevity."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:91
msgid ""
"`core/class_db.h <https://github.com/godotengine/godot/blob/master/core/"
"class_db.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:96
msgid "Classes often have enums such as:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:105
msgid ""
"For these to work when binding to methods, the enum must be declared "
"convertible to int, for this a macro is provided:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:112
msgid "The constants can also be bound inside ``_bind_methods``, by using:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:120
msgid "Properties (set/get)"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:122
msgid "Objects export properties, properties are useful for the following:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:124
msgid "Serializing and deserializing the object."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:125
msgid "Creating a list of editable values for the Object derived class."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:127
msgid ""
"Properties are usually defined by the PropertyInfo() class. Usually "
"constructed as:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:134
msgid "For example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:140
msgid ""
"This is an integer property, named \"amount\", hint is a range, range goes "
"from 0 to 49 in steps of 1 (integers). It is only usable for the editor "
"(edit value visually) but won't be serialized."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:144
msgid "Another example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:150
msgid ""
"This is a string property, can take any string but the editor will only "
"allow the defined hint ones. Since no usage flags were specified, the "
"default ones are PROPERTY_USAGE_STORAGE and PROPERTY_USAGE_EDITOR."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:154
msgid ""
"There are plenty of hints and usage flags available in object.h, give them a "
"check."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:157
msgid ""
"Properties can also work like C# properties and be accessed from script "
"using indexing, but this usage is generally discouraged, as using functions "
"is preferred for legibility. Many properties are also bound with categories, "
"such as \"animation/frame\" which also make indexing impossible unless using "
"operator []."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:163
msgid ""
"From ``_bind_methods()``, properties can be created and bound as long as set/"
"get functions exist. Example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:170
msgid "This creates the property using the setter and the getter."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:175
msgid "Binding properties using ``_set``/``_get``/``_get_property_list``"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:177
msgid ""
"An additional method of creating properties exists when more flexibility is "
"desired (i.e. adding or removing properties on context)."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:180
msgid ""
"The following functions can be overridden in an Object derived class, they "
"are NOT virtual, DO NOT make them virtual, they are called for every "
"override and the previous ones are not invalidated (multilevel call)."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:192
msgid ""
"This is also a little less efficient since ``p_property`` must be compared "
"against the desired names in serial order."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:196
msgid "Dynamic casting"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:198
msgid ""
"Godot provides dynamic casting between Object-derived classes, for example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:208
msgid ""
"If cast fails, NULL is returned. This system uses RTTI, but it also works "
"fine (although a bit slower) when RTTI is disabled. This is useful on "
"platforms where a small binary size is ideal, such as HTML5 or consoles "
"(with low memory footprint)."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:216
msgid ""
"Objects can have a set of signals defined (similar to Delegates in other "
"languages). Connecting to them is rather easy:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:225
msgid ""
"The method ``_node_entered_tree`` must be registered to the class using "
"``ClassDB::bind_method`` (explained before)."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:228
msgid ""
"Adding signals to a class is done in ``_bind_methods``, using the "
"``ADD_SIGNAL`` macro, for example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:236
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:18
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:39
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:303
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:356
#: ../../docs/development/cpp/custom_godot_servers.rst:19
#: ../../docs/development/cpp/custom_godot_servers.rst:316
#: ../../docs/development/editor/creating_icons.rst:102
msgid "References"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:238
msgid ""
":ref:`Reference <class_reference>` inherits from Object and holds a "
"reference count. It is the base for reference counted object types. "
"Declaring them must be done using Ref<> template. For example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:250
msgid ""
"``myref`` is reference counted. It will be freed when no more Ref<> "
"templates point to it."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:256
msgid ""
"`core/reference.h <https://github.com/godotengine/godot/blob/master/core/"
"reference.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:259
msgid "Resources:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:261
msgid ""
":ref:`Resource <class_resource>` inherits from Reference, so all resources "
"are reference counted. Resources can optionally contain a path, which "
"reference a file on disk. This can be set with ``resource.set_path(path)``. "
"This is normally done by the resource loader though. No two different "
"resources can have the same path, attempt to do so will result in an error."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:267
msgid "Resources without a path are fine too."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:272
msgid ""
"`core/resource.h <https://github.com/godotengine/godot/blob/master/core/"
"resource.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:275
msgid "Resource loading"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:277
msgid "Resources can be loaded with the ResourceLoader API, like this:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:283
msgid ""
"If a reference to that resource has been loaded previously and is in memory, "
"the resource loader will return that reference. This means that there can be "
"only one resource loaded from a file referenced on disk at the same time."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:288
msgid "resourceinteractiveloader (TODO)"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:293
msgid ""
"`core/io/resource_loader.h <https://github.com/godotengine/godot/blob/master/"
"core/io/resource_loader.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:296
msgid "Resource saving"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:298
msgid "Saving a resource can be done with the resource saver API:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:304
msgid ""
"Instance will be saved. Sub resources that have a path to a file will be "
"saved as a reference to that resource. Sub resources without a path will be "
"bundled with the saved resource and assigned sub-IDs, like \"res://"
"someresource.res::1\". This also helps to cache them when loaded."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:312
msgid ""
"`core/io/resource_saver.h <https://github.com/godotengine/godot/blob/master/"
"core/io/resource_saver.h>`__"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:2
msgid "Inheritance class tree"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:5
msgid "Object"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:15
msgid "Control"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:20
msgid "Node2D"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:25
msgid "Spatial"
msgstr ""

#: ../../docs/development/cpp/inheritance_class_tree.rst:29
msgid "Source files: :download:`class_tree.zip <files/class_tree.zip>`."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:4
msgid "Custom modules in C++"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:7
#: ../../docs/development/cpp/binding_to_external_libraries.rst:7
msgid "Modules"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:9
msgid ""
"Godot allows extending the engine in a modular way. New modules can be "
"created and then enabled/disabled. This allows for adding new engine "
"functionality at every level without modifying the core, which can be split "
"for use and reuse in different modules."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:14
msgid ""
"Modules are located in the ``modules/`` subdirectory of the build system. By "
"default, dozens of modules are enabled, such as GDScript (which, yes, is not "
"part of the base engine), the Mono runtime, a regular expressions module, "
"and others. As many new modules as desired can be created and combined. The "
"SCons build system will take care of it transparently."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:22
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:24
#: ../../docs/development/cpp/custom_audiostreams.rst:29
#: ../../docs/development/cpp/custom_godot_servers.rst:26
msgid "What for?"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:24
msgid ""
"While it's recommended that most of a game be written in scripting (as it is "
"an enormous time saver), it's perfectly possible to use C++ instead. Adding C"
"++ modules can be useful in the following scenarios:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:28
msgid "Binding an external library to Godot (like PhysX, FMOD, etc)."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:29
msgid "Optimize critical parts of a game."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:30
msgid "Adding new functionality to the engine and/or editor."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:31
msgid "Porting an existing game."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:32
msgid "Write a whole, new game in C++ because you can't live without C++."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:35
msgid "Creating a new module"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:37
msgid ""
"Before creating a module, make sure to download the source code of Godot and "
"manage to compile it. There are tutorials in the documentation for this."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:40
msgid ""
"To create a new module, the first step is creating a directory inside "
"``modules/``. If you want to maintain the module separately, you can "
"checkout a different VCS into modules and use it."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:44
msgid ""
"The example module will be called \"summator\", and is placed inside the "
"Godot source tree (``C:\\godot`` refers to wherever the Godot sources are "
"located):"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:55
msgid "Inside we will create a simple summator class:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:84
msgid "And then the cpp file."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:114
msgid ""
"Then, the new class needs to be registered somehow, so two more files need "
"to be created:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:123
#: ../../docs/development/cpp/binding_to_external_libraries.rst:79
msgid ""
"These files must be in the top-level folder of your module (next to your "
"``SCsub`` and ``config.py`` files) for the module to be registered properly."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:126
#: ../../docs/development/cpp/binding_to_external_libraries.rst:82
msgid "These files should contain the following:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:153
msgid ""
"Next, we need to create a ``SCsub`` file so the build system compiles this "
"module:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:164
msgid ""
"With multiple sources, you can also add each file individually to a Python "
"string list:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:172
msgid ""
"This allows for powerful possibilities using Python to construct the file "
"list using loops and logic statements. Look at some modules that ship with "
"Godot by default for examples."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:176
#: ../../docs/development/cpp/binding_to_external_libraries.rst:161
msgid ""
"To add include directories for the compiler to look at you can append it to "
"the environment's paths:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:184
#: ../../docs/development/cpp/binding_to_external_libraries.rst:172
msgid ""
"If you want to add custom compiler flags when building your module, you need "
"to clone `env` first, so it won't add those flags to whole Godot build "
"(which can cause errors). Example `SCsub` with custom flags:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:199
msgid ""
"And finally, the configuration file for the module, this is a simple python "
"script that must be named ``config.py``:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:212
msgid ""
"The module is asked if it's OK to build for the specific platform (in this "
"case, ``True`` means it will build for every platform)."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:215
msgid ""
"And that's it. Hope it was not too complex! Your module should look like "
"this:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:227
msgid ""
"You can then zip it and share the module with everyone else. When building "
"for every platform (instructions in the previous sections), your module will "
"be included."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:231
msgid ""
"There is a parameter limit of 5 in C++ modules for things such as "
"subclasses. This can be raised to 13 by including the header file ``core/"
"method_bind_ext.gen.inc``."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:236
#: ../../docs/development/cpp/binding_to_external_libraries.rst:205
msgid "Using the module"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:238
#: ../../docs/development/cpp/binding_to_external_libraries.rst:207
msgid "You can now use your newly created module from any script:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:249
msgid "The output will be ``60``."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:251
msgid ""
"The previous Summator example is great for small, custom modules, but what "
"if you want to use a larger, external library? Refer to :ref:"
"`doc_binding_to_external_libraries` for details about binding to external "
"libraries."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:256
msgid ""
"If your module is meant to be accessed from the running project (not just "
"from the editor), you must also recompile every export template you plan to "
"use, then specify the path to the custom template in each export preset. "
"Otherwise, you'll get errors when running the project as the module isn't "
"compiled in the export template. See the :ref:`Compiling <toc-devel-"
"compiling>` pages for more information."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:265
msgid "Compiling a module externally"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:267
msgid ""
"Compiling a module involves moving the module's sources directly under the "
"engine's ``modules/`` directory. While this is the most straightforward way "
"to compile a module, there are a couple of reasons as to why this might not "
"be a practical thing to do:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:272
msgid ""
"Having to manually copy modules sources every time you want to compile the "
"engine with or without the module, or taking additional steps needed to "
"manually disable a module during compilation with a build option similar to "
"``module_summator_enabled=no``. Creating symbolic links may also be a "
"solution, but you may additionally need to overcome OS restrictions like "
"needing the symbolic link privilege if doing this via script."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:279
msgid ""
"Depending on whether you have to work with the engine's source code, the "
"module files added directly to ``modules/`` changes the working tree to the "
"point where using a VCS (like ``git``) proves to be cumbersome as you need "
"to make sure that only the engine-related code is committed by filtering "
"changes."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:285
msgid ""
"So if you feel like the independent structure of custom modules is needed, "
"lets take our \"summator\" module and move it to the engine's parent "
"directory:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:293
msgid ""
"Compile the engine with our module by providing ``custom_modules`` build "
"option which accepts a comma-separated list of directory paths containing "
"custom C++ modules, similar to the following:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:301
msgid ""
"The build system shall detect all modules under the ``../modules`` directory "
"and compile them accordingly, including our \"summator\" module."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:306
msgid ""
"Any path passed to ``custom_modules`` will be converted to an absolute path "
"internally as a way to distinguish between custom and built-in modules. It "
"means that things like generating module documentation may rely on a "
"specific path structure on your machine."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:313
msgid ""
":ref:`Introduction to the buildsystem - Custom modules build option "
"<doc_buildsystem_custom_modules>`."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:316
msgid "Improving the build system for development"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:318
msgid ""
"So far we defined a clean and simple SCsub that allows us to add the sources "
"of our new module as part of the Godot binary."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:321
msgid ""
"This static approach is fine when we want to build a release version of our "
"game given we want all the modules in a single binary."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:324
msgid ""
"However, the trade-off is every single change means a full recompilation of "
"the game. Even if SCons is able to detect and recompile only the file that "
"have changed, finding such files and eventually linking the final binary is "
"a long and costly part."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:329
msgid ""
"The solution to avoid such a cost is to build our own module as a shared "
"library that will be dynamically loaded when starting our game's binary."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:362
msgid ""
"Once compiled, we should end up with a ``bin`` directory containing both the "
"``godot*`` binary and our ``libsummator*.so``. However given the .so is not "
"in a standard directory (like ``/usr/lib``), we have to help our binary find "
"it during runtime with the ``LD_LIBRARY_PATH`` environment variable:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:373
msgid ""
"You have to ``export`` the environment variable otherwise you won't be able "
"to play your project from within the editor."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:376
msgid ""
"On top of that, it would be nice to be able to select whether to compile our "
"module as shared library (for development) or as a part of the Godot binary "
"(for release). To do that we can define a custom flag to be passed to SCons "
"using the `ARGUMENT` command:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:408
msgid ""
"Now by default ``scons`` command will build our module as part of Godot's "
"binary and as a shared library when passing ``summator_shared=yes``."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:411
msgid ""
"Finally, you can even speed up the build further by explicitly specifying "
"your shared module as target in the SCons command:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:419
msgid "Writing custom documentation"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:421
msgid ""
"Writing documentation may seem like a boring task, but it is highly "
"recommended to document your newly created module in order to make it easier "
"for users to benefit from it. Not to mention that the code you've written "
"one year ago may become indistinguishable from the code that was written by "
"someone else, so be kind to your future self!"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:427
msgid "There are several steps in order to setup custom docs for the module:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:429
msgid ""
"Make a new directory in the root of the module. The directory name can be "
"anything, but we'll be using the ``doc_classes`` name throughout this "
"section."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:432
msgid "Now, we need to edit ``config.py``, add the following snippet:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:444
msgid ""
"The ``get_doc_path()`` function is used by the build system to determine the "
"location of the docs. In this case, they will be located in the ``modules/"
"summator/doc_classes`` directory. If you don't define this, the doc path for "
"your module will fall back to the main ``doc/classes`` directory."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:450
msgid ""
"The ``get_doc_classes()`` method is necessary for the build system to know "
"which registered classes belong to the module. You need to list all of your "
"classes here. The classes that you don't list will end up in the main ``doc/"
"classes`` directory."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:457
msgid ""
"You can use Git to check if you have missed some of your classes by checking "
"the untracked files with ``git status``. For example::"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:462
msgid "Example output::"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:474
#, fuzzy
msgid "Now we can generate the documentation:"
msgstr "על אודות התיעוד"

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:476
msgid ""
"We can do this via running Godot's doctool i.e. ``godot --doctool <path>``, "
"which will dump the engine API reference to the given ``<path>`` in XML "
"format."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:479
msgid ""
"In our case we'll point it to the root of the cloned repository. You can "
"point it to an another folder, and just copy over the files that you need."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:482
msgid "Run command:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:488
msgid ""
"Now if you go to the ``godot/modules/summator/doc_classes`` folder, you will "
"see that it contains a ``Summator.xml`` file, or any other classes, that you "
"referenced in your ``get_doc_classes`` function."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:492
msgid ""
"Edit the file(s) following :ref:`doc_updating_the_class_reference` and "
"recompile the engine."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:494
msgid ""
"Once the compilation process is finished, the docs will become accessible "
"within the engine's built-in documentation system."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:497
msgid ""
"In order to keep documentation up-to-date, all you'll have to do is simply "
"modify one of the XML files and recompile the engine from now on."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:500
msgid ""
"If you change your module's API, you can also re-extract the docs, they will "
"contain the things that you previously added. Of course if you point it to "
"your godot folder, make sure you don't lose work by extracting older docs "
"from an older engine build on top of the newer ones."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:505
msgid ""
"Note that if you don't have write access rights to your supplied ``<path>``, "
"you might encounter an error similar to the following:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:517
msgid "Adding custom editor icons"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:519
msgid ""
"Similarly to how you can write self-contained documentation within a module, "
"you can also create your own custom icons for classes to appear in the "
"editor."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:522
msgid ""
"For the actual process of creating editor icons to be integrated within the "
"engine, please refer to :ref:`doc_editor_icons` first."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:525
msgid "Once you've created your icon(s), proceed with the following steps:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:527
msgid ""
"Make a new directory in the root of the module named ``icons``. This is the "
"default path for the engine to look for module's editor icons."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:530
msgid ""
"Move your newly created ``svg`` icons (optimized or not) into that folder."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:532
msgid ""
"Recompile the engine and run the editor. Now the icon(s) will appear in "
"editor's interface where appropriate."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:535
msgid ""
"If you'd like to store your icons somewhere else within your module, add the "
"following code snippet to ``config.py`` to override the default path:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:544
msgid "Summing up"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:546
msgid "Remember to:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:548
msgid "use ``GDCLASS`` macro for inheritance, so Godot can wrap it"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:549
msgid ""
"use ``_bind_methods`` to bind your functions to scripting, and to allow them "
"to work as callbacks for signals."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:552
msgid ""
"But this is not all, depending what you do, you will be greeted with some "
"(hopefully positive) surprises."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:555
msgid ""
"If you inherit from :ref:`class_Node` (or any derived node type, such as "
"Sprite), your new class will appear in the editor, in the inheritance tree "
"in the \"Add Node\" dialog."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:558
msgid ""
"If you inherit from :ref:`class_Resource`, it will appear in the resource "
"list, and all the exposed properties can be serialized when saved/loaded."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:561
msgid ""
"By this same logic, you can extend the Editor and almost any area of the "
"engine."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:4
msgid "Binding to external libraries"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:9
msgid ""
"The Summator example in :ref:`doc_custom_modules_in_c++` is great for small, "
"custom modules, but what if you want to use a larger, external library? "
"Let's look at an example using Festival, a speech synthesis (text-to-speech) "
"library written in C++."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:14
msgid ""
"To bind to an external library, set up a module directory similar to the "
"Summator example:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:20
msgid "Next, you will create a header file with a simple TTS class:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:45
msgid "And then you'll add the cpp file."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:70
msgid ""
"Just as before, the new class needs to be registered somehow, so two more "
"files need to be created:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:109
msgid ""
"Next, you need to create a ``SCsub`` file so the build system compiles this "
"module:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:121
msgid ""
"You'll need to install the external library on your machine to get the .a "
"library files.  See the library's official documentation for specific "
"instructions on how to do this for your operation system.  We've included "
"the installation commands for Linux below, for reference."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:132
msgid ""
"The voices that Festival uses (and any other potential external/3rd-party "
"resource) all have varying licenses and terms of use; some (if not most) of "
"them may be be problematic with Godot, even if the Festival Library itself "
"is MIT License compatible. Please be sure to check the licenses and terms of "
"use."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:137
msgid ""
"The external library will also need to be installed inside your module to "
"make the source files accessible to the compiler, while also keeping the "
"module code self-contained.  The festival and speech_tools libraries can be "
"installed from the modules/tts/ directory via git using the following "
"commands:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:147
msgid ""
"If you don't want the external repository source files committed to your "
"repository, you can link to them instead by adding them as submodules (from "
"within the modules/tts/ directory), as seen below:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:156
msgid ""
"Please note that Git submodules are not used in the Godot repository.  If "
"you are developing a module to be merged into the main Godot repository, you "
"should not use submodules.  If your module doesn't get merged in, you can "
"always try to implement the external library as a GDNative C++ plugin."
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:187
msgid "The final module should look like this:"
msgstr ""

#: ../../docs/development/cpp/binding_to_external_libraries.rst:216
msgid "And the output will be ``is_spoken: True`` if the text is spoken."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:4
msgid "Custom resource format loaders"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:9
msgid ""
"ResourceFormatLoader is a factory interface for loading file assets. "
"Resources are primary containers. When load is called on the same file path "
"again, the previous loaded Resource will be referenced. Naturally, loaded "
"resources must be stateless."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:14
msgid ""
"This guide assumes the reader knows how to create C++ modules and Godot data "
"types. If not, refer to this guide :ref:`doc_custom_modules_in_c++`."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:20
msgid ":ref:`ResourceLoader<class_resourceloader>`"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:21
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:358
msgid ""
"`core/io/resource_loader.cpp <https://github.com/godotengine/godot/blob/"
"master/core/io/resource_loader.cpp>`_"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:26
msgid "Adding new support for many file formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:27
msgid "Audio formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:28
msgid "Video formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:29
msgid "Machine learning models"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:32
msgid "What not?"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:34
msgid "Raster images"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:36
msgid "ImageFormatLoader should be used to load images."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:41
msgid ""
"`core/io/image_loader.h <https://github.com/godotengine/godot/blob/master/"
"core/io/image_loader.h>`_"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:45
msgid "Creating a ResourceFormatLoader"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:47
msgid ""
"Each file format consist of a data container and a ``ResourceFormatLoader``."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:49
msgid ""
"ResourceFormatLoaders are usually simple classes which return all the "
"necessary metadata for supporting new extensions in Godot. The class must "
"the return the format name and the extension string."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:53
msgid ""
"In addition, ResourceFormatLoaders must convert file paths into resources "
"with the ``load`` function. To load a resource, ``load`` must read and "
"handle data serialization."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:109
#, fuzzy
msgid "Creating a ResourceFormatSaver"
msgstr "יצירת תוכן"

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:111
msgid ""
"If you'd like to be able to edit and save a resource, you can implement a "
"``ResourceFormatSaver``:"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:158
msgid "Creating custom data types"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:160
msgid ""
"Godot may not have a proper substitute within its :ref:`doc_core_types` or "
"managed resources. Godot needs a new registered data type to understand "
"additional binary formats such as machine learning models."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:164
msgid "Here is an example of creating a custom datatype:"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:262
msgid "Considerations"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:264
msgid ""
"Some libraries may not define certain common routines such as IO handling. "
"Therefore, Godot call translations are required."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:267
msgid ""
"For example, here is the code for translating ``FileAccess`` calls into "
"``std::istream``."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:305
msgid "`istream <http://www.cplusplus.com/reference/istream/istream/>`_"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:306
msgid ""
"`streambuf <http://www.cplusplus.com/reference/streambuf/streambuf/?"
"kw=streambuf>`_"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:307
msgid ""
"`core/io/fileaccess.h <https://github.com/godotengine/godot/blob/master/core/"
"os/file_access.h>`_"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:310
msgid "Registering the new file format"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:312
msgid ""
"Godot registers ``ResourcesFormatLoader`` with a ``ResourceLoader`` handler. "
"The handler selects the proper loader automatically when ``load`` is called."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:361
msgid "Loading it on GDScript"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:363
msgid ""
"Save a file called ``demo.json`` with the following contents and place it in "
"the project's root folder:"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:379
msgid "Then attach the following script to any node::"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:4
msgid "Custom AudioStreams"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:9
msgid ""
"AudioStream is the base class of all audio emitting objects. "
"AudioStreamPlayer binds onto an AudioStream to emit PCM data into an "
"AudioServer which manages audio drivers."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:13
msgid ""
"All audio resources require two audio based classes: AudioStream and "
"AudioStreamPlayback. As a data container, AudioStream contains the resource "
"and exposes itself to GDScript. AudioStream references its own internal "
"custom AudioStreamPlayback which translates AudioStream into PCM data."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:19
msgid ""
"This guide assumes the reader knows how to create C++ modules. If not, refer "
"to this guide :ref:`doc_custom_modules_in_c++`."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:25
#: ../../docs/development/cpp/custom_audiostreams.rst:119
#: ../../docs/development/cpp/custom_audiostreams.rst:350
msgid ""
"`servers/audio/audio_stream.h <https://github.com/godotengine/godot/blob/"
"master/servers/audio/audio_stream.h>`__"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:26
#: ../../docs/development/cpp/custom_audiostreams.rst:351
msgid ""
"`scene/audio/audioplayer.cpp <https://github.com/godotengine/godot/blob/"
"master/scene/audio/audio_player.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:31
msgid "Binding external libraries (like Wwise, FMOD, etc)."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:32
msgid "Adding custom audio queues"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:33
msgid "Adding support for more audio formats"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:36
msgid "Create an AudioStream"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:38
msgid ""
"An AudioStream consists of three components: data container, stream name, "
"and an AudioStreamPlayback friend class generator. Audio data can be loaded "
"in a number of ways such as with an internal counter for a tone generator, "
"internal/external buffer, or a file reference."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:43
msgid ""
"Some AudioStreams need to be stateless such as objects loaded from "
"ResourceLoader. ResourceLoader loads once and references the same object "
"regardless how many times ``load`` is called on a specific resource. "
"Therefore, playback state must be self-contained in AudioStreamPlayback."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:123
msgid "Create an AudioStreamPlayback"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:125
msgid ""
"AudioStreamPlayer uses ``mix`` callback to obtain PCM data. The callback "
"must match sample rate and fill the buffer."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:127
msgid ""
"Since AudioStreamPlayback is controlled by the audio thread, i/o and dynamic "
"memory allocation are forbidden."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:232
msgid "Resampling"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:234
msgid ""
"Godot's AudioServer currently uses 44100 Hz sample rate. When other sample "
"rates are needed such as 48000, either provide one or use "
"AudioStreamPlaybackResampled. Godot provides cubic interpolation for audio "
"resampling."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:238
msgid ""
"Instead of overloading ``mix``, AudioStreamPlaybackResampled uses "
"``_mix_internal`` to query AudioFrames and ``get_stream_sampling_rate`` to "
"query current mix rate."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:349
msgid ""
"`core/math/audio_frame.h <https://github.com/godotengine/godot/blob/master/"
"core/math/audio_frame.h>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:4
msgid "Custom Godot servers"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:9
msgid ""
"Godot implements multi-threading as servers. Servers are daemons which "
"manages data, processes, and pushes the result. Servers implement the "
"mediator pattern which interprets resource ID and process data for the "
"engine and other modules. In addition, the server claims ownership for its "
"RID allocations."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:15
msgid ""
"This guide assumes the reader knows how to create C++ modules and Godot data "
"types. If not, refer to :ref:`doc_custom_modules_in_c++`."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:21
msgid ""
"`Why does Godot use servers and RIDs? <https://godotengine.org/article/why-"
"does-godot-use-servers-and-rids>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:22
msgid "`Singleton pattern <https://en.wikipedia.org/wiki/Singleton_pattern>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:23
msgid "`Mediator pattern <https://en.wikipedia.org/wiki/Mediator_pattern>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:28
msgid "Adding artificial intelligence."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:29
msgid "Adding custom asynchronous threads."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:30
msgid "Adding support for a new input device."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:31
msgid "Adding writing threads."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:32
msgid "Adding a custom VoIP protocol."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:33
msgid "And more..."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:36
msgid "Creating a Godot server"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:38
msgid ""
"At minimum, a server must have a static instance, a sleep timer, a thread "
"loop, an initialization state and a cleanup procedure."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:274
msgid "Custom managed resource data"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:276
msgid ""
"Godot servers implement a mediator pattern. All data types inherit "
"``RID_Data``. ``RID_Owner<MyRID_Data>`` owns the object when ``make_rid`` is "
"called. During debug mode only, RID_Owner maintains a list of RIDs. In "
"practice, RIDs are similar to writing object-oriented C code."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:318
msgid ":ref:`RID<class_rid>`"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:322
msgid "Registering the class in GDScript"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:324
msgid ""
"Servers are allocated in ``register_types.cpp``. The constructor sets the "
"static instance and ``init()`` creates the managed thread; "
"``unregister_types.cpp`` cleans up the server."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:328
msgid ""
"Since a Godot server class creates an instance and binds it to a static "
"singleton, binding the class might not reference the correct instance. "
"Therefore, a dummy class must be created to reference the proper Godot "
"server."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:332
msgid ""
"In ``register_server_types()``, ``Engine::get_singleton()->add_singleton`` "
"is used to register the dummy class in GDScript."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:376
msgid ""
"`servers/register_server_types.cpp <https://github.com/godotengine/godot/"
"blob/master/servers/register_server_types.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:379
msgid "Bind methods"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:381
msgid ""
"The dummy class binds singleton methods to GDScript. In most cases, the "
"dummy class methods wraps around."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:389
#, fuzzy
msgid "Binding Signals"
msgstr "אותות"

#: ../../docs/development/cpp/custom_godot_servers.rst:391
msgid ""
"It is possible to emit signals to GDScript by calling the GDScript dummy "
"object."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:466
msgid "MessageQueue"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:468
msgid ""
"In order to send commands into SceneTree, MessageQueue is a thread-safe "
"buffer to queue set and call methods for other threads. To queue a command, "
"obtain the target object RID and use either ``push_call``, ``push_set``, or "
"``push_notification`` to execute the desired behavior. The queue will be "
"flushed whenever either ``SceneTree::idle`` or ``SceneTree::iteration`` is "
"executed."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:477
msgid ""
"`core/message_queue.cpp <https://github.com/godotengine/godot/blob/master/"
"core/message_queue.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:480
msgid "Summing it up"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:482
msgid "Here is the GDScript sample code:"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:508
msgid ""
"The actual `Hilbert Hotel <https://en.wikipedia.org/wiki/Hilbert"
"%27s_paradox_of_the_Grand_Hotel>`__ is impossible."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:509
msgid "Connecting signal example code is pretty hacky."
msgstr ""

#: ../../docs/development/editor/index.rst:2
#, fuzzy
msgid "Editor development"
msgstr "פיתוח"

#: ../../docs/development/editor/creating_icons.rst:4
#, fuzzy
msgid "Editor icons"
msgstr "עורך"

#: ../../docs/development/editor/creating_icons.rst:6
msgid ""
"When a new class is created and exposed to scripting, the editor's interface "
"will display it with a default icon representing the base class it inherits "
"from. In most cases, it's still recommended to create icons for new classes "
"to improve the user experience."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:12
#, fuzzy
msgid "Creating icons"
msgstr "יצירת תוכן"

#: ../../docs/development/editor/creating_icons.rst:14
msgid ""
"To create new icons, you first need a vector graphics editor installed. For "
"instance, you can use the open source `Inkscape <https://inkscape.org/>`_ "
"editor."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:17
msgid "Clone the ``godot`` repository containing all the editor icons:"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:23
msgid ""
"The icons must be created in a vector graphics editor in SVG format. There "
"are two main requirements to follow:"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:26
msgid ""
"Icons must be 16×16. In Inkscape, you can configure the document size in "
"**File > Document Properties**."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:28
msgid ""
"Lines should be snapped to pixels whenever possible to remain crisp at lower "
"DPI. You can create a 16×16 grid in Inkscape to make this easier."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:31
msgid ""
"Once you're satisfied with the icon's design, save the icon in the cloned "
"repository's ``editor/icons`` folder. The icon name should match the "
"intended name in a case-sensitive manner. For example, to create an icon for "
"CPUParticles2D, name the file ``CPUParticles2D.svg``."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:37
msgid "Color conversion for light editor themes"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:39
msgid ""
"If the user has configured their editor to use a light theme, Godot will "
"convert the icon's colors based on a `set of predefined color mappings "
"<https://github.com/godotengine/godot/blob/"
"b9f2e57d6240346f1833fd0390de195c956299e7/editor/editor_themes.cpp#L122-"
"L184>`__. This is to ensure the icon always displays with a sufficient "
"contrast rate. Try to restrict your icon's color palette to colors found in "
"the list above. Otherwise, your icon may become difficult to read on a light "
"background."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:47
#, fuzzy
msgid "Icon optimization"
msgstr "אנימציות"

#: ../../docs/development/editor/creating_icons.rst:49
msgid ""
"Because the editor renders SVGs once at load time, they need to be small in "
"size so they can be efficiently parsed. Editor icons must be first optimized "
"before being added to the engine, to do so:"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:53
msgid ""
"Install `svgcleaner <https://github.com/RazrFalcon/svgcleaner>`__ by "
"downloading a binary from its `Releases tab <https://github.com/RazrFalcon/"
"svgcleaner/releases/latest>`__ and placing it into a location in your "
"``PATH`` environment variable."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:58
msgid ""
"Run the command below, replacing ``svg_source.svg`` with the path to your "
"SVG file (which can be a relative or absolute path):"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:65
msgid ""
"The ``--multipass`` switch improves compression, so make sure to include it. "
"The optimized icon will be saved to ``svg_optimized.svg``. You can also "
"change the destination parameter to any relative or absolute path you'd like."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:71
msgid ""
"While this optimization step won't impact the icon's quality noticeably, it "
"will still remove editor-only information such as guides. Therefore, it's "
"recommended to keep the source SVG around if you need to make further "
"changes."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:77
msgid "Integrating and sharing the icons"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:79
msgid ""
"If you're contributing to the engine itself, you should make a pull request "
"to add optimized icons to ``editor/icons`` in the main repository. Recompile "
"the engine to make it pick up new icons for classes."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:83
msgid ""
"It's also possible to create custom icons within a module. If you're "
"creating your own module and don't plan to integrate it with Godot, you "
"don't need to make a separate pull request for your icons to be available "
"within the editor as they can be self-contained."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:88
msgid ""
"For specific instructions on how to create module icons, refer to :ref:"
"`Creating custom module icons<doc_custom_module_icons>`."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:94
msgid "If icons don't appear in the editor, make sure that:"
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:96
msgid ""
"Each icon's filename matches the naming requirement as described previously."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:98
msgid ""
"``modules/svg`` is enabled (it should be enabled by default). Without it, "
"icons won't appear in the editor at all."
msgstr ""

#: ../../docs/development/editor/creating_icons.rst:104
msgid ""
"`editor/icons <https://github.com/godotengine/godot/tree/master/editor/"
"icons>`__"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:4
#, fuzzy
msgid "Editor style guide"
msgstr "עורך"

#: ../../docs/development/editor/editor_style_guide.rst:9
msgid "Thanks for your interest in contributing to the Godot editor!"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:11
msgid ""
"This page describes the grammar and writing style used throughout the Godot "
"editor. Following this style guide will help your contribution get merged "
"faster since there will be fewer review steps required."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:16
#, fuzzy
msgid "Writing style"
msgstr "יצירת תוכן"

#: ../../docs/development/editor/editor_style_guide.rst:18
msgid ""
"**Write messages (errors, warnings, ...) as full sentences.** They should "
"start with an uppercase letter and end with a period."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:20
msgid ""
"**Try to keep sentences short.** This makes it more likely that their "
"translations will be short as well, which is a good thing to avoid UI bugs."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:22
msgid ""
"**Use contractions.** For example, use \"isn't\" instead of \"is not\". An "
"exception to this rule can be made when you specifically want to emphasize "
"one of the contraction's words."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:25
msgid ""
"**Use double quotes in messages** (``\"\"``) instead of simple quotes "
"(``''``). Double quotes should be used to quote user input, file paths and "
"possibly other things depending on the context."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:31
msgid ""
"Try to follow the :ref:`doc_docs_writing_guidelines` in addition to the "
"guidelines outlined above."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:35
msgid "Button and menu texts"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:37
msgid "Capitalize text in buttons and menu actions:"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:39
msgid "**Good:** *Open Editor Data Folder*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:40
msgid "**Bad:** *Open editor data folder*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:42
msgid ""
"If a menu action opens a modal dialog, suffix it with an ellipsis (``...``)."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:44
msgid "**Good:** *Editor Settings...*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:45
#, fuzzy
msgid "**Bad:** *Editor Settings*"
msgstr "עורך"

#: ../../docs/development/editor/editor_style_guide.rst:48
#, fuzzy
msgid "Inspector sections"
msgstr "Android"

#: ../../docs/development/editor/editor_style_guide.rst:50
msgid ""
"In general, don't create sections that contain less than 3 items. Sections "
"that contain few items make it difficult to navigate the inspector, while "
"missing the benefits of using sections such as folding."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:54
msgid ""
"There are some valid exceptions for this, such as material features in :ref:"
"`class_SpatialMaterial`."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:57
msgid "This advice also applies to the Project Settings and Editor Settings."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:60
#, fuzzy
msgid "Inspector performance hints"
msgstr "Android"

#: ../../docs/development/editor/editor_style_guide.rst:62
msgid ""
"Enum properties that noticeably impact performance should have a performance "
"hint associated. The hint should refer to the *absolute* performance impact, "
"rather than being relative to the other options provided in the enum. Here "
"are some examples taken from the Godot editor:"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:67
msgid "**Screen-space antialiasing:** *Disabled (Fastest), FXAA (Fast)*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:68
msgid ""
"**MSAA quality:** *Disabled (Fastest), 2x (Fast), 4x (Average), 8x (Slow), "
"16x (Slower)*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:70
msgid ""
"**DirectionalLight mode:** *Orthogonal (Fast), PSSM 2 Splits (Average), PSSM "
"4 Splits (Slow)*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:73
msgid ""
"For consistency, try to stick to the terms below (from fastest to slowest):"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:75
msgid "*Fastest, Faster, Fast, Average, Slow, Slower, Slowest*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:77
msgid ""
"Their usage doesn't have to be contiguous. For example, you can use only "
"\"Fast\" and \"Slow\" from the list above."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:80
msgid ""
"If you're adding a new enum, its values should be ordered from the fastest "
"option to the slowest option."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:84
#, fuzzy
msgid "Tooltips"
msgstr "כלים"

#: ../../docs/development/editor/editor_style_guide.rst:86
msgid ""
"Consider adding tooltips whenever the action performed by a button or menu "
"action isn't obvious. You can also provide additional context or highlight "
"caveats in the tooltip."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:90
msgid ""
"You can do this by calling ``set_tooltip(TTR(\"Text here.\"))`` on the "
"Control-based node in question. If the tooltip is particularly long (more "
"than ~80 characters), wrap it over several lines by adding line breaks using "
"``\\n``."
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:94
msgid ""
"Tooltips should follow the writing style described above. In addition to "
"this, use indicative mood instead of imperative mood:"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:97
msgid "**Good:** *Computes global illumination for the selected GIProbe.*"
msgstr ""

#: ../../docs/development/editor/editor_style_guide.rst:98
msgid "**Bad:** *Compute global illumination for the selected GIProbe.*"
msgstr ""

#: ../../docs/development/file_formats/index.rst:2
msgid "Godot file formats"
msgstr ""

#: ../../docs/development/file_formats/gdscript_grammar.rst:4
msgid "GDScript grammar"
msgstr ""

#: ../../docs/development/file_formats/gdscript_grammar.rst:6
msgid ""
"This is the formal grammar of GDScript written in `EBNF <https://en."
"wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form>`_, for reference "
"purposes."
msgstr ""

#: ../../docs/development/file_formats/gdscript_grammar.rst:9
msgid ""
"This grammar is descriptive only, derived from the reference documentation "
"and current implementation. The GDScript parser is **not** generated from a "
"grammar definition. Inconsistencies here likely mean an error in this "
"grammar, not a bug in GDScript."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:2
msgid "TSCN file format"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:4
msgid ""
"The TSCN (text scene) file format represents a single scene tree inside "
"Godot. TSCN files have the advantage of being mostly human-readable and easy "
"for version control systems to manage. During import, TSCN files are "
"compiled into binary ``.scn`` files stored inside the .import folder. This "
"reduces the data size and speeds up loading."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:10
msgid ""
"The ESCN (exported scene) file format is identical to the TSCN file format, "
"but is used to indicate to Godot that the file has been exported from "
"another program and should not be edited by the user from within Godot."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:14
msgid ""
"For those looking for a complete description, the parsing is handled in the "
"file `resource_format_text.cpp <https://github.com/godotengine/godot/blob/"
"master/scene/resources/resource_format_text.cpp>`_ in the "
"``ResourceFormatLoaderText`` class."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:19
msgid "File structure"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:21
msgid "There are five main sections inside the TSCN file:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:23
msgid "File Descriptor"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:24
#: ../../docs/development/file_formats/tscn.rst:273
msgid "External resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:25
#: ../../docs/development/file_formats/tscn.rst:295
msgid "Internal resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:29
msgid ""
"The file descriptor looks like ``[gd_scene load_steps=1 format=2]`` and "
"should be the first entry in the file. The ``load_steps`` parameter should "
"(in theory) be the number of resources within the file. However, in "
"practice, its value seems not to matter."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:34
msgid ""
"These sections should appear in order, but it can be hard to distinguish "
"them. The only difference between them is the first element in the heading "
"for all of the items in the section. For example, the heading of all "
"external resources should start with ``[ext_resource .....]``."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:39
msgid ""
"A TSCN file may contain single-line comments starting with a semicolon (``;"
"``). However, comments will be discarded when saving the file using the "
"Godot editor."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:43
msgid "Entries inside the file"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:45
msgid ""
"A heading looks like ``[<resource_type> key=value key=value key=value ...]`` "
"where resource_type is one of:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:49
msgid "``ext_resource``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:50
msgid "``sub_resource``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:51
msgid "``node``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:52
msgid "``connection``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:54
msgid ""
"Below every heading comes zero or more ``key = value`` pairs. The values can "
"be complex datatypes such as Arrays, Transforms, Colors, and so on. For "
"example, a spatial node looks like:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:65
msgid "The scene tree"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:67
msgid ""
"The scene tree is made up of… nodes! The heading of each node consists of "
"its name, parent and (most of the time) a type. For example ``[node type="
"\"Camera\" name=\"PlayerCamera\" parent=\"Player/Head\"]``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:71
msgid "Other valid keywords include:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:73
msgid "``instance``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:74
msgid "``instance_placeholder``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:75
msgid "``owner``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:76
msgid "``index`` (if two nodes have the same name)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:77
#, fuzzy
msgid "``groups``"
msgstr "קבוצות"

#: ../../docs/development/file_formats/tscn.rst:79
msgid ""
"The first node in the file, which is also the scene root, must not have a "
"``parent=Path/To/Node`` entry in its heading. All scene files should have "
"exactly *one* scene root. If it doesn't, Godot will fail to import the file. "
"The parent path of other nodes should be absolute, but shouldn't contain the "
"scene root's name. If the node is a direct child of the scene root, the path "
"should be ``\".\"``. Here is an example scene tree (but without any node "
"content):"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:95
msgid ""
"Similar to the internal resource, the document for each node is currently "
"incomplete. Fortunately, it is easy to find out because you can simply save "
"a file with that node in it. Some example nodes are:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:136
msgid ""
"A tree structure is not enough to represent the whole scene. Godot uses a "
"``NodePath(Path/To/Node)`` structure to refer to another node or attribute "
"of the node anywhere in the scene tree. For instance, MeshInstance uses "
"``NodePath()`` to point to its skeleton. Likewise, Animation tracks use "
"``NodePath()`` to point to node properties to animate."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:163
msgid ""
"The Skeleton node inherits the Spatial node, but also may have a list of "
"bones described in key-value pairs in the format ``bones/Id/"
"Attribute=Value``. The bone attributes consist of:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:168
msgid "``parent``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:169
msgid "``rest``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:170
msgid "``pose``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:171
#: ../../docs/development/file_formats/tscn.rst:391
msgid "``enabled``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:172
msgid "``bound_children``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:174
msgid "``name`` must be the first attribute of each bone."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:175
msgid ""
"``parent`` is the index of parent bone in the bone list, with parent index, "
"the bone list is built to a bone tree."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:177
msgid "``rest`` is the transform matrix of bone in its \"resting\" position."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:178
msgid "``pose`` is the pose matrix; use ``rest`` as the basis."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:179
msgid ""
"``bound_children`` is a list of ``NodePath()`` which point to "
"BoneAttachments belonging to this bone."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:182
msgid "Here's an example of a skeleton node with two bones:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:203
msgid "BoneAttachment"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:205
msgid ""
"BoneAttachment node is an intermediate node to describe some node being "
"parented to a single bone in a Skeleton node. The BoneAttachment has a "
"``bone_name=NameOfBone`` attribute, and the corresponding bone being the "
"parent has the BoneAttachment node in its ``bound_children`` list."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:210
msgid "An example of one MeshInstance parented to a bone in Skeleton:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:235
#, fuzzy
msgid "AnimationPlayer"
msgstr "אנימציות"

#: ../../docs/development/file_formats/tscn.rst:237
msgid ""
"AnimationPlayer works as an animation library. It stores animations listed "
"in the format ``anim/Name=SubResource(ResourceId)``; each line refers to an "
"Animation resource. All the animation resources use the root node of "
"AnimationPlayer. The root node is stored as ``root_node=NodePath(Path/To/"
"Node)``."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:259
msgid ""
"Resources are components that make up the nodes. For example, a MeshInstance "
"node will have an accompanying ArrayMesh resource. The ArrayMesh resource "
"may be either internal or external to the TSCN file."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:263
msgid ""
"References to the resources are handled by ``id`` numbers in the resource's "
"heading. External resources and internal resources are referred to with "
"``ExtResource(id)`` and ``SubResource(id)``, respectively. Because there "
"have different methods to refer to internal and external resources, you can "
"have the same ID for both an internal and external resource."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:269
msgid ""
"For example, to refer to the resource ``[ext_resource id=3 type=\"PackedScene"
"\" path=....]``, you would use ``ExtResource(3)``."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:275
msgid ""
"External resources are links to resources not contained within the TSCN file "
"itself. An external resource consists of a path, a type and an ID."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:278
msgid ""
"Godot always generates absolute paths relative to the resource directory and "
"thus prefixed with ``res://``, but paths relative to the TSCN file's "
"location are also valid."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:282
msgid "Some example external resources are:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:290
msgid ""
"Like TSCN files, a TRES file may contain single-line comments starting with "
"a semicolon (``;``). However, comments will be discarded when saving the "
"resource using the Godot editor."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:297
msgid ""
"A TSCN file can contain meshes, materials and other data. These are "
"contained in the *internal resources* section of the file. The heading for "
"an internal resource looks similar to those of external resources, except "
"that it doesn't have a path. Internal resources also have ``key=value`` "
"pairs under each heading. For example, a capsule collision shape looks like:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:311
msgid ""
"Some internal resources contain links to other internal resources (such as a "
"mesh having a material). In this case, the referring resource must appear "
"*before* the reference to it. This means that order matters in the file's "
"internal resources section."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:316
msgid ""
"Unfortunately, documentation on the formats for these subresources isn't "
"complete. Some examples can be found by inspecting saved resource files, but "
"others can only be found by looking through Godot's source."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:323
msgid ""
"ArrayMesh consists of several surfaces, each in the format ``surface"
"\\Index={}``. Each surface is a set of vertices and a material."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:326
msgid "TSCN files support two surface formats:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:328
msgid "For the old format, each surface has three essential keys:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:330
msgid "``primitive``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:331
msgid "``arrays``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:332
msgid "``morph_arrays``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:334
msgid ""
"``primitive`` is an enumerate variable, ``primitive=4`` which is "
"``PRIMITIVE_TRIANGLES`` is frequently used."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:337
msgid "``arrays`` is a two-dimensional array, it contains:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:339
msgid "Vertex positions array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:340
msgid "Tangents array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:341
msgid "Vertex colors array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:342
msgid "UV array 1"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:343
msgid "UV array 2"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:344
msgid "Bone indexes array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:345
msgid "Bone weights array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:346
msgid "Vertex indexes array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:348
msgid ""
"``morph_arrays`` is an array of morphs. Each morph is exactly an ``arrays`` "
"without the vertex indexes array."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:351
msgid "An example of ArrayMesh:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:377
msgid ""
"An animation resource consists of tracks. Besides, it has ``length``, "
"``loop`` and ``step`` applied to all the tracks."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:380
msgid "``length`` and ``step`` are both durations in seconds."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:382
msgid ""
"Each track is described by a list of key-value pairs in the format ``tracks/"
"Id/Attribute``. Each track includes:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:385
msgid "``type``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:386
#, fuzzy
msgid "``path``"
msgstr "נתיב"

#: ../../docs/development/file_formats/tscn.rst:387
msgid "``interp``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:388
msgid "``keys``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:389
msgid "``loop_wrap``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:390
msgid "``imported``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:393
msgid ""
"The ``type`` must be the first attribute of each track. The value of "
"``type`` can be:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:396
#, fuzzy
msgid "``transform``"
msgstr "התמרה"

#: ../../docs/development/file_formats/tscn.rst:397
msgid "``value``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:398
msgid "``method``"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:400
msgid ""
"The ``path`` has the format ``NodePath(Path/To/Node:attribute)``. It's the "
"path to the animated node or attribute, relative to the root node defined in "
"the AnimationPlayer."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:404
msgid ""
"The ``interp`` is the method to interpolate frames from the keyframes. It is "
"an enum variable with one of the following values:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:407
#, fuzzy
msgid "``0`` (constant)"
msgstr "קבועים"

#: ../../docs/development/file_formats/tscn.rst:408
msgid "``1`` (linear)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:409
msgid "``2`` (cubic)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:411
msgid ""
"The ``keys`` correspond to the keyframes. It appears as a "
"``PoolRealArray()``, but may have a different structure for tracks with "
"different types."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:414
msgid ""
"A Transform track uses every 12 real numbers in the ``keys`` to describe a "
"keyframe. The first number is the timestamp. The second number is the "
"transition followed by a 3-number translation vector, followed by a 4-number "
"rotation quaternion (X, Y, Z, W) and finally a 3-number scale vector. The "
"default transition in a Transform track is 1.0."
msgstr ""

#: ../../docs/community/contributing/index.rst:2
msgid "Contributing"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:4
msgid "Ways to contribute"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:6
msgid ""
"Godot Engine is a non-profit, community-driven free and open source project. "
"Almost all (but our lead dev Juan, more on that below) developers are "
"working *pro bono* on their free time, out of personal interest and for the "
"love of creating a libre engine of exceptional quality."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:11
msgid ""
"This means that to thrive, Godot needs as many users as possible to get "
"involved by contributing to the engine. There are many ways to contribute to "
"such a big project, making it possible for everybody to bring something "
"positive to the engine, regardless of their skill set:"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:16
msgid ""
"**Be part of the community.** The best way to contribute to Godot and help "
"it become ever better is simply to use the engine and promote it by word-of-"
"mouth, in the credits or splash screen of your games, blog posts, tutorials, "
"videos, demos, gamedev or free software events, support on the Q&A, IRC, "
"forums, Discord, etc. Participate! Being a user and advocate helps spread "
"the word about our great engine, which has no marketing budget and can "
"therefore only rely on its community to become more mainstream."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:25
msgid ""
"**Make games.** It's no secret that, to convince new users and especially "
"the industry at large that Godot is a relevant market player, we need great "
"games made with Godot. We know that the engine has a lot of potential, both "
"for 2D and 3D games, but given its young age we still lack big releases that "
"will draw attention to Godot. So keep working on your awesome projects, each "
"new game increases our credibility on the gamedev market!"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:32
msgid ""
"**Get involved in the engine's development.** This can be by contributing "
"code via pull requests, testing the development snapshots or directly the "
"git *master* branch, report bugs or suggest enhancements on the issue "
"tracker, improve the official documentation (both the class reference and "
"tutorials) and its translations. The following sections will cover each of "
"those \"direct\" ways of contributing to the engine."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:40
msgid ""
"**Donate.** Godot is a non-profit project, but it can still benefit from "
"user donations for many things. Apart from usual expenses such as hosting "
"costs or promotional material on events, we also use donation money to "
"acquire hardware when necessary (e.g. we used donation money to buy a "
"MacBook Pro to implement Retina/HiDPI support and various other macOS-"
"related features). Most importantly, we also used donation money to hire "
"core developers so they can work full-time on the engine. Even with a low "
"monthly wage, we need a steady donation income to continue doing this, which "
"has been very beneficial to the project so far. So if you want to donate "
"some money to the project, check `our website <https://godotengine.org/"
"donate>`_ for details."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:54
msgid "Contributing code"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:56
msgid ""
"The possibility to study, use, modify and redistribute modifications of the "
"engine's source code are the fundamental rights that Godot's `MIT <https://"
"tldrlegal.com/license/mit-license>`_ license grants you, making it `free and "
"open source software <https://en.wikipedia.org/wiki/Free_and_open-"
"source_software>`_."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:61
msgid ""
"As such, everyone is entitled to modify `Godot's source code <https://github."
"com/godotengine/godot>`_, and send those modifications back to the upstream "
"project in the form of a patch (a text file describing the changes in a "
"ready-to-apply manner) or - in the modern workflow that we use - via a so-"
"called \"pull request\" (PR), i.e. a proposal to directly merge one or more "
"Git commits (patches) into the main development branch."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:68
msgid "Contributing code changes upstream has two big advantages:"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:70
msgid ""
"Your own code will be reviewed and improved by other developers, and will be "
"further maintained directly in the upstream project, so you won't have to "
"reapply your own changes every time you move to a newer version. On the "
"other hand it comes with a responsibility, as your changes have to be "
"generic enough to be beneficial to all users, and not just your project; so "
"in some cases it might still be relevant to keep your changes only for your "
"own project, if they are too specific."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:78
msgid ""
"The whole community will benefit from your work, and other contributors will "
"behave the same way, contributing code that will be beneficial to you. At "
"the time of this writing, more than 1000 developers have contributed code "
"changes to the engine!"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:83
msgid ""
"To ensure good collaboration and overall quality, the Godot developers "
"enforce some rules for code contributions, for example regarding the style "
"to use in the C++ code (indentation, brackets, etc.) or the Git and PR "
"workflow."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:87
msgid ""
"A good place to start is by searching for issues tagged as `junior jobs "
"<https://github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+label%3A"
"%22junior+job%22>`_ (or `Hacktoberfest <https://github.com/godotengine/godot/"
"issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3AHacktoberfest+>`_ "
"during October) on GitHub."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:89
msgid ""
"Technical details about the PR workflow are outlined in a specific section, :"
"ref:`doc_pr_workflow`."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:92
msgid ""
"Details about the code style guidelines and the ``clang-format`` tool used "
"to enforce them are outlined in :ref:`doc_code_style_guidelines`."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:97
msgid "Testing and reporting issues"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:99
msgid ""
"Another great way of contributing to the engine is to test development "
"releases or the development branch and to report issues. It is also helpful "
"to report issues discovered in stable releases, so that they can be fixed in "
"the development branch and in future maintenance releases."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:105
msgid "Testing development versions"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:107
msgid "To help with the testing, you have several possibilities:"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:109
msgid ""
"Compile the engine from source yourself, following the instructions of the :"
"ref:`Compiling <toc-devel-compiling>` page for your platform."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:112
msgid ""
"Test official pre-release binaries when they are announced (usually on the "
"blog and other community platforms), such as alpha, beta and release "
"candidate (RC) builds."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:115
msgid ""
"Test \"trusted\" unofficial builds of the development branch; just ask "
"community members for reliable providers. Whenever possible, it's best to "
"use official binaries or to compile yourself though, to be sure about the "
"provenance of your binaries."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:120
msgid ""
"As mentioned previously, it is also helpful to keep your eyes peeled for "
"potential bugs that might still be present in the stable releases, "
"especially when using some niche features of the engine which might get less "
"testing by the developers."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:126
msgid "Filing an issue on GitHub"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:128
msgid ""
"Godot uses `GitHub's issue tracker <https://github.com/godotengine/godot/"
"issues>`_ for bug reports and enhancement suggestions. You will need a "
"GitHub account to be able to open a new issue there, and click on the \"New "
"issue\" button."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:132
msgid ""
"When you report a bug, you should keep in mind that the process is similar "
"to an appointment with your doctor. You noticed *symptoms* that make you "
"think that something might be wrong (the engine crashes, some features don't "
"work as expected, etc.). It's the role of the bug triaging team and the "
"developers to then help make the diagnosis of the issue you met, so that the "
"actual cause of the bug can be identified and addressed."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:139
msgid ""
"You should therefore always ask yourself: what is relevant information to "
"give so that other Godot contributors can understand the bug, identify it "
"and hopefully fix it. Here are some of the most important infos that you "
"should always provide:"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:144
msgid ""
"**Operating system.** Sometimes bugs are system-specific, i.e. they happen "
"only on Windows, or only on Linux, etc. That's particularly relevant for all "
"bugs related to OS interfaces, such as file management, input, window "
"management, audio, etc."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:149
msgid ""
"**Hardware.** Sometimes bugs are hardware-specific, i.e. they happen only on "
"certain processors, graphic cards, etc. If you are able to, it can be "
"helpful to include information on your hardware."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:153
msgid ""
"**Godot version.** This is a must have. Some issues might be relevant in the "
"current stable release, but fixed in the development branch, or the other "
"way around. You might also be using an obsolete version of Godot and "
"experiencing a known issue fixed in a later version, so knowing this from "
"the start helps to speed up the diagnosis."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:159
msgid ""
"**How to reproduce the bug.** In the majority of cases, bugs are "
"reproducible, i.e. it is possible to trigger them reliably by following some "
"steps. Please always describe those steps as clearly as possible, so that "
"everyone can try to reproduce the issue and confirm it. Ideally, make a demo "
"project that reproduces this issue out of the box, zip it and attach it to "
"the issue (you can do this by drag and drop). Even if you think that the "
"issue is trivial to reproduce, adding a minimal project that lets reproduce "
"it is a big added value. You have to keep in mind that there are thousands "
"of issues in the tracker, and developers can only dedicate little time to "
"each issue."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:170
msgid ""
"When you click the \"New issue\" button, you should be presented with a text "
"area prefilled with our issue template. Please try to follow it so that all "
"issues are consistent and provide the required information."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:175
msgid "Contributing to the documentation"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:177
msgid ""
"There are two separate resources referred to as \"documentation\" in Godot:"
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:179
msgid ""
"**The class reference.** This is the documentation for the complete Godot "
"API as exposed to GDScript and the other scripting languages. It can be "
"consulted offline, directly in Godot's code editor, or online at :ref:`Godot "
"API <toc-class-ref>`. To contribute to the class reference, you have to edit "
"the `doc/base/classes.xml` in Godot's Git repository, and make a pull "
"request. See :ref:`doc_updating_the_class_reference` for more details."
msgstr ""

#: ../../docs/community/contributing/ways_to_contribute.rst:187
msgid ""
"**The tutorials and engine documentation and its translations.** This is the "
"part you are reading now, which is distributed in the HTML, PDF and EPUB "
"formats. Its contents are generated from plain text files in the "
"reStructured Text (rst) format, to which you can contribute via pull "
"requests on the `godot-docs <https://github.com/godotengine/godot-docs>`_ "
"GitHub repository. See :ref:`doc_documentation_guidelines` for more details."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:4
msgid "Best practices for engine contributors"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:9
msgid ""
"Godot has a large amount of users who have the ability to contribute, given "
"the project itself is aimed mainly at users with the ability to do "
"programming. Despite this, not all of them have the same level of experience "
"working in large projects or in software engineering, which can lead to "
"common misunderstandings and bad practices during the process of "
"contributing code to the project."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:14
msgid ""
"The scope of this document is to be a list of best practices for "
"contributors to follow, as well as to creating a language they can use to "
"refer to common situations that arise in the process of submitting their "
"contributions."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:16
msgid ""
"While some may find it useful to extend this to general software "
"development, our intention is to just restrict to situations that are most "
"common in our project."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:18
msgid ""
"Contributions are most of the time categorized as bug fixes, enhancements or "
"new features. To abstract this idea, we will call them *Solutions*, because "
"they always seek to solve something that can be described as a *Problem*."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:21
msgid "Best Practices"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:24
msgid "#1: The problem always comes first"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:26
msgid ""
"Many contributors are extremely creative and just enjoy the process of "
"designing abstract data structures, creating nice user interfaces, or simply "
"love programming. Whatever the case may be, they come up with cool ideas, "
"which may not be actually solving any actual problems."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:30
msgid ""
"These are usually called *Solutions in search of a problem*. In an ideal "
"world, they would not be harmful but, in reality, code takes time to write, "
"takes space as source and binary and requires maintenance once it exists. "
"Avoiding the addition of anything unnecessary is always considered a good "
"practice in software development."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:33
msgid "#2: The problem has to exist"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:35
msgid ""
"This is a variation of the previous practice. I believe most developers "
"agree that adding anything unnecessary is not a good idea, but what "
"constitutes what is necessary and what isn't?"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:39
msgid ""
"The answer to this question is that the problem needs to *exist*. It must "
"not be speculation or a belief. The user must be using the software as "
"intended to create something they *need*. In this process, the user may "
"stumble into a problem that requires a solution in order to continue, or in "
"order to achieve greater productivity. In this case, *a solution is needed*."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:41
msgid ""
"Believing that problems may arise in the future and that the software needs "
"to be ready to solve them by the time they appear is called *\"Future "
"proofing\"* and its characterized by lines of thought such as:"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:43
msgid "I think it would be useful for users to..."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:44
msgid "I think users will eventually need to..."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:46
msgid ""
"This is generally considered a bad habit, because trying to solve problems "
"that *don't actually exist* in the present will very often lead to code that "
"will be written but never used, or to code that is considerably more complex "
"to use and maintain than it needs to be."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:49
msgid "#3: The problem has to be complex or frequent"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:51
msgid ""
"Software is designed to solve problems, but we can't expect it to solve "
"*every problem that exists under the sun*. As a game engine, Godot will "
"solve problems for you, so it helps you to make games better and faster, but "
"it won't make the *entire game* for you. A line must be drawn somewhere."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:55
msgid ""
"Whether a problem is worth solving is determined by the difficulty the user "
"has to work around it. This difficulty can be expressed as:"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:57
msgid "The complexity of the problem"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:58
msgid "The frequency the problem"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:60
msgid ""
"If the problem is *too complex* for most users to solve, the software must "
"offer a ready-made solution for it. Likewise, if the problem is easy for the "
"user to workaround, offering such a solution is unnecessary and it's up to "
"the user to do it."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:62
msgid ""
"The exception, however, is when the user stumbles into this problem "
"*frequently enough* that having to do the simple solution every time becomes "
"an annoyance. In this case, the software must offer a solution to simplify "
"this use case."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:64
msgid ""
"In our experience, in most cases it's usually obvious to tell when a problem "
"is complex or frequent, but cases may arise where drawing this line is "
"difficult. This is why discussing with other developers (next point) is "
"always advised."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:67
msgid "#4: The solution must be discussed with others"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:69
msgid ""
"It is often the case that, when users stumble upon problems, they are only "
"immersed in their own project, so they will naturally try to solve the "
"problem from their own perspective, thinking only about their use case."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:71
msgid ""
"Because of this, user proposed solutions don't always contemplate other use "
"cases that developers are often aware of, so they are often biased towards "
"their own requirements."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:75
msgid ""
"For developers, the perspective is different. They may find the user's "
"problem too unique to justify a solution (instead of a user workaround), or "
"maybe they will suggest a partial (usually simpler or lower level) solution "
"that applies to a wider range of known problems, and leave the rest of the "
"solution up to the user."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:77
msgid ""
"In any case, before attempting a contribution, it is important to discuss "
"the actual problems with the other developers or contributors, so a better "
"agreement on implementation can be reached."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:79
msgid ""
"The only exception, in this case, is when an area of code has a clear owner "
"(agreed by the other contributors), who talks to users directly and has the "
"most knowledge to implement a solution directly."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:82
msgid "#5: To each problem, its own solution"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:84
msgid ""
"For programmers, it is always a most enjoyable challenge to find the most "
"optimal solutions to problems. Things, however, may go overboard sometimes "
"and programmers will try to come up with solutions that solve as many "
"problems as possible."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:86
msgid ""
"The situation will often take a turn for the worse when, in order to make "
"this solution appear even more fantastic and flexible, the pure speculation-"
"based problems (as described in #2) also make their appearance on stage."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:90
msgid ""
"The main problem is that, in reality, it rarely works this way. Most of the "
"time, just writing an individual solution to each problem results in code "
"that is simpler and more maintainable."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:92
msgid ""
"Additionally, solutions that target individual problems are better for the "
"users, as they find something that does exactly what they need, without "
"having to learn and remember a more complex system they will only need for "
"simple tasks."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:94
msgid ""
"Big and flexible solutions also have an additional drawback which is that, "
"over time, they are rarely flexible enough for all users, which keep "
"requesting more functions added (and making the API and codebase more and "
"more complex)."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:97
msgid "#6: Cater to common use cases, leave the door open for the rare ones"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:99
msgid ""
"This is a continuation of the previous point, which further explains why "
"this way of thinking and designing software is preferred."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:101
msgid ""
"As mentioned before (in point #2), it is very difficult for us (as human "
"beings who design software) to actually understand all future user needs. "
"Trying to write very flexible structures that cater to many use cases at "
"once is often a mistake."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:103
msgid ""
"We may come up with something we believe is brilliant, but when it's "
"actually used, we will find that users will never even use half of it, or "
"that they will require features that don't quite accommodate our original "
"design, forcing us to either throw it away or make it even more complex."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:105
msgid ""
"The question is then, how to design software that gives users what *we know "
"they need*, but that is flexible enough to allow them to do *what we don't "
"know they might need* in the future?"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:109
msgid ""
"The answer to this question is that, to ensure users still can do what they "
"want to do, we need to give them access to a *low level API* that they can "
"use to achieve what they want, even if it's more work for them because it "
"means reimplementing some logic that already exists."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:111
msgid ""
"In real-life scenarios, these use cases will be at most rare and uncommon "
"anyway, so it makes sense a custom solution needs to be written. This is why "
"it's important to still provide users the basic building blocks to do it."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:114
msgid "#7: Solutions must be local"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:116
msgid ""
"When looking for a solution to a problem, be it implementing a new feature "
"or fixing a bug, sometimes the easiest path is to add data or a new function "
"in the core layers of code."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:118
msgid ""
"The main problem here is, adding something to the core layers that will only "
"be used from a single location far away will not only make the code more "
"difficult to follow (split in two), but also make the core API larger, more "
"complex, more difficult to understand in general."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:120
msgid ""
"This is bad, because readability and cleanness of core APIs is always of "
"extreme importance given how much code relies on it, and because it's key "
"for new contributors as a starting point to learning the codebase."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:126
msgid ""
"The common reasoning for wanting to do this is that it's usually less code "
"to simply add a hack in the core layers."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:128
msgid ""
"Despite this, this practice is not advised. Generally, the code for a "
"solution should be closer to where the problem originates, even if it "
"involves more code, duplicated, more complex or is less efficient. More "
"creativity might be needed, but this path is always the advised one."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:131
msgid "#8: Don't use complex canned solutions for simple problems"
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:133
msgid ""
"Not every problem has a simple solution and, many times, the right choice is "
"to use a third party library to solve the problem."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:135
msgid ""
"As Godot requires to be shipped in a large amount of platforms, we just "
"can't link libraries dynamically. Instead, we bundle them in our source tree."
msgstr ""

#: ../../docs/community/contributing/best_practices_for_engine_contributors.rst:139
msgid ""
"As a result, we are very picky with what goes in, and we tend to prefer "
"smaller libraries (in fact, single header ones are our favorite). Only in "
"cases where there is no other choice we end up bundling something larger."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:4
msgid "Pull request workflow"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:8
msgid ""
"The so-called \"PR workflow\" used by Godot is common to many projects using "
"Git, and should be familiar to veteran free software contributors. The idea "
"is that only a small number (if any) commit directly to the *master* branch. "
"Instead, contributors *fork* the project (i.e. create a copy of it, which "
"they can modify as they wish), and then use the GitHub interface to request "
"a *pull* from one of their fork's branches to one branch of the original "
"(often named *upstream*) repository."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:16
msgid ""
"The resulting *pull request* (PR) can then be reviewed by other "
"contributors, which might approve it, reject it, or most often request that "
"modifications be done. Once approved, the PR can then be merged by one of "
"the core developers, and its commit(s) will become part of the target branch "
"(usually the *master* branch)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:22
msgid ""
"We will go together through an example to show the typical workflow and "
"associated Git commands. But first, let's have a quick look at the "
"organization of Godot's Git repository."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:27
msgid "Git source repository"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:29
msgid ""
"The `repository on GitHub <https://github.com/godotengine/godot>`_ is a `Git "
"<https://git-scm.com>`_ code repository together with an embedded issue "
"tracker and PR system."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:33
msgid ""
"If you are contributing to the documentation, its repository can be found "
"`here <https://github.com/godotengine/godot-docs>`_."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:36
msgid ""
"The Git version control system is the tool used to keep track of successive "
"edits to the source code - to contribute efficiently to Godot, learning the "
"basics of the Git command line is *highly* recommended. There exist some "
"graphical interfaces for Git, but they usually encourage users to take bad "
"habits regarding the Git and PR workflow, and we therefore recommend not to "
"use them. In particular, we advise not to use GitHub's online editor for "
"code contributions (although it's tolerated for small fixes or documentation "
"changes) as it enforces one commit per file and per modification, which "
"quickly leads to PRs with an unreadable Git history (especially after peer "
"review)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:46
msgid ""
"The first sections of Git's \"Book\" are a good introduction to the tool's "
"philosophy and the various commands you need to master in your daily "
"workflow. You can read them online on the `Git SCM <https://git-scm.com/book/"
"en/v2>`_ website."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:51
msgid "The branches on the Git repository are organized as follows:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:53
msgid ""
"The ``master`` branch is where the development of the next major version "
"occurs. As a development branch, it can be unstable and is not meant for use "
"in production. This is where PRs should be done in priority."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:57
msgid ""
"The stable branches are named after their version, e.g. ``3.1`` and ``2.1``. "
"They are used to backport bugfixes and enhancements from the ``master`` "
"branch to the currently maintained stable release (e.g. 3.1.2 or 2.1.6). As "
"a rule of thumb, the last stable branch is maintained until the next major "
"version (e.g. the ``3.0`` branch was maintained until the release of Godot "
"3.1). If you want to make PRs against a maintained stable branch, please "
"check first if your changes are also relevant for the ``master`` branch, and "
"if so make the PR for the ``master`` branch in priority. Release managers "
"can then cherry-pick the fix to a stable branch if relevant."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:67
msgid ""
"There might occasionally be feature branches, usually meant to be merged "
"into the ``master`` branch at some time."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:71
msgid "Forking and cloning"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:73
msgid ""
"The first step is to *fork* the `godotengine/godot <https://github.com/"
"godotengine/godot>`_ repository on GitHub. To do so, you will need to have a "
"GitHub account and to be logged in. In the top right corner of the "
"repository's GitHub page, you should see the \"Fork\" button as shown below:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:80
msgid ""
"Click it, and after a while you should be redirected to your own fork of the "
"Godot repo, with your GitHub username as namespace:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:85
msgid ""
"You can then *clone* your fork, i.e. create a local copy of the online "
"repository (in Git speak, the *origin remote*). If you haven't already, "
"download Git from `its website <https://git-scm.com>`_ if you're using "
"Windows or macOS, or install it through your package manager if you're using "
"Linux."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:90
msgid ""
"If you are on Windows, open Git Bash to type commands. macOS and Linux users "
"can use their respective terminals."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:93
msgid "To clone your fork from GitHub, use the following command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:99
msgid ""
"In our examples, the \"$\" character denotes the command line prompt on "
"typical UNIX shells. It is not part of the command and should not be typed."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:103
msgid ""
"After a little while, you should have a ``godot`` directory in your current "
"working directory. Move into it using the ``cd`` command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:110
msgid ""
"We will start by setting up a reference to the original repository that we "
"forked:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:117
msgid ""
"This will create a reference named ``upstream`` pointing to the original "
"``godotengine/godot`` repository. This will be useful when you want to pull "
"new commits from its ``master`` branch to update your fork. You have another "
"remote reference named ``origin``, which points to your fork (``USERNAME/"
"godot``)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:122
msgid ""
"You only need to do the above steps once, as long as you keep that local "
"``godot`` folder (which you can move around if you want, the relevant "
"metadata is hidden in its ``.git`` subfolder)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:126
msgid ""
"*Branch it, pull it, code it, stage it, commit, push it, rebase it... "
"technologic.*"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:129
msgid ""
"This bad take on Daft Punk's *Technologic* shows the general conception Git "
"beginners have of its workflow: lots of strange commands to learn by copy "
"and paste, hoping they will work as expected. And that's actually not a bad "
"way to learn, as long as you're curious and don't hesitate to question your "
"search engine when lost, so we will give you the basic commands to know when "
"working in Git."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:137
msgid ""
"In the following, we will assume as an example that you want to implement a "
"feature in Godot's project manager, which is coded in the ``editor/"
"project_manager.cpp`` file."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:142
msgid "Branching"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:144
msgid ""
"By default, the ``git clone`` should have put you on the ``master`` branch "
"of your fork (``origin``). To start your own feature development, we will "
"create a feature branch:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:156
msgid "This command is equivalent:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:163
msgid "If you want to go back to the ``master`` branch, you'd use:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:169
msgid ""
"You can see which branch you are currently on with the ``git branch`` "
"command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:179
msgid ""
"Be sure to always go back to the ``master`` branch before creating a new "
"branch, as your current branch will be used as the base for the new one. "
"Alternatively, you can specify a custom base branch after the new branch's "
"name:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:188
msgid "Updating your branch"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:190
msgid ""
"This would not be needed the first time (just after you forked the upstream "
"repository). However, the next time you want to work on something, you will "
"notice that your fork's ``master`` is several commits behind the upstream "
"``master`` branch: pull requests from other contributors would have been "
"merged in the meantime."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:196
msgid ""
"To ensure there won't be conflicts between the feature you develop and the "
"current upstream ``master`` branch, you will have to update your branch by "
"*pulling* the upstream branch."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:204
msgid ""
"The ``--rebase`` argument will ensure that any local changes that you "
"committed will be re-applied *on top* of the pulled branch, which is usually "
"what we want in our PR workflow. This way, when you open a pull request, "
"your own commits will be the only difference with the upstream ``master`` "
"branch."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:209
msgid ""
"While rebasing, conflicts may arise if your commits modified code that has "
"been changed in the upstream branch in the meantime. If that happens, Git "
"will stop at the conflicting commit and will ask you to resolve the "
"conflicts. You can do so with any text editor, then stage the changes (more "
"on that later), and proceed with ``git rebase --continue``. Repeat the "
"operation if later commits have conflicts too, until the rebase operation "
"completes."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:216
msgid ""
"If you're unsure about what is going on during a rebase and you panic (no "
"worry, we all do the first few times), you can abort the rebase with ``git "
"rebase --abort``. You will then be back to the original state of your branch "
"before calling ``git pull --rebase``."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:221
msgid ""
"If you omit the ``--rebase`` argument, you will instead create a merge "
"commit which tells Git what to make of the two distinct branches. If any "
"conflicts arise, they would be resolved all at once via this merge commit."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:225
msgid ""
"While this is a valid workflow and the default behavior of ``git pull``, "
"merge commits within PRs are frowned upon in our PR workflow. We only use "
"them when merging PRs into the upstream branch."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:229
msgid ""
"The philosophy is that a PR should represent the final stage of the changes "
"made to the codebase, and we are not interested in mistakes and fixes that "
"would have been done in intermediate stages before merging. Git gives us "
"great tools to \"rewrite the history\" and make it as if we got things right "
"the first time, and we're happy to use it to ensure that changes are easy to "
"review and understand long after they have been merged."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:236
msgid ""
"If you have already created a merge commit without using ``rebase``, or have "
"made any other changes that have resulted in undesired history, the best "
"option is to use an *interactive rebase* on the upstream branch. See the :"
"ref:`dedicated section <doc_pr_workflow_rebase>` for instructions."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:241
msgid ""
"If at any time you want to *reset* a local branch to a given commit or "
"branch, you can do so with ``git reset --hard <commit ID>`` or ``git reset --"
"hard <remote>/<branch>`` (e.g. ``git reset --hard upstream/master``)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:245
msgid ""
"Be warned that this will remove any changes that you might have committed in "
"this branch. If you ever lose commits by mistake, use the ``git reflog`` "
"command to find the commit ID of the previous state that you would like to "
"restore, and use it as argument of ``git reset --hard`` to go back to that "
"state."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:251
msgid "Making changes"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:253
msgid ""
"You would then do your changes to our example's ``editor/project_manager."
"cpp`` file with your usual development environment (text editor, IDE, etc.)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:257
msgid ""
"By default, those changes are *unstaged*. The staging area is a layer "
"between your working directory (where you make your modifications) and the "
"local Git repository (the commits and all the metadata in the ``.git`` "
"folder). To bring changes from the working directory to the Git repository, "
"you need to *stage* them with the ``git add`` command, and then to commit "
"them with the ``git commit`` command."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:264
msgid ""
"There are various commands you should know to review your current work, "
"before staging it, while it is staged, and after it has been committed."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:267
msgid ""
"``git diff`` will show you the current unstaged changes, i.e. the "
"differences between your working directory and the staging area."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:269
msgid ""
"``git checkout -- <files>`` will undo the unstaged changes to the given "
"files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:271
msgid "``git add <files>`` will *stage* the changes on the listed files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:272
msgid ""
"``git diff --staged`` will show the current staged changes, i.e. the "
"differences between the staging area and the last commit."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:274
msgid "``git reset HEAD <files>`` will *unstage* changes to the listed files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:275
msgid ""
"``git status`` will show you what are the currently staged and unstaged "
"modifications."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:277
msgid ""
"``git commit`` will commit the staged files. It will open a text editor (you "
"can define the one you want to use with the ``GIT_EDITOR`` environment "
"variable or the ``core.editor`` setting in your Git configuration) to let "
"you write a commit log. You can use ``git commit -m \"Cool commit log\"`` to "
"write the log directly."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:282
msgid ""
"``git commit --amend`` lets you amend the last commit with your currently "
"staged changes (added with ``git add``). This is the best option if you want "
"to fix a mistake in the last commit (bug, typo, style issue, etc.)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:285
msgid ""
"``git log`` will show you the last commits of your current branch. If you "
"did local commits, they should be shown at the top."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:287
msgid ""
"``git show`` will show you the changes of the last commit. You can also "
"specify a commit hash to see the changes for that commit."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:290
msgid ""
"That's a lot to memorize! Don't worry, just check this cheat sheet when you "
"need to make changes, and learn by doing."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:293
msgid "Here's how the shell history could look like on our example:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:325
msgid ""
"With this, we should have two new commits in our ``better-project-manager`` "
"branch which were not in the ``master`` branch. They are still only local "
"though, the remote fork does not know about them, nor does the upstream repo."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:330
msgid "Pushing changes to a remote"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:332
msgid ""
"That's where ``git push`` will come into play. In Git, a commit is always "
"done in the local repository (unlike Subversion where a commit will modify "
"the remote repository directly). You need to *push* the new commits to a "
"remote branch to share them with the world. The syntax for this is:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:341
msgid ""
"The part about the remote branch can be omitted if you want it to have the "
"same name as the local branch, which is our case in this example, so we will "
"do:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:349
msgid ""
"Git will ask you for your username and password, and the changes will be "
"sent to your remote. If you check the fork's page on GitHub, you should see "
"a new branch with your added commits."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:354
msgid "Issuing a pull request"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:356
msgid ""
"When you load your fork's branch on GitHub, you should see a line saying *"
"\"This branch is 2 commits ahead of godotengine:master.\"* (and potentially "
"some commits behind, if your ``master`` branch was out of sync with the "
"upstream ``master`` branch)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:363
msgid ""
"On that line, there is a \"Pull request\" link. Clicking it will open a form "
"that will let you issue a pull request on the ``godotengine/godot`` upstream "
"repository. It should show you your two commits, and state \"Able to merge"
"\". If not (e.g. it has way more commits, or says there are merge "
"conflicts), don't create the PR, something went wrong. Go to IRC and ask for "
"support :)"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:369
msgid ""
"Use an explicit title for the PR and put the necessary details in the "
"comment area. You can drag and drop screenshots, GIFs or zipped projects if "
"relevant, to showcase what your work implements. Click \"Create a pull "
"request\", and tadaa!"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:375
msgid "Modifying a pull request"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:377
msgid ""
"While it is reviewed by other contributors, you will often need to make "
"changes to your yet-unmerged PR, either because contributors requested them, "
"or because you found issues yourself while testing."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:381
msgid ""
"The good news is that you can modify a pull request simply by acting on the "
"branch you made the pull request from. You can e.g. make a new commit on "
"that branch, push it to your fork, and the PR will be updated automatically:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:396
msgid ""
"However, be aware that in our PR workflow, we favor commits that bring the "
"codebase from one functional state to another functional state, without "
"having intermediate commits fixing up bugs in your own code or style issues. "
"Most of the time, we will prefer a single commit in a given PR (unless "
"there's a good reason to keep the changes separate), so instead of authoring "
"a new commit, considering using ``git commit --amend`` to amend the previous "
"commit with your fixes. The above example would then become:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:426
msgid "The interactive rebase"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:428
msgid ""
"If you didn't follow the above steps closely to *amend* changes into a "
"commit instead of creating fixup commits, or if you authored your changes "
"without being aware of our workflow and Git usage tips, reviewers might "
"request of your to *rebase* your branch to *squash* some or all of the "
"commits into one."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:433
msgid ""
"Indeed, if some commits have been made following reviews to fix bugs, typos, "
"etc. in the original commit, they are not relevant to a future changelog "
"reader who would want to know what happened in the Godot codebase, or when "
"and how a given file was last modified."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:438
msgid ""
"To squash those extraneous commits into the main one, we will have to "
"*rewrite history*. Right, we have that power. You may read that it's a bad "
"practice, and it's true when it comes to branches of the upstream repo. But "
"in your fork, you can do whatever you want, and everything is allowed to get "
"neat PRs :)"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:443
msgid ""
"We will use the *interactive rebase* ``git rebase -i`` to do this. This "
"command takes a commit ID or a branch name as argument, and will let you "
"modify all commits between that commit/branch and the last one in your "
"working branch, the so-called ``HEAD``."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:448
msgid ""
"While you can give any commit ID to ``git rebase -i`` and review everything "
"in between, the most common and convenient workflow involves rebasing on the "
"*upstream ``master`` branch*, which you can do with:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:456
msgid ""
"Referencing branches in Git is a bit tricky due to the distinction between "
"remote and local branches. Here, ``upstream/master`` (with a `/`) is a local "
"branch which has been pulled from the ``upstream`` remote's ``master`` "
"branch."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:461
msgid ""
"Interactive rebases can only be done on local branches, so the `/` is "
"important here. As the upstream remote changes frequently, your local "
"``upstream/master`` branch may become outdated, so you can update it with "
"``git fetch upstream master``. Contrarily to ``git pull --rebase upstream "
"master`` which would update your currently checked out branch, ``fetch`` "
"will only update the ``upstream/master`` reference (which is distinct from "
"your local ``master`` branch... yes it's confusing, but you'll become "
"familiar with this little by little)."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:471
msgid ""
"This will open a text editor (``vi`` by default, see `Git docs <https://git-"
"scm.com/book/en/v2/Customizing-Git-Git-Configuration#_core_editor>__` to "
"configure your favorite one) with something which may look like this:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:480
msgid ""
"The editor will also show instructions regarding how you can act on those "
"commits. In particular, it should tell you that \"pick\" means to use that "
"commit (do nothing), and that \"squash\" and \"fixup\" can be used to *meld* "
"the commit in its parent commit. The difference between \"squash\" and "
"\"fixup\" is that \"fixup\" will discard the commit log from the squashed "
"commit. In our example, we are not interested in keeping the log of the "
"\"Fix a typo\" commit, so we use:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:493
msgid ""
"Upon saving and quitting the editor, the rebase will occur. The second "
"commit will be melded into the first one, and ``git log`` and ``git show`` "
"should now confirm that you have only one commit with the changes from both "
"previous commits."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:498
msgid ""
"But! You rewrote the history, and now your local and remote branches have "
"diverged. Indeed, commit 1b4aad7 in the above example will have changed, and "
"therefore got a new commit hash. If you try to push to your remote branch, "
"it will raise an error:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:512
msgid ""
"This is a sane behavior, Git will not let you push changes that would "
"override remote content. But that's actually what we want to do here, so we "
"will have to *force* it:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:520
msgid ""
"And tadaa! Git will happily *replace* your remote branch with what you had "
"locally (so make sure that's what you wanted, using ``git log``). This will "
"also update the PR accordingly."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:525
msgid "Deleting a Git branch"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:527
msgid ""
"After your pull request gets merged, there's one last thing you should do: "
"delete your Git branch for the PR. There won't be issues if you don't delete "
"your branch, but it's good practice to do so. You'll need to do this twice, "
"once for the local branch and another for the remote branch on GitHub."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:532
msgid "To delete our better project manager branch locally, use this command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:538
msgid ""
"Alternatively, if the branch hadn't been merged yet and we wanted to delete "
"it anyway, instead of ``-d`` you would use ``-D``."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:541
msgid "Next, to delete the remote branch on GitHub use this command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:547
msgid ""
"You can also delete the remote branch from the GitHub PR itself, a button "
"should appear once it has been merged or closed."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:4
msgid "Bisecting regressions"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:8
msgid ""
"Bisecting is a way to find regressions in software. After reporting a bug on "
"the `Godot repository on GitHub <https://github.com/godotengine/godot>`__, "
"you may be asked by a contributor to *bisect* the issue. Bisecting makes it "
"possible for contributors to fix bugs faster, as they can know in advance "
"which commit caused the regression. Your effort will be widely appreciated :)"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:14
msgid "The guide below explains how to find a regression by bisecting."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:17
msgid "What is bisecting?"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:19
msgid ""
"Godot developers use the `Git <https://git-scm.com/>`__ version control "
"system. In the context of Git, bisecting is the process of performing a "
"manual `binary search <https://en.wikipedia.org/wiki/"
"Binary_search_algorithm>`__ to determine when a regression appeared. While "
"it's typically used for bugs, it can also be used to find other kinds of "
"unexpected changes such as performance regressions."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:27
msgid "Using official builds to speed up bisecting"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:29
msgid ""
"Before using Git's ``bisect`` command, we strongly recommend trying to "
"reproduce the bug with an older (or newer) official release. This greatly "
"reduces the range of commits that potentially need to be built from source "
"and tested. You can find binaries of official releases, as well as alphas, "
"betas, and release candidates `here <https://downloads.tuxfamily.org/"
"godotengine/>`__."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:35
msgid ""
"For example, if you've reported a bug against Godot 3.2, you should first "
"try to reproduce the bug in Godot 3.1 (not a patch release, see below for "
"the reason). If the bug doesn't occur there, try to reproduce it in Godot "
"3.2 *beta 1* (which is roughly in the middle of all test builds available). "
"If you can't reproduce the bug with Godot 3.2 beta 1, then try newer betas "
"and RC builds. If you do manage to reproduce the bug with Godot 3.2 beta 1, "
"then try older alpha builds."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:44
msgid ""
"For bisecting regressions, don't use patch releases such as Godot 3.1.2. "
"Instead, use the minor version's first release like Godot 3.1. This is "
"because patch releases are built from a separate *stable branch*. This kind "
"of branch doesn't follow the rest of Godot's development, which is done in "
"the ``master`` branch."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:51
msgid "The Git bisect command"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:53
msgid ""
"If you've found a build that didn't exhibit the bug in the above testing "
"process, you can now start bisecting the regression. The Git version control "
"system offers a built-in command for this: ``git bisect``. This makes the "
"process semi-automated as you only have to build the engine, run it and try "
"to reproduce the bug."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:61
msgid ""
"Before bisecting a regression, you need to set up a build environment to "
"compile Godot from source. To do so, read the :ref:`Compiling <toc-devel-"
"compiling>` page for your target platform. (Compiling Godot from source "
"doesn't require C++ programming knowledge.)"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:66
msgid ""
"Note that compiling Godot can take a while on slow hardware (up an hour for "
"each full rebuild on a slow dual-core CPU). This means the full process can "
"take up to several hours. If your hardware is too slow, you may want to stop "
"there and report the results of your \"pre-bisecting\" on the GitHub issue "
"so another contributor can continue bisecting from there."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:72
msgid ""
"To start bisecting, you must first determine the commit hashes (identifiers) "
"of the \"bad\" and \"good\" build. \"bad\" refers to the build that exhibits "
"the bug, whereas \"good\" refers to the version that doesn't exhibit the "
"bug. If you're using a pre-release build as the \"good\" or \"bad\" build, "
"browse the `download mirror <https://downloads.tuxfamily.org/godotengine/"
">`__, go to the folder that contains the pre-release you downloaded and look "
"for the ``README.txt`` file. The commit hash is written inside that file."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:80
msgid ""
"If you're using a stable release as the \"good\" or \"bad\" build, use one "
"of the following commit hashes depending on the version:"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:89
msgid ""
"To refer to the latest state of the master branch, you can use ``master`` "
"instead of a commit hash."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:92
msgid ""
":ref:`Get Godot's source code using Git <doc_getting_source>`. Once this is "
"done, in the terminal window, use ``cd`` to reach the Godot repository "
"folder and enter the following command:"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:102
msgid "Compile Godot. This assumes you've set up a build environment:"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:110
msgid ""
"Since building Godot takes a while, you want to dedicate as many CPU threads "
"as possible to the task. This is what the ``-j`` parameter does. Here, the "
"command assigns 4 CPU threads to compiling Godot."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:114
msgid ""
"Run the binary located in the ``bin/`` folder and try to reproduce the bug."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:116
msgid "If the build **still** exhibits the bug, run the following command:"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:122
msgid "If the build **does not** exhibit the bug, run the following command:"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:128
msgid ""
"After entering one of the commands above, Git will switch to a different "
"commit. You should now build Godot again, try to reproduce the bug, then "
"enter ``git bisect good`` or ``git bisect bad`` depending on the result. "
"You'll have to repeat this several times. The longer the commit range, the "
"more steps will be required. 5 to 10 steps are usually sufficient to find "
"most regressions; Git will remind you of the number of steps remaining (in "
"the worst case scenario)."
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:135
msgid ""
"Once you've completed enough steps, Git will display the commit hash where "
"the regression appeared. Write this commit hash as a comment to the GitHub "
"issue you've bisected. This will help in solving the issue. Thanks again for "
"contributing to Godot :)"
msgstr ""

#: ../../docs/community/contributing/bisecting_regressions.rst:142
msgid ""
"You can read the full documentation on ``git bisect`` `here <https://git-scm."
"com/docs/git-bisect>`__."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:4
msgid "Code style guidelines"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:8
msgid ""
"When contributing to Godot's source code, you will be expected to follow the "
"style guidelines outlined below. Some of them are checked via the Continuous "
"Integration process and reviewers will ask you to fix potential issues, so "
"best setup your system as outlined below to ensure all your commits follow "
"the guidelines."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:15
msgid "C++ and Objective-C"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:17
msgid ""
"There are no written guidelines, but the code style agreed upon by the "
"developers is enforced via the `clang-format <http://clang.llvm.org/docs/"
"ClangFormat.html>`__ code beautifier, which takes care for you of all our "
"conventions. To name a few:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:22
msgid ""
"Indentation and alignment are both tab based (respectively one and two tabs)"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:23
msgid "One space around math and assignments operators as well as after commas"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:24
msgid ""
"Pointer and reference operators are affixed to the variable identifier, not "
"to the type name"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:26
msgid "See further down regarding header includes"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:28
msgid ""
"The rules used by clang-format are outlined in the `.clang-format <https://"
"github.com/godotengine/godot/blob/master/.clang-format>`__ file of the Godot "
"repository."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:32
msgid ""
"As long as you ensure that your style matches the surrounding code and that "
"you not introducing trailing whitespace or space-based indentation, you "
"should be fine. If you plan to contribute regularly however, we strongly "
"advise that you setup clang-format locally to check and automatically fix "
"all your commits."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:37
msgid ""
"Godot's code style should *not* be applied to third-party code, i.e. that is "
"included in Godot's source tree but was not written specifically for our "
"project. Such code usually come from different upstream projects with their "
"own style guides (or lack thereof), and don't want to introduce differences "
"that would make syncing with upstream repositories harder."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:44
msgid ""
"Third-party code is usually included in the ``thirdparty/`` folder and can "
"thus easily be excluded from formatting scripts. For the rare cases where a "
"third-party code snippet needs to be included directly within a Godot file, "
"you can use ``/* clang-format off */`` and ``/* clang-format on */`` to tell "
"clang-format to ignore a chunk of code."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:52
msgid "Using clang-format locally"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:54
msgid ""
"First of all, you will need to install clang-format. As of now, you need to "
"use **clang-format 8.x** to be compatible with Godot's format. Later "
"versions might be suitable, but previous versions had bugs that will cause "
"formatting changes to the current code base."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:60
msgid "Installation"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:62
msgid "Here's how to install clang-format:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:64
msgid ""
"Linux: It will usually be available out-of-the-box with the clang toolchain "
"packaged by your distribution. If your distro version is not the required "
"one, you can download a pre-compiled version from the `LLVM website <http://"
"releases.llvm.org/download.html>`__, or if you are on a Debian derivative, "
"use the `upstream repos <http://apt.llvm.org/>`__."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:69
msgid ""
"macOS and Windows: You can download precompiled binaries from the `LLVM "
"website <http://releases.llvm.org/download.html>`__. You may need to add the "
"path to the binary's folder to your system's ``PATH`` environment variable "
"to be able to call ``clang-format`` out of the box."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:74
msgid ""
"You then have different possibilities to apply clang-format to your changes:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:77
msgid "Manual usage"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:79
msgid ""
"You can apply clang-format manually one or more files with the following "
"command:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:86
msgid ""
"``-i`` means that the changes should be written directly to the file (by "
"default clang-format would only output the fixed version to the terminal)."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:88
msgid ""
"The path can point to several files, either one after the other or using "
"wildcards like in a typical Unix shell. Be careful when globbing so that you "
"don't run clang-format on compiled objects (.o and .a files) that are in "
"Godot's tree. So better use ``core/*.{cpp,h}`` than ``core/*``."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:94
msgid "Pre-commit hook"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:96
msgid ""
"For ease of use, we provide a pre-commit hook for Git that will run clang-"
"format automatically on all your commits to check them, and let you apply "
"its changes in the final commit."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:100
msgid ""
"This \"hook\" is a script which can be found in ``misc/hooks``, refer to "
"that folder's README.md for installation instructions."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:103
msgid ""
"If your clang-format is not in the ``PATH``, you may have to edit the ``pre-"
"commit-clang-format`` to point to the correct binary for it to work. The "
"hook was tested on Linux and macOS, but should also work in the Git Shell on "
"Windows."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:109
msgid "IDE plugin"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:111
msgid ""
"Most IDEs or code editors have beautifier plugins that can be configured to "
"run clang-format automatically, for example each time you save a file."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:114
msgid "Here is a non-exhaustive list of beautifier plugins for some IDEs:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:116
msgid ""
"Qt Creator: `Beautifier plugin <http://doc.qt.io/qtcreator/creator-"
"beautifier.html>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:117
msgid ""
"Visual Studio Code: `Clang-Format <https://marketplace.visualstudio.com/"
"items?itemName=xaver.clang-format>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:118
msgid ""
"Visual Studio: `ClangFormat <https://marketplace.visualstudio.com/items?"
"itemName=LLVMExtensions.ClangFormat>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:119
msgid "vim: `vim-clang-format <https://github.com/rhysd/vim-clang-format>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:121
msgid "(Pull requests welcome to extend this list with tested plugins.)"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:124
msgid "Header includes"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:126
msgid ""
"When adding new C++ or Objective-C files or including new headers in "
"existing ones, the following rules should be followed:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:129
msgid ""
"The first lines in the file should be Godot's copyright header and MIT "
"license, copy-pasted from another file. Make sure to adjust the filename."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:131
msgid ""
"In a ``.h`` header, include guards should be used with the form "
"``FILENAME_H``."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:134
msgid ""
"In a ``.cpp`` file (e.g. ``filename.cpp``), the first include should be the "
"one where the class is declared (e.g. ``#include \"filename.h\"``), followed "
"by an empty line for separation."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:137
msgid ""
"Then come headers from Godot's own code base, included in alphabetical order "
"(enforced by ``clang-format``) with paths relative to the root folder. Those "
"includes should be done with quotes, e.g. ``#include \"core/object.h\"``. "
"The block of Godot header includes should then be followed by an empty line "
"for separation."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:142
msgid ""
"Finally, third-party headers (either from ``thirdparty`` or from the "
"system's include paths) come next and should be included with the < and > "
"symbols, e.g. ``#include <png.h>``. The block of third-party headers should "
"also be followed by an empty line for separation."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:146
msgid ""
"Godot and third-party headers should be included in the file that requires "
"them, i.e. in the `.h` header if used in the declarative code or in the `."
"cpp` if used only in the imperative code."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:238
msgid "Java"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:240
msgid ""
"Godot's Java code (mostly in ``platform/android``) is also enforced via "
"``clang-format``, so see the instructions above to set it up. Keep in mind "
"that this style guide only applies to code written and maintained by Godot, "
"not third-party code such as the ``java/src/com/google`` subfolder."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:246
msgid "Python"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:248
msgid ""
"Godot's SCons buildsystem is written in Python, and various scripts included "
"in the source tree are also using Python."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:251
msgid ""
"For those, we follow the `PEP-8 style guide <https://www.python.org/dev/peps/"
"pep-0008/>`__, this is however not as strongly enforced as for the C++ code. "
"If you are so inclined, you can check and format your Python changes using "
"`autopep8 <https://pypi.org/project/autopep8/>`__."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:4
msgid "Bug triage guidelines"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:6
msgid ""
"This page describes the typical workflow of the bug triage team aka bugsquad "
"when handling issues and pull requests on Godot's `GitHub <https://github."
"com/godotengine/godot>`_ repository. It is bound to evolve together with the "
"bugsquad, so do not hesitate to propose modifications to the following "
"guidelines."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:12
msgid "Issues management"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:14
msgid "GitHub proposes various features to manage issues:"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:16
msgid "Set one or several labels from a predefined list"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:17
msgid "Set one milestone from a predefined list"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:18
msgid "Keep track of the issue in the project dashboard"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:19
msgid ""
"Define one contributor as \"assignee\" among the Godot engine organization "
"members"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:22
msgid ""
"As the Godot engine organization on GitHub currently has a restricted number "
"of contributors, we do not use assignees extensively for now. All "
"contributors are welcome to take on any issue, if relevant after mentioning "
"it on the issue ticket and/or discussing the best way to resolve it with "
"other developers."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:28
msgid "For the time being we do not use the project dashboard feature either."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:30
msgid ""
"As far as possible, we try to assign labels (and milestones, when relevant) "
"to both issues and pull requests."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:34
msgid "Labels"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:36
msgid "The following labels are currently defined in the Godot repository:"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:38
msgid "**Categories:**"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:40
msgid ""
"*Archived*: either a duplicate of another issue, or invalid. Such an issue "
"would also be closed."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:42
msgid "*Bug*: describes something that is not working properly."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:43
msgid ""
"*Confirmed*: has been confirmed by at least one other contributor than the "
"bug reporter (typically for *Bug* reports). The purpose of this label is to "
"let developers know which issues are still reproducible when they want to "
"select what to work on. It is therefore a good practice to add in a comment "
"on what platform and what version or commit of Godot the issue could be "
"reproduced; if a developer looks at the issue one year later, the "
"*Confirmed* label may not be relevant anymore."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:51
msgid ""
"*Discussion*: the issue is not consensual and needs further discussion to "
"define what exactly should be done to address the topic."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:54
msgid ""
"*Documentation*: issue related to the documentation. Mainly to request "
"enhancements in the API documentation. Issues related to the ReadTheDocs "
"documentation should be filed on the `godot-docs <https://github.com/"
"godotengine/godot-docs>`_ repository."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:58
msgid ""
"*Enhancement*: describes a proposed enhancement to an existing functionality."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:60
msgid ""
"*Feature proposal*: describes a wish for a new feature to be implemented."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:62
msgid ""
"*Junior job*: the issue is *assumed* to be an easy one to fix, which makes "
"it a great fit for junior contributors who need to become familiar with the "
"code base."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:65
msgid "*Needs rebase*: the issue need a Git rebase to be merged."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:66
msgid ""
"*Needs testing*: the issue/pull request could not be completely tested and "
"thus need further testing. This can mean that it needs to be tested on "
"different hardware/software configurations or even that the steps to "
"reproduce are not certain."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:70
msgid ""
"*PR welcome / hero wanted!*: Contributions for issues with these labels are "
"especially welcome. Note that this **doesn't** mean you can't work on issues "
"without these labels."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:73
msgid ""
"*Tracker*: issue used to track other issues (like all issues related to the "
"plugin system)."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:75
msgid "*Usability*: issues that directly impact user usability."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:77
msgid ""
"The categories are used for general triage of the issues. They can be "
"combined in some way when relevant, e.g. an issue can be labelled "
"*Enhancement* and *Usability* at the same time if it's an issue to improve "
"usability. Or *Feature proposal* and *Discussion* if it's a non-consensual "
"feature request, or one that is not precise enough to be worked on."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:83
msgid "**Topics:**"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:85
msgid "*Assetlib*: relates to issues with the asset library."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:86
msgid "*Audio*: relates to the audio features (low and high level)."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:87
msgid ""
"*Buildsystem*: relates to building issues, either linked to the SCons "
"buildsystem or to compiler peculiarities."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:89
msgid ""
"*Core*: anything related to the core engine. It might be further split later "
"on as it's a pretty big topic."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:91
msgid "*Drivers*: relates to issues with the drivers used by the engine."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:92
msgid "*Editor*: relates to issues in the editor (mainly UI)."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:93
msgid "*GDNative*: relates to the GDNative module."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:94
msgid "*GDScript*: relates to GDScript."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:95
msgid "*Mono*: relates to the C# / Mono bindings."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:96
msgid "*Network*: relates to networking."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:97
msgid "*Physics*: relates to the physics engine (2D/3D)."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:98
msgid "*Plugin*: relates to problems encountered while writing plugins."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:99
msgid "*Porting*: relates to some specific platforms."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:100
msgid "*Rendering*: relates to the 2D and 3D rendering engines."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:101
msgid "*VisualScript*: relates to issues with the visual scripting language."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:103
msgid ""
"Issues would typically correspond to only one topic, though it's not "
"unthinkable to see issues that fit two bills. The general idea is that there "
"will be specialized contributors teams behind all topics, so they can focus "
"on the issues labelled with their team's topic."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:108
msgid "**Platforms:**"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:110
msgid "*Android*, *HTML5*, *iOS*, *Linux*, *macOS*, *Windows*, *UWP*"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:112
msgid ""
"By default, it is assumed that a given issue applies to all platforms. If "
"one of the platform labels is used, it is then exclusive and the previous "
"assumption doesn't stand anymore (so if it's a bug on e.g. Android and Linux "
"exclusively, select those two platforms)."
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:118
msgid "Milestones"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:120
msgid ""
"`Milestones <https://github.com/godotengine/godot/milestones>`_ correspond "
"to planned future versions of Godot for which there is an existing roadmap. "
"Issues that fit in the said roadmap should be filed under the corresponding "
"milestone; if they don't correspond to any current roadmap, they should be "
"left without milestone. As a rule of thumb, an issue corresponds to a given "
"milestone if it concerns a feature that is new in the milestone, or a "
"critical bug that can't be accepted in any future stable release, or "
"anything that Juan wants to work on right now. :)"
msgstr ""

#: ../../docs/community/contributing/bug_triage_guidelines.rst:129
msgid ""
"Contributors are free to pick issues regardless of their assigned milestone; "
"if a fix is proposed for a bug that was not deemed urgent and thus without "
"milestone, it would likely still be very welcome."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:4
msgid "Documentation guidelines"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:6
msgid ""
"This page describes the rules to follow if you want to contribute to Godot "
"Engine by writing or reviewing documentation, or by translating existing "
"documentation. Also, have a look at README of the `godot-docs GitHub "
"repository <https://github.com/godotengine/godot-docs>`_ and the `docs front "
"page <https://docs.godotengine.org>`_ on what steps to follow and how to "
"contact the docs team."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:14
#: ../../docs/community/contributing/updating_the_class_reference.rst:25
msgid "How to contribute"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:16
msgid ""
"Creating or modifying documentation pages is mainly done via the `godot-docs "
"GitHub repository <https://github.com/godotengine/godot-docs>`_. The HTML "
"(or PDF and EPUB) documentation is generated from the .rst files "
"(reStructuredText markup language) in that repository. Modifying those pages "
"in a pull request and getting it merged will trigger a rebuild of the online "
"documentation."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:23
msgid ""
"For details on Git usage and the pull request workflow, please refer to the :"
"ref:`doc_pr_workflow` page. Most of what it describes regarding the main "
"godotengine/godot repository is also valid for the docs repository."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:28
msgid ""
"The README.md file contains all the information you need to get you started, "
"please read it. In particular, it contains some tips and tricks and links to "
"reference documentation about the reStructuredText markup language."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:32
msgid ""
"If you want to edit the **API reference**, please note that it should *not* "
"be done in the godot-docs repository. Instead, you should edit the ``doc/"
"classes/*`` XML files of Godot's main repository. These files are then later "
"used to generate the in-editor documentation as well as the API reference of "
"the online docs. Read more here: :ref:`doc_updating_the_class_reference`."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:40
msgid "The 'Edit on GitHub' link"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:42
msgid ""
"If you're reading documentation on `docs.godotengine.org <https://docs."
"godotengine.org>`_, you'll see an **Edit on GitHub** hyperlink at the top "
"right of the page. Once you've created a GitHub account, you can propose "
"changes to a page you're reading as follows:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:47
msgid "Click the **Edit on GitHub** button."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:49
msgid ""
"On the GitHub page you're taken to, click the pencil icon in the top-right "
"corner near the **Raw**, **Blame** and **History** buttons. It has the "
"tooltip \"Edit the file in a fork of this project\"."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:53
msgid "Complete all the edits you want to make for that page."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:55
msgid ""
"Summarize the changes you made in the form at the bottom of the page and "
"click the button labelled **Propose file change** when done."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:58
msgid ""
"On the following screens, click the **Create pull request** button until you "
"see a message like *Username wants to merge 1 commit into godotengine:master "
"from Username:patch-6*."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:62
msgid ""
"A reviewer will evaluate your changes and incorporate them into the docs if "
"they're acceptable. You might also be asked to make modifications to your "
"changes before they're included."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:67
msgid "What makes good documentation?"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:69
msgid ""
"Documentation should be well written in plain English, using well-formed "
"sentences and various levels of sections and subsections. It should be clear "
"and objective. Also, have a look at the :ref:`doc_docs_writing_guidelines`."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:73
msgid ""
"We differentiate tutorial pages from other documentation pages by these "
"definitions:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:76
msgid ""
"Tutorial: a page aiming at explaining how to use one or more concepts in the "
"editor or scripts in order to achieve a specific goal with a learning "
"purpose (e.g. \"Making a simple 2d Pong game\", \"Applying forces to an "
"object\")."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:80
msgid ""
"Documentation: a page describing precisely one and only one concept at a "
"time, if possible exhaustively (e.g. the list of methods of the Sprite "
"class, or an overview of the input management in Godot)."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:84
msgid ""
"You are free to write the kind of documentation you wish, as long as you "
"respect the following rules (and the ones on the repo)."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:88
msgid "Titles"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:90
msgid "Always begin pages with their title and a Sphinx reference name:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:99
msgid ""
"The reference allows linking to this page using the ``:ref:`` format, e.g. "
"``:ref:`doc_insert_your_title_here``` would link to the above example page "
"(note the lack of leading underscore in the reference)."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:103
msgid ""
"Also, avoid American CamelCase titles: title's first word should begin with "
"a capitalized letter, and every following word should not. Thus, this is a "
"good example:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:107
msgid "Insert your title here"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:109
msgid "And this is a bad example:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:111
msgid "Insert Your Title Here"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:113
msgid ""
"Only project, people and node class names should have capitalized first "
"letter."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:117
msgid "Translating existing pages"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:119
msgid ""
"You can help to translate the official Godot documentation on our `Hosted "
"Weblate <https://hosted.weblate.org/engage/godot-engine/>`_."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:128
msgid ""
"There also is the official `Godot i18n repository <https://github.com/"
"godotengine/godot-docs-l10n>`_ where you can see when the data was last "
"synchronized."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:135
#, fuzzy
msgid ""
"This documentation and every page it contains is published under the terms "
"of the `Creative Commons Attribution 3.0 license (CC-BY-3.0) <https://"
"tldrlegal.com/license/creative-commons-attribution-(cc)>`_, with attribution "
"to \"Juan Linietsky, Ariel Manzur and the Godot community\"."
msgstr ""
"כל התוכן בתיעוד הזה תחת רישיון reative Commons Attribution 3.0 (`CC-BY 3.0 "
"<https://creativecommons.org/licenses/by/3.0/>`_) וביחוס ל\"Juan Linietsky, "
"Ariel Manzur and the Godot Engine community\"."

#: ../../docs/community/contributing/documentation_guidelines.rst:138
msgid ""
"By contributing to the documentation on the GitHub repository, you agree "
"that your changes are distributed under this license."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:4
msgid "Docs writing guidelines"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:6
msgid ""
"The Godot community is rich and international. Users come from all around "
"the world. Some of them are young, and many aren't native English speakers. "
"That's why we must all write using a clear and a common language. For the "
"class reference, the goal is to make it easy to read for everyone and "
"precise."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:12
msgid "In summary, always try to:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:14
#: ../../docs/community/contributing/docs_writing_guidelines.rst:39
msgid "Use the direct voice"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:15
#: ../../docs/community/contributing/docs_writing_guidelines.rst:74
msgid "Use precise action verbs"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:16
#: ../../docs/community/contributing/docs_writing_guidelines.rst:96
msgid "Avoid verbs that end in -ing"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:17
msgid "Remove unnecessary adverbs and adjectives."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:18
msgid ""
"Ban these 8 words: obvious, simple, basic, easy, actual, just, clear, and "
"however"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:19
#: ../../docs/community/contributing/docs_writing_guidelines.rst:210
msgid "Use explicit references"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:20
#: ../../docs/community/contributing/docs_writing_guidelines.rst:231
msgid "Use 's to show possession"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:21
msgid "Use the Oxford comma"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:23
msgid "There are 3 rules to describe classes:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:25
#: ../../docs/community/contributing/docs_writing_guidelines.rst:368
msgid "Give an overview of the node in the brief description"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:26
#: ../../docs/community/contributing/docs_writing_guidelines.rst:397
msgid "Mention what methods return if it's useful"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:27
#: ../../docs/community/contributing/docs_writing_guidelines.rst:422
msgid "Use \"if true\" to describe booleans"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:31
msgid ""
"A technical writer's job is to pack as much information as possible into the "
"smallest and clearest sentences possible. These guidelines will help you "
"work towards that goal."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:36
msgid "7 rules for clear English"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:41
msgid ""
"Use the direct voice when possible. Take the classes, methods, and constants "
"you describe as the subject. It's natural to write using the passive voice, "
"but it's harder to read and produces longer sentences."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:47
msgid "Passive:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:53
msgid "Active:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:59
#: ../../docs/community/contributing/docs_writing_guidelines.rst:403
msgid "**Don't** use the passive voice:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:66
msgid "**Do** use the node's name as a noun:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:76
msgid ""
"Favor precise yet common verbs over generic ones like ``make``, ``set``, and "
"any expression you can replace with a single word."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:79
msgid ""
"**Don't** repeat the method's name. It already states it sets the pivot "
"value to a new one:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:87
msgid ""
"**Do** explain what's the consequence of this \"set\": use precise verbs "
"like ``place``, ``position``, ``rotate``, ``fade``, etc."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:98
msgid ""
"The progressive forms describe continuous actions. E.g. \"is calling\", \"is "
"moving\"."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:101
msgid "**Don't** use the progressive form for instant changes."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:108
msgid "**Do** use simple present, preterit or future."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:115
msgid ""
"You may use the progressive tense to describe actions that are continuous in "
"time. Anything like animation or coroutines."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:120
msgid ""
"Verbs can turn into adjectival nouns with -ing. This is not a conjugation, "
"so you may use them: ``the remaining movement``, ``the missing file``, etc."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:125
msgid "Remove unnecessary adverbs and adjectives"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:127
msgid ""
"Write as few adjectives and adverbs as possible. Only use them if they add "
"key information to the description."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:130
msgid ""
"**Don't** use redundant or meaningless adverbs. Words that lengthen the "
"documentation but don't add any information:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:137
msgid "**Do** write short sentences in a simple, descriptive language:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:144
msgid "Ban these 8 words"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:146
msgid "**Don't** ever use these 8 banned words:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:148
msgid "obvious"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:149
msgid "simple"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:150
msgid "basic"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:151
msgid "easy"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:152
msgid "actual"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:153
msgid "just"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:154
msgid "clear"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:155
msgid "however (some uses)"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:157
msgid ""
"Game creation and programming aren't simple, and nothing's easy to someone "
"learning to use the API for the first time. Other words in the list, like "
"``just`` or ``actual`` won't add any info to the sentence. Don't use "
"corresponding adverbs either: obviously, simply, basically, easily, "
"actually, clearly."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:163
msgid ""
"**Don't** example. The banned words lengthen the description and take "
"attention away from the most important info:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:171
msgid "**Do** remove them:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:178
msgid ""
"\"Simple\" never helps. Remember, for other users, anything could be complex "
"or frustrate them. There's nothing like a good old *it's simple* to make you "
"cringe. Here's the old brief description, the first sentence on the Timer "
"node's page:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:188
msgid "**Do** explain what the node does instead:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:195
msgid "**Don't** use \"basic\", it is too vague:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:202
msgid "**Do** use the brief description to offer an overview of the node:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:212
msgid "Favor explicit references over implicit ones."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:214
msgid ""
"**Don't** use words like \"the former\", \"the latter\", etc. They're not "
"the most common in English, and they require you to check the reference."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:221
msgid "**Do** repeat words. They remove all ambiguity:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:227
msgid ""
"If you need to repeat the same variable name 3 or 4 times, you probably need "
"to rephrase your description."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:233
msgid ""
"Avoid \"The milk **of** the cow\". It feels unnatural in English. Write "
"\"The cow's milk\" instead."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:236
msgid "**Don't** write \"of the X\":"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:242
msgid ""
"**Do** use ``'s``. It lets you put the main subject at the start of the "
"sentence, and keep it short:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:250
msgid "Use the Oxford comma to enumerate anything"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:252
msgid "From the Oxford dictionary:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:254
msgid ""
"The 'Oxford comma' is an optional comma before the word 'and' at the end of "
"a list: *We sell books, videos, and magazines.*"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:257
msgid ""
"[...] Not all writers and publishers use it, but it can clarify the meaning "
"of a sentence when the items in a list are not single words: *These items "
"are available in black and white, red and yellow, and blue and green.*"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:260
msgid "**Don't** leave the last element of a list without a comma:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:266
msgid ""
"**Do** add a comma before `and` or `or`, for the last element of a list with "
"more than two elements."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:275
msgid "How to write methods and classes"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:278
msgid "Dynamic vs static typing"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:280
msgid ""
"The code examples in the documentation should follow a consistent style not "
"to confuse users. As static type hints are an optional feature of GDScript, "
"we chose to stick to writing dynamic code. This leads to writing GDScript "
"that is concise and accessible."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:285
msgid "The exception is topics that explain static typing concepts to users."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:287
msgid "**Don't** add a type hint with a colon or by casting:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:297
msgid "**Do** write constants variables with dynamic typing:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:307
msgid "**Don't** write functions with inferred arguments or return types:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:318
msgid "**Do** write functions using dynamic typing:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:330
msgid "Use real-world code examples where appropriate"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:332
msgid ""
"Real-world examples are more accessible to beginners than abstract ``foos`` "
"and ``bars``. You can also copy them directly from your game projects, "
"ensuring that any code snippet compiles without errors."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:336
msgid ""
"Writing ``var speed = 10`` rather than ``var my_var = 10`` allows beginners "
"to understand code better. It gives them a frame of reference as to where "
"they could use the code snippets in a live project."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:340
msgid "**Don't** write made-up examples:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:351
msgid "**Do** write concrete examples:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:363
msgid ""
"Of course, there are times when using real-world examples is impractical. In "
"those situations, you should still avoid using names such as ``my_var``, "
"``foo()`` or ``my_func()`` and consider more meaningful names for your "
"examples."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:370
msgid ""
"The brief description is the reference's most important sentence. It's the "
"user's first contact with a node:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:373
msgid "It's the only description in the \"Create New Node\" dialog."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:374
msgid "It's at the top of every page in the reference"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:376
msgid ""
"The brief description should explain the node's role and its functionality, "
"in up to 200 characters."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:379
msgid "**Don't** write tiny and vague summaries:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:386
msgid "**Do** give an overview of the node's functionality:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:393
msgid ""
"Use the node's full description to provide more information, and a code "
"example, if possible."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:399
msgid ""
"Some methods return important values. Describe them at the end of the "
"description, ideally on a new line. No need to mention the return values for "
"any method whose name starts with ``set`` or ``get``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:410
msgid "**Do** always use \"Returns\"."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:417
msgid ""
"Notice the exception to the \"direct voice\" rule: with the move method, an "
"external collider can influence the method and the body that calls ``move``. "
"In this case, you can use the passive voice."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:424
msgid ""
"For boolean member variables, always use ``if true`` and/or ``if false``, to "
"stay explicit. ``Controls whether or not`` may be ambiguous and won't work "
"for every member variable."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:428
msgid ""
"Also, surround boolean values, variable names and methods with ``[code][/"
"code]``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:430
msgid "**Do** start with \"if true\":"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:439
msgid "Use ``[code]`` around arguments"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:441
msgid ""
"In the class reference, always surround arguments with ``[code][/code]``. In "
"the documentation and in Godot, it will display like ``this``. When you edit "
"XML files in the Godot repository, replace existing arguments written like "
"'this' or \\`this\\` with ``[code]this[/code]``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:448
msgid "Common vocabulary to use in Godot's documentation"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:450
msgid ""
"The developers chose some specific words to refer to areas of the interface. "
"They're used in the sources, in the documentation, and you should always use "
"them instead of synonyms, so the users know what you're talking about."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:458
msgid "Overview of the interface and common vocabulary"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:460
msgid ""
"In the top left corner of the editor lie the ``main menus``. In the center, "
"the buttons change the ``workspace``. And together the buttons in the top "
"right are the ``playtest buttons``. The area in the center, that displays "
"the 2D or the 3D space, is the ``viewport``. At its top, you find a list of "
"``tools`` inside the ``toolbar``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:466
msgid ""
"The tabs or dockable panels on either side of the viewport are ``docks``. "
"You have the ``FileSystem dock``, the ``Scene dock`` that contains your "
"scene tree, the ``Import dock``, the ``Node dock``, and the ``Inspector`` or "
"``Inspector dock``. With the default layout you may call the tabbed docks "
"``tabs``: the ``Scene tab``, the ``Node tab``..."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:472
msgid ""
"The Animation, Debugger, etc. at the bottom of the viewport are ``panels``. "
"Together they make up the ``bottom panels``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:475
msgid ""
"Foldable areas of the Inspector are ``sections``. The node's parent class "
"names, which you can't fold, are ``Classes`` e.g. the ``KinematicBody2D "
"class``. And individual lines with key-value pairs are ``properties``. E.g. "
"``position`` or ``modulate color`` are both ``properties``."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:482
msgid "Keyboard shortcut guidelines"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:484
msgid ""
"Keyboard and mouse shortcuts should make use of the ``:kbd:`` tag, which "
"allows shortcuts to stand out from the rest of the text and inline code. Use "
"the compact form for modifier keys (:kbd:`Ctrl`/:kbd:`Cmd`) instead of their "
"spelled out form (:kbd:`Control`/:kbd:`Command`). For combinations, use the "
"``+`` symbol with a space on either side of the symbol."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:490
msgid ""
"Make sure to mention shortcuts that differ on macOS compared to other "
"platforms. On macOS, ``Cmd`` often replaces ``Ctrl`` in keyboard shortcuts."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:493
msgid ""
"Try to integrate the shortcut into sentences the best you can. Here are some "
"examples with the ``:kbd:`` tag left as-is for better visibility:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:496
msgid ""
"Press ``:kbd:`Ctrl + Alt + T``` to toggle the panel (``:kbd:`Cmd + Alt + "
"T``` on macOS)."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:497
msgid ""
"Press ``:kbd:`Space``` and hold the left mouse button to pan in the 2D "
"editor."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:498
msgid "Press ``:kbd:`Shift + Up Arrow``` to move the node upwards by 8 pixels."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:501
msgid "Image contribution guidelines"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:503
msgid ""
"A significant part of the documentation is images, and there are several "
"important guidelines to follow."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:506
msgid ""
"First, you should always be using the default editor theme and text when "
"taking screenshots."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:509
msgid ""
"To improve the appearance of 3D screenshots, use 4× MSAA, enable anisotropic "
"filtering on the project's textures, and set the anisotropic filter quality "
"to 16× in Project Settings."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:513
msgid ""
"Screenshot sizes should not exceed 1920×1080 to ensure fast loading on "
"slower connections."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:516
msgid ""
"When you need to highlight an area of the editor to show something, like a "
"button or option, use a 2 pixel thick outline without a bevel."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:519
msgid ""
"Before you add or replace any images in the documentation, they should be "
"run through a PNG compressor to save size. The built in lossless compressor "
"in programs like Krita or Photoshop should be enough. For heavier images, "
"also look into using a lossy compressor, such as `pngquant <https://pngquant."
"org/>`_ where almost no image quality is lost during compression."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:4
msgid "Contribute to the Class Reference"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:8
msgid ""
"This guide also is available as a `video tutorial on YouTube <https://www."
"youtube.com/watch?v=5jeHXxeX-JY>`_."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:10
msgid ""
"Godot ships with many nodes and singletons to help you develop your games. "
"Each is a class, documented in the :ref:`class reference <toc-class-ref>`. "
"This reference is essential for anyone learning the engine: it is available "
"both online and in the engine."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:13
msgid ""
"But it's incomplete. Some methods, variables and signals lack descriptions. "
"Others changed with recent releases and need updates. The developers can't "
"write the entire reference on their own. Godot needs you, and all of us, to "
"contribute."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:16
msgid ""
"**Important:** If you are planning to make larger changes or a more "
"substantial contribution, it is usually a good idea to create an issue (or a "
"comment in an existing one) to let others know so they don't start working "
"on the same thing too."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:21
msgid ""
"Not sure where to start contributing? Take a look at the current class "
"reference completion status `here <https://godotengine.github.io/doc-status/"
">`__."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:27
msgid ""
"The class reference lies in the following XML files, in Godot's GitHub "
"repository: `doc/classes/ <https://github.com/godotengine/godot/tree/master/"
"doc/classes>`_."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:29
msgid "There are 5 steps to update the class reference (full guide below):"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:31
msgid "Fork `Godot's repository <https://github.com/godotengine/godot>`_"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:32
msgid "Clone your fork on your computer"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:33
msgid "Edit the class file in ``doc/classes/`` to write documentation"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:34
msgid "Commit your changes and push them to your fork"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:35
msgid "Make a pull request on the Godot repository"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:37
msgid ""
"Always use these XML files to edit the API reference. Do not edit the "
"generated .rst files :ref:`in the online documentation <toc-class-ref>`, "
"hosted in the `godot-docs <https://github.com/godotengine/godot-docs>`_ "
"repository."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:40
msgid "Get started with GitHub"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:42
msgid ""
"If you're new to Git and GitHub, this guide will help you get started. "
"You'll learn to:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:44
msgid "Fork and clone Godot's repository"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:45
msgid "Keep your fork up to date with other contributors"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:46
msgid "Create a pull request so your improvements end in the official docs"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:48
msgid ""
"If you're new to Git, the version control system Godot uses, go through "
"`GitHub's interactive guide <https://try.github.io/levels/1/challenges/1>`_. "
"You'll learn some essential vocabulary and get a sense for the tool."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:51
msgid "Fork Godot"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:53
msgid "Fork the Godot Engine into a GitHub repository of your own."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:55
msgid "Clone the repository on your computer:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:61
msgid ""
"Create a new branch to make your changes. It makes it a lot easier to sync "
"your improvements with other docs writers. It's also easier to clean up your "
"repository if you run into any issues with Git."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:67
msgid ""
"The new branch is the same as your master branch, until you start to write "
"API docs. In the ``doc/`` folder, you'll find the class reference."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:70
msgid "How to keep your local clone up-to-date"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:72
msgid ""
"Other writers contribute to Godot's documentation. Your local repository "
"will fall behind it, and you'll have to synchronize it. Especially if other "
"contributors update the class reference while you work on it."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:74
msgid ""
"First add an ``upstream`` git *remote* to work with. Remotes are links to "
"online repositories you can download new files from."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:80
msgid "You can check the list of all remote servers with:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:86
msgid ""
"You should have two: ``origin``, your fork on GitHub that Git adds by "
"default, and ``upstream``, that you just added:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:96
msgid ""
"Each time you want to sync your branch to the state of the upstream "
"repository, enter:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:102
msgid ""
"This command will first ``fetch``, or download the latest version of the "
"Godot repository. Then, it will reapply your local changes on top."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:104
msgid ""
"If you made changes you don't want to keep in your local branch, use the "
"following commands instead:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:111
msgid ""
"**Warning:** The above command will reset your branch to the state of the "
"``upstream master`` branch. It will discard all local changes. Make sure to "
"only run this *before* you make important changes."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:113
msgid ""
"Another option is to delete the branch you're working on, synchronize the "
"master branch with the Godot repository, and create a new branch:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:122
msgid ""
"If you're feeling lost by now, come to our `IRC channels <https://webchat."
"freenode.net/?channels=#godotengine>`_ and ask for help. Experienced Git "
"users will give you a hand."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:125
msgid "Updating the documentation template"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:127
msgid ""
"When classes are modified in the source code, the documentation template "
"might become outdated. To make sure that you are editing an up-to-date "
"version, you first need to compile Godot (you can follow the :ref:"
"`doc_introduction_to_the_buildsystem` page), and then run the following "
"command (assuming 64-bit Linux):"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:133
msgid ""
"The XML files in doc/classes should then be up-to-date with current Godot "
"Engine features. You can then check what changed using the ``git diff`` "
"command. If there are changes to other classes than the one you are planning "
"to document, please commit those changes first before starting to edit the "
"template:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:140
msgid "You are now ready to edit this file to add stuff."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:142
msgid ""
"**Note:** If this has been done recently by another contributor, you don't "
"forcefully need to go through these steps (unless you know that the class "
"you plan to edit *has* been modified recently)."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:145
msgid "Push and request a pull of your changes"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:147
msgid ""
"Once your modifications are finished, push your changes on your GitHub "
"repository:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:156
msgid ""
"When it's done, you can ask for a Pull Request via the GitHub UI of your "
"Godot fork."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:160
msgid ""
"Although you can edit files on GitHub, it's not recommended. As hundreds of "
"contributors work on Godot, the Git history must stay clean. Each commit "
"should bundle all related improvements you make to the class reference, a "
"new feature, bug fixes... When you edit from GitHub, it will create a new "
"branch and a Pull Request every time you want to save it. If a few days pass "
"before your changes get a review, you won't be able to update to the latest "
"version of the repository cleanly. Also, it's harder to keep clean indents "
"from GitHub. And they're very important in the docs."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:162
msgid ""
"TL;DR: If you don't know what you're doing exactly, do not edit files from "
"GitHub."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:165
msgid "How to edit class XML"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:167
msgid ""
"Edit the file for your chosen class in ``doc/classes/`` to update the class "
"reference. The folder contains an XML file for each class. The XML lists the "
"constants and methods you'll find in the class reference. Godot generates "
"and updates the XML automatically."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:169
msgid ""
"Edit it using your favorite text editor. If you use a code editor, make sure "
"that it doesn't change the indent style: tabs for the XML, and 4 spaces "
"inside BBcode-style blocks. More on that below."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:171
msgid ""
"If you need to check that the modifications you've made are correct in the "
"generated documentation, build Godot as described :ref:`here <toc-devel-"
"compiling>`, run the editor and open the help for the page you modified."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:174
msgid "How to write the class reference"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:176
msgid ""
"Each class has a brief and a long description. The brief description is "
"always at the top of the page, while the full description lies below the "
"list of methods, variables and constants. Methods, member variables, "
"constants and signals are in separate categories or XML nodes. For each, "
"learn how they work in Godot's source code, and fill their <description>."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:178
msgid "Our job is to add the missing text between these marks:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:180
msgid "<description></description>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:181
msgid "<brief_description></brief_description>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:182
msgid "<constant></constant>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:183
msgid "<method></method>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:184
msgid "<member></member>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:185
msgid "<signal></signal>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:187
msgid ""
"Write in a clear and simple language. Always follow the :ref:`writing "
"guidelines <doc_docs_writing_guidelines>` to keep your descriptions short "
"and easy to read. **Do not leave empty lines** in the descriptions: each "
"line in the XML file will result in a new paragraph."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:189
msgid "Here's how a class looks like in XML:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:228
msgid ""
"Use a code editor like Vim, Atom, Code, Notepad++ or anything similar to "
"edit the file quickly. Use the search function to find classes fast."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:232
msgid "Improve formatting with BBcode style tags"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:234
msgid ""
"Godot's class reference supports BBcode-like tags. They add nice formatting "
"to the text. Here's the list of available tags:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Effect"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Result"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "[Class]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "Link a class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "Move the [Sprite]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "Move the :ref:`class_sprite`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "[method methodname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "Link to a method in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "Call [method hide]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "See :ref:`hide <class_spatial_method_hide>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "[method Class.methodname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "Link to another class's method"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "Call [method Spatial.hide]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "[member membername]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "Link to a member in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "Get [member scale]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Get :ref:`scale <class_node2d_property_scale>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "[member Class.membername]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Link to another class's member"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Get [member Node2D.scale]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "[signal signalname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "Link to a signal in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "Emit [signal renamed]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
#: ../../docs/community/contributing/updating_the_class_reference.rst:251
msgid "Emit :ref:`renamed <class_node_signal_renamed>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:251
msgid "[signal Class.signalname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:251
msgid "Link to another class's signal"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:251
msgid "Emit [signal Node.renamed]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:253
msgid "[b] [/b]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:253
msgid "Bold"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:253
msgid "Some [b]bold[/b] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:253
msgid "Some **bold** text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:255
msgid "[i] [/i]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:255
msgid "Italic"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:255
msgid "Some [i]italic[/i] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:255
msgid "Some *italic* text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:257
msgid "[code] [/code]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:257
msgid "Monospace"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:257
msgid "Some [code]monospace[/code] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:257
msgid "Some ``monospace`` text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:259
msgid "[kbd] [/kbd]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:259
msgid "Keyboard/mouse shortcut"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:259
msgid "Some [kbd]Ctrl + C[/kbd] key."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:259
msgid "Some :kbd:`Ctrl + C` key."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:261
msgid "[codeblock] [/codeblock]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:261
msgid "Multiline preformatted block"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:261
msgid "*See below.*"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:264
msgid ""
"Use ``[codeblock]`` for pre-formatted code blocks. Inside ``[codeblock]``, "
"always use **four spaces** for indentation (the parser will delete tabs). "
"Example:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:274
msgid "Will display as:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:284
msgid "I don't know what this method does!"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:286
msgid ""
"No problem. Leave it behind, and list the methods you skipped when you "
"request a pull of your changes. Another writer will take care of it."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:288
msgid ""
"You can still have a look at the methods' implementation in Godot's source "
"code on GitHub. Also, if you have doubts, feel free to ask on the `Q&A "
"website <https://godotengine.org/qa/>`__ and on IRC (freenode, #godotengine)."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:292
msgid "Localization"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:294
msgid ""
"The documentation can be translated in any language on `Hosted Weblate "
"<https://hosted.weblate.org/projects/godot-engine/godot-docs/>`__."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:297
msgid ""
"Translated strings are synced manually by documentation maintainers in the "
"`godot-docs-l10n <https://github.com/godotengine/godot-docs-l10n>`__ "
"repository."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:301
msgid ""
"Languages with a good level of completion have their own localized instances "
"of ReadTheDocs. Open an issue on the ``godot-docs-l10n`` repository if you "
"think that a new language is complete enough to get its own instance."
msgstr ""

#: ../../docs/community/channels.rst:4
#, fuzzy
msgid "Community channels"
msgstr "קהילה"

#: ../../docs/community/channels.rst:6
msgid ""
"So, where is the Godot community and where can you ask questions and get "
"help?"
msgstr ""

#: ../../docs/community/channels.rst:8
msgid ""
"Note that some of these channels are run and moderated by members of the "
"Godot community or third parties."
msgstr ""

#: ../../docs/community/channels.rst:10
#, fuzzy
msgid ""
"A brief overview over these and other channels is also available on the "
"`Godot website <https://godotengine.org/community>`_."
msgstr "ראה גם  `את דף הרישיון באתר גודוט <https://godotengine.org/license>`_."

#: ../../docs/community/channels.rst:13
msgid "Q&A"
msgstr "שאלות ותשובות נפוצות"

#: ../../docs/community/channels.rst:15
msgid "`Official Godot Questions & Answers <https://godotengine.org/qa/>`_"
msgstr ""

#: ../../docs/community/channels.rst:18
msgid "IRC on Freenode"
msgstr ""

#: ../../docs/community/channels.rst:20
msgid ""
"`General: #godotengine <http://webchat.freenode.net/?channels=#godotengine>`_"
msgstr ""

#: ../../docs/community/channels.rst:21
msgid ""
"`Engine development: #godotengine-devel <http://webchat.freenode.net/?"
"channels=#godotengine-devel>`_"
msgstr ""

#: ../../docs/community/channels.rst:22
msgid ""
"`Documentation: #godotengine-doc <http://webchat.freenode.net/?"
"channels=#godotengine-doc>`_"
msgstr ""

#: ../../docs/community/channels.rst:23
msgid ""
"`Pull request meetings: #godotengine-meeting <http://webchat.freenode.net/?"
"channels=#godotengine-meeting>`_"
msgstr ""

#: ../../docs/community/channels.rst:24
msgid ""
"`GDNative: #godotengine-gdnative <http://webchat.freenode.net/?"
"channels=#godotengine-gdnative>`_"
msgstr ""

#: ../../docs/community/channels.rst:25
msgid ""
"`Website and public relations: #godotengine-atelier <http://webchat.freenode."
"net/?channels=#godotengine-atelier>`_"
msgstr ""

#: ../../docs/community/channels.rst:26
msgid "`IRC logs <https://godot.eska.me/irc-logs/>`_"
msgstr ""

#: ../../docs/community/channels.rst:29
msgid "Other chats"
msgstr ""

#: ../../docs/community/channels.rst:31
msgid "`Discord Server <https://discordapp.com/invite/zH7NUgz>`_"
msgstr ""

#: ../../docs/community/channels.rst:32
msgid ""
"`Matrix (IRC compatible) <https://matrix.to/#/#godotengine:matrix.org>`_"
msgstr ""

#: ../../docs/community/channels.rst:35
msgid "Language-based communities"
msgstr ""

#: ../../docs/community/channels.rst:37
msgid ""
"Brazilian Portuguese: `Godot Brasil (Discord) <https://discord.gg/gWmQKBv>`_"
msgstr ""

#: ../../docs/community/channels.rst:38
msgid ""
"French: `Godot Francophone Officiel (Discord) <https://discord.gg/3jvf3XN>`_"
msgstr ""

#: ../../docs/community/channels.rst:39
msgid "French: `SoloCode Godot (Discord) <https://discord.gg/gZ3QJ5T>`_"
msgstr ""

#: ../../docs/community/channels.rst:40
msgid ""
"German: `Deutsche Godot Community (Discord) <https://discord.gg/Tr7Ma6E>`_"
msgstr ""

#: ../../docs/community/channels.rst:41
msgid ""
"Swedish: `Swedish Godot Community (Discord) <https://discord.gg/6ZsgWmH>`_"
msgstr ""

#: ../../docs/community/channels.rst:44
msgid "Social networks"
msgstr ""

#: ../../docs/community/channels.rst:46
msgid "`GitHub <https://github.com/godotengine/>`_"
msgstr ""

#: ../../docs/community/channels.rst:47
msgid "`Facebook group <https://www.facebook.com/groups/godotengine/>`_"
msgstr ""

#: ../../docs/community/channels.rst:48
msgid "`Twitter (also, #godotengine) <https://twitter.com/godotengine>`_"
msgstr ""

#: ../../docs/community/channels.rst:49
msgid "`Reddit <https://www.reddit.com/r/godot>`_"
msgstr ""

#: ../../docs/community/channels.rst:50
msgid "`YouTube <https://www.youtube.com/c/GodotEngineOfficial>`_"
msgstr ""

#: ../../docs/community/channels.rst:51
msgid "`Steam <https://steamcommunity.com/app/404790>`_"
msgstr ""

#: ../../docs/community/channels.rst:54
msgid "Forum"
msgstr ""

#: ../../docs/community/channels.rst:56
msgid "`Forum (godotforums.org) <https://godotforums.org/>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:4
msgid "Tutorials and resources"
msgstr ""

#: ../../docs/community/tutorials.rst:6
msgid ""
"This is a list of third-party tutorials and resources created by the Godot "
"community. For resources, remember that there is the official `Godot Asset "
"Library <https://godotengine.org/asset-library/asset>`_ full of official and "
"community resources too! Also, have a look at this `huge list over at Reddit "
"<https://www.reddit.com/r/godot/comments/an0iq5/"
"godot_tutorials_list_of_video_and_written/>`_."
msgstr ""

#: ../../docs/community/tutorials.rst:8
msgid ""
"Think there is something missing here? Feel free to submit a `Pull Request "
"<https://github.com/godotengine/godot-docs/blob/master/community/tutorials."
"rst>`_ as always."
msgstr ""

#: ../../docs/community/tutorials.rst:11
msgid "Where to start"
msgstr ""

#: ../../docs/community/tutorials.rst:13
msgid ""
"The Godot video tutorials by `GDQuest <https://www.youtube.com/channel/"
"UCxboW7x0jZqFdvMdCFKTMsQ/playlists>`_, `Game from Scratch <https://www."
"youtube.com/watch?v=iDEcP8Mc-7s&list=PLS9MbmO_ssyDk79j9ewONxV88fD5e_o5d>`_ "
"and `KidsCanCode <https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/"
"playlists>`_ are well-regarded in the community and often recommended as a "
"gentle introduction to beginners."
msgstr ""

#: ../../docs/community/tutorials.rst:15
msgid ""
"If you're interested in Visual Scripting, `Emilio's tutorials <https://www."
"youtube.com/channel/UC9DR22-qohBDtZ74R3FxOZg>`_ may be worth a look."
msgstr ""

#: ../../docs/community/tutorials.rst:17
msgid ""
"Some tutorials mentioned below provide more advanced tutorials, e.g. on 3D "
"or shaders."
msgstr ""

#: ../../docs/community/tutorials.rst:20
msgid "Video tutorials"
msgstr ""

#: ../../docs/community/tutorials.rst:22
msgid ""
"`Emilio <https://www.youtube.com/channel/UC9DR22-qohBDtZ74R3FxOZg>`_ (2D, "
"GDScript and VisualScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:23
msgid ""
"`GDQuest <https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ/"
"playlists>`_ (2D and 3D, GDScript, VisualScript and C#)."
msgstr ""

#: ../../docs/community/tutorials.rst:24
msgid ""
"`Game Development Channel <https://www.youtube.com/channel/"
"UClseGZiVmeHamsjYmpbiAmQ/playlists>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:25
msgid ""
"`Game Endeavor <https://www.youtube.com/channel/UCLweX1UtQjRjj7rs_0XQ2Eg/"
"videos>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:26
msgid ""
"`Game from Scratch <https://www.youtube.com/watch?"
"v=iDEcP8Mc-7s&list=PLS9MbmO_ssyDk79j9ewONxV88fD5e_o5d>`_ (2D and 3D, "
"GDScript and C#)."
msgstr ""

#: ../../docs/community/tutorials.rst:27
msgid ""
"`HeartBeast <https://www.youtube.com/watch?v=wETY5_9kFtA&list=PL9FzW-"
"m48fn2jlBu_0DRh7PvAt-GULEmd>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:28
msgid ""
"`Jeremy Bullock <https://www.youtube.com/channel/UCwJw2-V5S1TkBjLQ3_Ws54g>`_ "
"(2D and 3D, GDScript, VisualScript and C#)."
msgstr ""

#: ../../docs/community/tutorials.rst:29
msgid ""
"`KidsCanCode <https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/"
"playlists>`__ (2D and 3D, GDScript and VisualScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:30
msgid ""
"`Mister Taft Creates <https://www.youtube.com/playlist?"
"list=PL4vbr3u7UKWqwQlvwvgNcgDL1p_3hcNn2>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:31
msgid ""
"`Miziziziz <https://www.youtube.com/playlist?"
"list=PLmugv6_kd0qN6AyjG245_Pdak4MXKUx88>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:32
msgid ""
"`P1X / Krzysztof Jankowski <https://www.youtube.com/playlist?"
"list=PLvDk7UKhld4xGPovdB4IFtAHYMYjx_-3K>`_ (3D)."
msgstr ""

#: ../../docs/community/tutorials.rst:33
msgid ""
"`Pigdev <https://www.youtube.com/playlist?"
"list=PLPMN4vCRFdordS3E-3zi0Hdh7pAsbWQ6a>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:34
msgid ""
"`Steincodes <https://www.youtube.com/c/steincodes/playlists>`__ (2D, "
"GDScript and VisualScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:35
msgid ""
"`TheBuffED <https://www.youtube.com/watch?"
"v=ygGaN1EOQEA&list=PLvN5Z3tTxXEDfQkt4Frg6ALirespSwZd7>`_ (2D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:36
msgid ""
"`Code with Tom <https://www.youtube.com/playlist?"
"list=PLiUQR4U_J9ec0k91iHPme_qtfS1nrWF3W>`_ (2D and 3D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:37
msgid ""
"`BornCG <https://www.youtube.com/playlist?"
"list=PLda3VoSoc_TSBBOBYwcmlamF1UrjVtccZ>`_ (3D, GDScript)."
msgstr ""

#: ../../docs/community/tutorials.rst:38
msgid ""
"`Gonkee <https://www.youtube.com/channel/UCJqCPFHdbc6443G3Sz6VYDw>`_ (2D, "
"3D, GDScript, Shaders)."
msgstr ""

#: ../../docs/community/tutorials.rst:41
#, fuzzy
msgid "Text tutorials"
msgstr "מדריכים"

#: ../../docs/community/tutorials.rst:43
msgid "`Godot Recipes by KidsCanCode <http://godotrecipes.com/>`__"
msgstr ""

#: ../../docs/community/tutorials.rst:44
msgid "`Steincodes <https://steincodes.tumblr.com>`__"
msgstr ""

#: ../../docs/community/tutorials.rst:47
msgid "Devlogs"
msgstr ""

#: ../../docs/community/tutorials.rst:49
msgid ""
"`Andrea Catania (Physics & AI) <https://www.youtube.com/channel/"
"UCm4RuvYtgpgFDTCgaEUT5uQ/videos>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:50
msgid ""
"`Bastiaan Olij (AR & VR) <https://www.youtube.com/channel/UCrbLJYzJjDf2p-"
"vJC011lYw/videos>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:55
msgid ""
"`awesome-godot: A curated list of resources by Calinou <https://github.com/"
"Calinou/awesome-godot>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:56
msgid ""
"`Zeef Godot Engine: A curated directory of resources by Andre Schmitz "
"<https://godot-engine.zeef.com/andre.antonio.schmitz>`_"
msgstr ""

#, fuzzy
#~ msgid "There are two types of products - consumables and non-consumables:"
#~ msgstr "אין מגבלות שימוש בגודוט"

#, fuzzy
#~ msgid "Scheme setup"
#~ msgstr "נתיב"

#, fuzzy
#~ msgid "Creating a main screen plugin"
#~ msgstr "אנימציות"

#, fuzzy
#~ msgid "Global constants"
#~ msgstr "קבועים"

#, fuzzy
#~ msgid "There is a few things to note here."
#~ msgstr "אין מגבלות שימוש בגודוט"

#~ msgid "Mac OS X"
#~ msgstr "מערכת הפעלה Mac OS X"

#, fuzzy
#~ msgid "Placing of AnimationPlayer"
#~ msgstr "אנימציות"

#~ msgid ""
#~ "This means it is free as in \"free speech\" as well as in \"free beer\"."
#~ msgstr "זה אומר שהוא חינם/חופשי כמו בחופש בחופש הדיבור כמו כן בירה בחינם."

#~ msgid "There are no usage restrictions on Godot"
#~ msgstr "אין מגבלות שימוש בגודוט"

#~ msgid ""
#~ "This means you can use it for any game or application, commercially or "
#~ "non-commercially, in any industry"
#~ msgstr ""
#~ "זה אומר שאתה יכול להשתמש בו לכל משחק או אפליקציה, מסחרית או לא, בכל תעשייה"

#~ msgid ""
#~ "For more, see `here <https://tldrlegal.com/license/mit-license>`_ or ask "
#~ "your lawyer of choice."
#~ msgstr ""
#~ "למידע נוסף, `ראה כאן<https://tldrlegal.com/license/mit-license>`_ או שאל "
#~ "את עורך הדין שלך."