# Godot Engine Documentation in Persian
# Copyright (C) 2014-2018, 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.
#
# Amir Hossein Mafi <theotheramir@gmail.com>, 2018.
# Dante Marshal <Marshal.Devilhunter@gmail.com>, 2018.
#
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: https://github.com/godotengine/godot-docs-l10n\n"
"POT-Creation-Date: 2018-06-18 08:58+0200\n"
"PO-Revision-Date: 2018-06-09 01:41+0000\n"
"Last-Translator: Amir Hossein Mafi <theotheramir@gmail.com>\n"
"Language-Team: Persian <https://hosted.weblate.org/projects/godot-engine/"
"godot-docs/fa/>\n"
"Language: fa\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n > 1;\n"
"X-Generator: Weblate 3.0\n"

#: ../../docs/index.rst:7
msgid "Godot Docs – *master* branch"
msgstr "اسناد گودوت - شاخه ی *سرامد*"

#: ../../docs/index.rst:9
msgid ""
"This is the documentation for the unstable (master) branch. Looking for the "
"documentation of the current **stable** branch? `Have a look here <http://"
"docs.godotengine.org/en/stable>`_."
msgstr ""
"این اسناد مربوط به شاخه‌ی ناپایدار (سرامد) است. میتوانید اسناد مربوط به شاخه‌ی "
"پایدار را در `این قسمت <http://docs.godotengine.org/en/stable>` مشاهده کنید."

#: ../../docs/index.rst:13
msgid ""
"Welcome to the official documentation of Godot Engine, 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:18
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:22
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:29
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 "
"discuss with 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 ""
"در `مخزن های گیت هاب <https://github.com/godotengine/godot-docs/issues>`_ یک "
"issue ایجاد کنید یا یک pull request ثبت کنید. به ما کمک کنید تا مستندات را "
"در زبان شما ترجمه کنیم، یا با ما در کانال `Discord <https://discord.gg/"
"zH7NUgz>`_  با برچسب ``#documentation`` یا در کانال  `irc.freenode.net "
"<http://webchat.freenode.net/?channels=#godotengine-doc>`_ با برچسب "
"``#godotengine-doc`` به بحث و گفتگو بپردازید."

#: ../../docs/index.rst:43
msgid ""
"The main documentation for the site is organized into the following sections:"
msgstr "مستندات اصلی سایت از این بخش ها تشکیل می‌شوند:"

#: ../../docs/index.rst:45 ../../docs/community/resources.rst:9
msgid "General"
msgstr "کلی"

#: ../../docs/index.rst:53
msgid "Getting started"
msgstr "شروع"

#: ../../docs/index.rst:64 ../../docs/community/tutorials.rst:4
msgid "Tutorials"
msgstr "آموزش‌ها"

#: ../../docs/index.rst:89
msgid "Development"
msgstr "توسعه"

#: ../../docs/index.rst:99 ../../docs/community/index.rst:2
msgid "Community"
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/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:4
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:7
#: ../../docs/getting_started/workflow/export/feature_tags.rst:7
#: ../../docs/tutorials/2d/2d_transforms.rst:7
#: ../../docs/tutorials/2d/using_tilemaps.rst:7
#: ../../docs/tutorials/2d/2d_movement.rst:7
#: ../../docs/tutorials/3d/using_transforms.rst:7
#: ../../docs/tutorials/3d/3d_performance_and_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/3d/mesh_generation_with_heightmap_and_shaders.rst:7
#: ../../docs/tutorials/audio/audio_buses.rst:7
#: ../../docs/tutorials/audio/audio_streams.rst:7
#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:7
#: ../../docs/tutorials/physics/ray-casting.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/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/shading/shading_language.rst:7
#: ../../docs/tutorials/shading/shader_materials.rst:7
#: ../../docs/tutorials/shading/screen-reading_shaders.rst:7
#: ../../docs/tutorials/networking/ssl_certificates.rst:7
#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:7
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:7
#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:7
#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:7
#: ../../docs/tutorials/misc/binary_serialization_api.rst:7
#: ../../docs/tutorials/debug/overview_of_debugging_tools.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/cpp/creating_android_modules.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 "
"خوش آمدید!\n"
"در اینجا، شما ابزاری قدرتمند و در عین حال کاربر پسند خواهید یافت، که "
"میتوانید برای ساخت هر نوع بازی، برای هر پلتفرمی و بدون هیچ محدودیتی از آن "
"استفاده کنید."

#: ../../docs/about/introduction.rst:16
msgid ""
"This page aims at giving 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 "About Godot Engine"
msgstr "درباره موتور Godot"

#: ../../docs/about/introduction.rst:23
msgid ""
"A game engine is a complex tool, and it is therefore difficult to present "
"Godot in a few words. Here's however our PR presentation, which you are free "
"to reuse if you need a quick writeup about Godot Engine."
msgstr ""
"موتور بازی‌سازی یک ابزار پیچیده است، در نتیجه نمیتوان Godot را در چند کلمه "
"توصیف کرد. با این حال این PR Presentation ماست، که در صورت نیاز میتوانید از "
"آن برای معرفی سریع موتور Godot استفاده کنید."

#: ../../docs/about/introduction.rst:27
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 that 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 ""
"موتور Godot (گودات) یک موتور بازی‌سازی همه‌کاره و کراس‌پلتفرم برای ساخت بازی‌های "
"۲ بعدی و ۳ بعدی از یک رابط واحد است. این موتور مجموعه‌ای جامع از ابزار‌های "
"عمومی را فراهم میکند، تا کاربران بتوانند روی ساختن بازی‌ها تمرکز کنند، بدون "
"این که مجبور باشند «چرخ را از نو اختراع کنند». بازی‌ها میتوانند با یک کلیک "
"برای چندین پلتفرم از جمله پلتفرم‌های اصلی دسکتاپ (لینوکس، مک و ویندوز)، "
"موبایل (اندروید و آی‌او‌اس) و مبتنی بر وب (HTML5) آماده شوند."

#: ../../docs/about/introduction.rst:34
#, fuzzy
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 ""
"گودات (Godot) کاملا رایگان و متن‌باز تحت مجوز MIT ارائه میگردد. هیچ بندی به "
"مجوز اضافه نشده و هیچ حق امتیازی وجود ندارد. کاربران تا آخرین خط کد موتور "
"صاحب امتیاز بازی‌های خودشان هستند. توسعه‌ی Godot کاملا مستقل و بوده و توسط "
"جامعه‌ی توسعه‌دهندگان موتور انجام میشود، که به کاربران این قدرت را میدهد که "
"برای شکل دادن به موتور مطابق انتظاراتشان به جامعه‌ی توسعه‌دهندگان کمک کنند. "
"این موتور تحت حمایت گروه `حفاظت از آزادی نرم‌افزار (Software Freedom "
"Conservancy) <https://sfconservancy.org>`_ می‌باشد."

#: ../../docs/about/introduction.rst:41
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 ""
"جهت کسب اطلاعات بیشتر درباره موتور، پیشنهاد میشود به مطالعه‌ی همین مستندات "
"ادامه دهید، از جمله :ref:`آموزش قدم به قدم <toc-learn-step_by_step>."

#: ../../docs/about/introduction.rst:46
msgid "About the documentation"
msgstr "درباره مستندات"

#: ../../docs/about/introduction.rst:48
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 ""

#: ../../docs/about/introduction.rst:55
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 ""

#: ../../docs/about/introduction.rst:61
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 ""
"تمام مطالب تحت مجوز Creative Commons Attribution 3.0 (`CC-BY 3.0 <https://"
"creativecommons.org/licenses/by/3.0/>`_) به نام «Juan Linietsky, Ariel "
"Manzur و انجمن موتور گودات» می‌باشد."

#: ../../docs/about/introduction.rst:66
msgid "Organisation of the documentation"
msgstr "سازمان‌دهی مستندات"

#: ../../docs/about/introduction.rst:68
msgid ""
"This documentation is organised 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:72
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:75
msgid ""
"The :ref:`sec-learn` section is the main *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 ""
"بخش :ref:`sec-learn` قسمت اصلی این اسناد می‌باشد، زیرا حاوی تمام اطلاعات لازم "
"جهت استفاده از موتور برای ساخت بازی است. این بخش با آموزش :ref:`قدم به قدم "
"<toc-learn-step_by_step>` آغاز می شود که باید نقطه ورود برای همه کاربران "
"جدید باشد."

#: ../../docs/about/introduction.rst:80
msgid ""
"The :ref:`sec-tutorials` section, on the other hand, can be read as needed, "
"in any order. It contains many feature-specific tutorials and documentations."
msgstr ""

#: ../../docs/about/introduction.rst:82
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 ""

#: ../../docs/about/introduction.rst:85
msgid ""
"The :ref:`sec-community` gives information related to contributing to the "
"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:90
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:96
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:99
msgid "Have fun reading and making games with Godot Engine!"
msgstr ""

#: ../../docs/about/faq.rst:4
#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:29
msgid "Frequently asked questions"
msgstr ""

#: ../../docs/about/faq.rst:7
msgid ""
"What can I do with Godot? How much does it cost? What are the license terms?"
msgstr ""

#: ../../docs/about/faq.rst:9
msgid ""
"Godot is Free/Libre Open Source Software available under the `OSI-approved "
"<https://opensource.org/licenses/MIT>`_ MIT license."
msgstr ""

#: ../../docs/about/faq.rst:11
msgid ""
"This means it is free as in \"free speech\" as well as in \"free beer\"."
msgstr ""

#: ../../docs/about/faq.rst:13
msgid "In short:"
msgstr ""

#: ../../docs/about/faq.rst:15
msgid "There are no usage restrictions on Godot"
msgstr ""

#: ../../docs/about/faq.rst:16
msgid ""
"This means you can use it for any game or application, commercially or non-"
"commercially, in any industry"
msgstr ""

#: ../../docs/about/faq.rst:17
msgid "You can modify, (re)distribute and remix Godot to your heart's content"
msgstr ""

#: ../../docs/about/faq.rst:19
msgid ""
"For more, see `here <https://tldrlegal.com/license/mit-license>`_ or ask "
"your lawyer of choice."
msgstr ""

#: ../../docs/about/faq.rst:21
msgid ""
"All the contents of the documentation 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 ""

#: ../../docs/about/faq.rst:25
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 ""

#: ../../docs/about/faq.rst:28
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 ""

#: ../../docs/about/faq.rst:31
msgid ""
"Also see `the license page on the Godot website <https://godotengine.org/"
"license>`_."
msgstr ""

#: ../../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
msgid "Windows"
msgstr ""

#: ../../docs/about/faq.rst:39 ../../docs/about/faq.rst:45
msgid "Mac OS X"
msgstr ""

#: ../../docs/about/faq.rst:40 ../../docs/about/faq.rst:46
msgid "X11 (Linux, \\*BSD)"
msgstr ""

#: ../../docs/about/faq.rst:42
msgid "**For exporting your games:**"
msgstr ""

#: ../../docs/about/faq.rst:44
msgid "Windows (and UWP)"
msgstr ""

#: ../../docs/about/faq.rst:47
#: ../../docs/getting_started/step_by_step/exporting.rst:185
msgid "Android"
msgstr ""

#: ../../docs/about/faq.rst:48
#: ../../docs/getting_started/step_by_step/exporting.rst:237
msgid "iOS"
msgstr ""

#: ../../docs/about/faq.rst:49
msgid "Web"
msgstr ""

#: ../../docs/about/faq.rst:51
msgid ""
"Both 32 and 64 bit binaries are supported where it makes sense, with 64 "
"being the default."
msgstr ""

#: ../../docs/about/faq.rst:53
msgid ""
"Some users also report building and using Godot successfully on ARM-based "
"systems with Linux, like the Raspberry Pi. There is also some unofficial "
"thirdparty work being done on building for some consoles. None of this is "
"included in the default build scripts or export templates, however."
msgstr ""

#: ../../docs/about/faq.rst:57
msgid ""
"For more on this, see the sections on :ref:`exporting <toc-learn-workflow-"
"export>` and :ref:`compiling Godot yourself <toc-devel-compiling>`."
msgstr ""

#: ../../docs/about/faq.rst:60
msgid "Which languages are supported in Godot?"
msgstr ""

#: ../../docs/about/faq.rst:62
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 ""

#: ../../docs/about/faq.rst:65
msgid ""
"Note that C# and Visual Scripting support is comparatively young and "
"GDScript still has some advantages as outlined below."
msgstr ""

#: ../../docs/about/faq.rst:68
msgid ""
"Support for new languages can be added by third parties using the GDNative / "
"NativeScript / PluginScript facilities. (See question about plugins below.)"
msgstr ""

#: ../../docs/about/faq.rst:71
msgid ""
"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 ""

#: ../../docs/about/faq.rst:75
msgid ""
"GDScript? Why use a custom scripting language instead of my language of "
"choice?"
msgstr ""

#: ../../docs/about/faq.rst:77
msgid ""
"The short answer is that we think the additional complexity both on your "
"side (when first learning Godot and GDScript) as well as our side "
"(maintenance) is worth the more integrated and seamless experience over "
"attracting additional users with more familiar programming languages that "
"result in a worse experience. We understand if you would rather use another "
"language in Godot (see list of supported options above), but we strongly "
"encourage you to try it and see the benefits for yourself."
msgstr ""

#: ../../docs/about/faq.rst:85
msgid ""
"GDScript is designed to integrate from the ground to the way Godot works, "
"more than any other language, and is simple and easy to learn. Takes at most "
"a day or two to get comfortable and it's easy to see the benefits once you "
"do. Please make the effort to learn GDScript, you will not regret it."
msgstr ""

#: ../../docs/about/faq.rst:91
msgid ""
"Godot C++ API is also efficient and easy to use (the entire Godot editor is "
"made with this API), and an excellent tool to optimize parts of a project, "
"but trying to use it instead of GDScript for an entire game is, in most "
"cases, a waste of time."
msgstr ""

#: ../../docs/about/faq.rst:96
msgid ""
"Yes, for more than a decade we tried in the past integrating several VMs "
"(and even shipped games using them), such as Python, Squirrel and Lua (in "
"fact we authored tolua++ in the past, one of the most popular C++ binders). "
"None of them worked as well as GDScript does now."
msgstr ""

#: ../../docs/about/faq.rst:101
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:105
msgid "For the more technically versed, proceed to the next item."
msgstr ""

#: ../../docs/about/faq.rst:108
msgid "I don't believe you. What are the technical reasons for the item above?"
msgstr ""

#: ../../docs/about/faq.rst:110
msgid "The main reasons are:"
msgstr ""

#: ../../docs/about/faq.rst:112
msgid ""
"No good thread support in most script VMs, and Godot uses threads (Lua, "
"Python, Squirrel, JS, AS, etc.)."
msgstr ""

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

#: ../../docs/about/faq.rst:116
msgid ""
"Horrible interface for binding to C++, results in large amount of code, "
"bugs, bottlenecks and general inefficiency (Lua, Python, Squirrel, JS, etc.)"
msgstr ""

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

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

#: ../../docs/about/faq.rst:124
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:128
msgid ""
"GDScript was designed to solve the issues above, and performs well in all "
"the above scenarios. Please learn GDScript and enjoy a smooth integration of "
"scripting with the game engine (yes, it's a rare but enjoyable situation "
"when things just work). It's worth it, give it a try!"
msgstr ""

#: ../../docs/about/faq.rst:135
msgid "I want to extend Godot. What are my options for creating plugins?"
msgstr ""

#: ../../docs/about/faq.rst:137
msgid ""
"For creating Godot Editor plugins look at :ref:`EditorPlugins "
"<doc_making_plugins>` and tool scripts."
msgstr ""

#: ../../docs/about/faq.rst:139
msgid ""
"Additional languages could be added via PluginScript or the more low-level "
"NativeScript."
msgstr ""

#: ../../docs/about/faq.rst:141
msgid ""
"If you want to add a certain native library, your best bet is GDNative and "
"custom C++ modules."
msgstr ""

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

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

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

#: ../../docs/about/faq.rst:148
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."
msgstr ""

#: ../../docs/about/faq.rst:152
msgid "Why is FBX not supported for import?"
msgstr ""

#: ../../docs/about/faq.rst:154
msgid ""
"FBX SDK has a `restrictive license <https://www.blender.org/bf/"
"Autodesk_FBX_License.rtf>`_, that is incompatible with the `open license "
"<https://opensource.org/licenses/MIT>`_ provided by Godot."
msgstr ""

#: ../../docs/about/faq.rst:158
msgid ""
"That said, Godot's Collada support is good, please use the `OpenCollada "
"<https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_ "
"exporter for maximum compatibility if you are using Maya or 3DS Max. If you "
"are using Blender, take a look at our own `Better Collada Exporter <https://"
"godotengine.org/download>`_."
msgstr ""

#: ../../docs/about/faq.rst:164
msgid "Also, glTF support was added in Godot 3.0."
msgstr ""

#: ../../docs/about/faq.rst:166
msgid ""
"FBX support could still be provided by third parties as a plugin. (See "
"Plugins question above.)"
msgstr ""

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

#: ../../docs/about/faq.rst:171
msgid ""
"No, the aim of Godot is to create a complete open source engine licensed "
"under MIT, so you have complete control over every single piece of it. Open "
"versions of functionality or features from such SDKs may be eventually added "
"though."
msgstr ""

#: ../../docs/about/faq.rst:176
msgid ""
"That said, because it is open source, and modular, nothing prevents you or "
"anyone else interested into adding those libraries as a module and ship your "
"game using them, as either open or closed source. Everything is allowed."
msgstr ""

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

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

#: ../../docs/about/faq.rst:186
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:195
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 aspects. This "
"is mostly needed for 2D, as in 3D it's just a matter of Camera XFov or YFov."
msgstr ""

#: ../../docs/about/faq.rst:200
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:208
msgid ""
"Use the stretch options in Godot, 2D stretching with keeping aspect works "
"best. Check the :ref:`doc_multiple_resolutions` tutorial on how to achieve "
"this."
msgstr ""

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

#: ../../docs/about/faq.rst:217
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:221
msgid "And that's it! Your game should work in multiple resolutions."
msgstr ""

#: ../../docs/about/faq.rst:223
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:229
msgid "I have a great idea that will make Godot better. What do you think?"
msgstr ""

#: ../../docs/about/faq.rst:231
msgid ""
"Your idea will most certainly be ignored. Examples of stuff that is ignored "
"by the developers:"
msgstr ""

#: ../../docs/about/faq.rst:234
msgid "Let's do this because it will make Godot better"
msgstr ""

#: ../../docs/about/faq.rst:235
msgid "Let's do this in Godot because another game engine does it"
msgstr ""

#: ../../docs/about/faq.rst:236
msgid "Let's remove this because I think it's not needed"
msgstr ""

#: ../../docs/about/faq.rst:237
msgid "Let's remove clutter and bloat and make Godot look nicer"
msgstr ""

#: ../../docs/about/faq.rst:238
msgid "Let's add an alternative workflow for people who prefer it"
msgstr ""

#: ../../docs/about/faq.rst:240
msgid ""
"Godot developers are always willing to talk to you and listen to your "
"feedback very openly, to an extent rarely seen in open source projects, but "
"they will care mostly about real issues you have while using Godot, not "
"ideas solely based on personal belief. Developers are interested in (for "
"example):"
msgstr ""

#: ../../docs/about/faq.rst:246
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:248
msgid ""
"The features you would like to see implemented because you need them for "
"your project."
msgstr ""

#: ../../docs/about/faq.rst:250
msgid ""
"The concepts that were difficult to understand in order to learn the "
"software."
msgstr ""

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

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

#: ../../docs/about/faq.rst:255
msgid ""
"Once one of the above points is stated, we can work together on a solution "
"and this is where your ideas and suggestions are most valuable and welcome, "
"they need to be in context of a real issue."
msgstr ""

#: ../../docs/about/faq.rst:259
msgid ""
"As such, please don't feel that your ideas for Godot are unwelcome. Instead, "
"try to reformulate them as a problem first, so developers and the community "
"have a base ground to discuss first."
msgstr ""

#: ../../docs/about/faq.rst:263
msgid "Examples of how NOT to state problems generally and vaguely are:"
msgstr ""

#: ../../docs/about/faq.rst:265
msgid "Certain feature is ugly"
msgstr ""

#: ../../docs/about/faq.rst:266
msgid "Certain workflow is slow"
msgstr ""

#: ../../docs/about/faq.rst:267
msgid "Certain feature needs optimization"
msgstr ""

#: ../../docs/about/faq.rst:268
msgid "Certain aspect of the UI looks cluttered"
msgstr ""

#: ../../docs/about/faq.rst:270
msgid ""
"Associating something with an adjective will not get you much attention and "
"developers will most likely not understand you. Instead, try to reformulate "
"your problem as a story such as:"
msgstr ""

#: ../../docs/about/faq.rst:274
msgid "I try to move objects around but always end up picking the wrong one"
msgstr ""

#: ../../docs/about/faq.rst:275
msgid ""
"I tried to make a game like Battlefield but I'm not managing to understand "
"how to get lighting to look the same."
msgstr ""

#: ../../docs/about/faq.rst:277
msgid ""
"I always forget which script I was editing, and it takes me too many steps "
"to go back to it."
msgstr ""

#: ../../docs/about/faq.rst:280
msgid ""
"This will allow you to convey what you are thinking much better and set a "
"common ground for discussion. Please try your best to state your problems as "
"stories to the developers and the community, before discussing any idea. Be "
"specific and concrete."
msgstr ""

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

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

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

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

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

#: ../../docs/getting_started/step_by_step/index.rst:2
msgid "Step by step"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:4
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. "
"It lets you create, remove, import or play game projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:16
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:46
#: ../../docs/tutorials/assetlib/using_assetlib.rst:16
#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:22
msgid "|image0|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:18
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:21
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:54
#: ../../docs/tutorials/assetlib/using_assetlib.rst:48
msgid "|image1|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:23
msgid ""
"From the **Templates** tab you can download open source project templates "
"and demos to help you get started faster."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:26
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:68
#: ../../docs/tutorials/assetlib/using_assetlib.rst:58
msgid "|image2|"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:34
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:88
#: ../../docs/tutorials/assetlib/using_assetlib.rst:83
msgid "|image3|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:36
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:39
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:99
#: ../../docs/tutorials/assetlib/using_assetlib.rst:88
msgid "|image4|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:41
msgid ""
"When you see the green tick on the right, it means the engine detects an "
"empty folder and you may click ``Create``. 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:45
msgid ""
"The next time you’ll open Godot, 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:48
#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:151
#: ../../docs/tutorials/assetlib/using_assetlib.rst:92
msgid "|image5|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:50
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:54
msgid "|image7|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:56
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:58
#: ../../docs/tutorials/assetlib/using_assetlib.rst:120
msgid "|image8|"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:63
msgid ""
"Welcome to Godot! With your project open you should see the editor’s "
"interface with the 3d viewport active. You can change the current workspace "
"at the top of the interface. Click on 2d to switch to the 2d workspace."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:68
#: ../../docs/tutorials/assetlib/using_assetlib.rst:141
msgid "|image9|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:70
msgid "Now you should see this interface, with empty docks on the right side."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:72
#: ../../docs/tutorials/assetlib/using_assetlib.rst:147
msgid "|image10|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:74
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:77
msgid ""
"On the left side you have the **FileSystem dock**, where you’ll manage your "
"project files and assets."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:80
#: ../../docs/tutorials/assetlib/using_assetlib.rst:152
msgid "|image11|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:82
msgid ""
"On the right side you’ll find the **Scene dock** that lists the active "
"scene’s content and the **Inspector** in the bottom right corner."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:85
#: ../../docs/tutorials/assetlib/using_assetlib.rst:160
msgid "|image12|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:87
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:91
#: ../../docs/tutorials/assetlib/using_assetlib.rst:167
msgid "|image13|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:93
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:97
msgid "|image14|"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:102
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:105
msgid ""
"You’ll use the **2D workspace** for all types of games. On top of 2D games "
"that is where you’ll build your interfaces. Press F1 to access it. |image15|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:109
msgid ""
"In the **3D workspace**, you can work with meshes, lights, and design levels "
"for 3D games. Press F2 to access it."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:112
msgid "|image16|"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:116
msgid "|image20|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:118
msgid ""
"The **Script** workspace is a complete code editor with a debugger, rich "
"auto-completion, and built-in code reference. Press F3 to access it, and F4 "
"to search the reference."
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:122
msgid "|image17|"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:130
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 for instance."
msgstr ""

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

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:137
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:140
msgid "|image18|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:142
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:145
msgid "|image19|"
msgstr ""

#: ../../docs/getting_started/step_by_step/intro_to_the_editor_interface.rst:147
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/development/file_formats/tscn.rst:27
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 other nodes as children."
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 only 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
msgid "Creating a new project"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:79
msgid ""
"Let's make these abstract concepts more concrete with an example. Following "
"a long tradition in tutorials, we'll start with a \"Hello World\" project. "
"This will introduce us to using the editor."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:83
msgid ""
"If you run the godot executable outside of a project, the Project Manager "
"appears. This helps developers manage their projects."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:88
msgid ""
"To create a new project, click the \"New Project\" option. Choose and create "
"a path for the project and specify the project name \"New Project\":"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:94
#: ../../docs/getting_started/editor/external_editor.rst:32
msgid "Editor"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:96
msgid ""
"Once you've created the \"New Project\", then open it. This will open the "
"Godot editor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:101
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:106
msgid ""
"To do this, press the \"New Node\" button (which looks like a plus symbol):"
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:110
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:115
msgid ""
"From there, select the \"Label\" node first. Searching for it is probably "
"the quickest way:"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:124
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:127
msgid ""
"The node appears in the scene tree editor (box in the top right corner), and "
"the label properties appear in the Inspector (box in the bottom right "
"corner)."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:131
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:136
msgid ""
"Ok, everything's ready to run the scene! Press the PLAY SCENE Button on the "
"top bar (or hit F6):"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:145
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:150
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:158
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:163
msgid "Success!"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:170
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:175
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:181
msgid "To access that dialog, select Project -> Project Settings. Try it now."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:183
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:188
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:191
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:196
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:200
msgid "To be continued..."
msgstr ""

#: ../../docs/getting_started/step_by_step/scenes_and_nodes.rst:202
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 "
"\"Duplicate\" (Ctrl-D):"
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 and change the ``Bounce`` property in the Inspector "
"to `1`. 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:98
msgid ""
"You can also adjust individual instances. Set the bounce value back to "
"``0.5`` and then in the ``Main`` scene, select one of the instanced balls. "
"Set its ``Bounce`` to ``1`` and press \"Play\"."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:104
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:112
msgid "Conclusion"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing.rst:114
msgid ""
"Instancing can be useful when you want to create many copies of the same "
"object."
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 more flexible alternative to prefabs (and much more powerful given that "
"instances can be nested)."
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:14
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:18
msgid "Design language"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:20
msgid ""
"But the greatest strength that comes with instancing scenes is that it works "
"as an excellent design language. This is pretty much what 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:25
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:31
msgid "For example, here's how a simple shooter game could be imagined:"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:35
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:39
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:43
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:49
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:54
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:59
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:63
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:67
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:74
msgid "Information overload!"
msgstr ""

#: ../../docs/getting_started/step_by_step/instancing_continued.rst:76
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:80
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:4
#: ../../docs/getting_started/step_by_step/resources.rst:165
#: ../../docs/getting_started/scripting/index.rst:2
#: ../../docs/tutorials/networking/http_request_class.rst:22
msgid "Scripting"
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:"
"`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 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/gdscript/gdscript_basics.rst:4
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:114
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:129
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:142
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:153
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:161
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:180
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:223
msgid "GDScript"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:24
msgid ""
":ref:`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 ""
"C# is usually the best choice for companies. The large amount of programmers "
"familiar with it means less time can be spent learning Godot and more time "
"can be spent programming with it."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:69
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:75
msgid "GDNative / C++"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:77
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:81
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:85
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:90
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:94
msgid "Scripting a scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:96
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:100
msgid "Writing a script and attaching it to a node."
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/scripting.rst:104
msgid ""
"Before continuing, please make sure to read the :ref:`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:109
#: ../../docs/tutorials/physics/kinematic_character_2d.rst:80
#: ../../docs/tutorials/animation/introduction_2d.rst:113
msgid "Scene setup"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/scripting.rst:116
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:141
msgid "Label"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:117
msgid "Button"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scripting.rst:123
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:128
msgid "Finally, save the scene with a name such as ``sayhello.tscn``."
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/scripting.rst:140
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:143
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:146
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:150
msgid "Finally, enter a path name for the script and select Create:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:154
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:160
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:165
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:170
msgid "The role of the script"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:172
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:180
msgid "Handling a signal"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:182
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:187
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:192
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:195
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:200
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:205
msgid ""
"In the bottom-left are the key things you need to create a connection: a "
"node which implements the method you want to trigger (represented here as a "
"NodePath) and the name of the method to trigger."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:209
msgid ""
"The top-left section displays a list of your scene's nodes with the emitting "
"node's name highlighted in red. Select the \"Panel\" node here. When you "
"select a node, the NodePath at the bottom will automatically update to point "
"a relative path from the emitting node to the selected node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:214
msgid ""
"By default, the method name will contain the emitting node's name (\"Button"
"\" in this case), resulting in \"_on_[EmitterNode]_[signal_name]\". If you "
"do have the \"Make Function\" check button checked, then the editor will "
"generate the function for you before setting up the connection."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:219
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 in to "
"the manual process!"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:223
msgid ""
"To accomplish this, we will introduce a function that is probably the most "
"used by Godot programmers: :ref:`Node.get_node() <class_Node_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:228
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:231
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:248
msgid "Next, write a function which will be called when the button is pressed:"
msgstr ""

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

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

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

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

#: ../../docs/getting_started/step_by_step/scripting.rst:325
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:343
msgid "Also, remember that nodes are referenced by name, not by type."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting.rst:347
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:351
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__process>` is found in a script. It can be turned off and on "
"with the :ref:`Node.set_process() <class_Node_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, so it's fully "
"dependent on how many frames per second (FPS) the application is running at:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:37
msgid ""
"The delta parameter contains the time elapsed in seconds, as a floating "
"point, since the previous call to ``_process()``."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:40
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:43
msgid ""
"For example, movement is often multiplied with a time delta to make movement "
"speed both constant and independent from the frame rate."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:46
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:52
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:55
msgid ""
"A simple way to test this is to create a scene with a single Label node, "
"with the following script:"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:85
msgid "Groups"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:87
msgid ""
"Nodes can be added to groups, as many as desired per node, and is a useful "
"feature for organizing large scenes. There are two ways to do this. The "
"first is from the UI, from the Groups button under the Node panel:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:92
msgid ""
"And the second way is from code. One example would be to tag scenes which "
"are enemies:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:110
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_call_group>`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:127
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:130
msgid ""
"It is also possible to get the full list of ``enemies`` nodes by calling :"
"ref:`SceneTree.get_nodes_in_group() <class_SceneTree_get_nodes_in_group>`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:143
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 got some time!"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:153
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__notification>` function in your "
"script:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:188
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 overrideable functions."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:193
msgid "Overrideable functions"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:267
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:271
msgid "Creating nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:273
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:297
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:313
msgid ""
"When a node is freed, it also frees all its children 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:317
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:322
msgid ""
"The safest way to delete a node is by using :ref:`Node.queue_free() "
"<class_Node_queue_free>`. This erases the node safely during idle."
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:340
msgid "Instancing scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/scripting_continued.rst:342
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:355
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:362
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_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:380
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/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."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:28
#: ../../docs/development/cpp/configuring_an_ide.rst:147
msgid "Project Setup"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:34
msgid ""
"For this tutorial, we will assume you are familiar with the 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:38
msgid ""
"This game will use 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:43
msgid "Organizing the Project"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:45
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 make folders to hold the various scenes and "
"their scripts, but for this relatively small game, you can save your scenes "
"and scripts in the root folder, referred to as ``res://``.  You can see your "
"project folders in the FileSystem Dock in the upper left corner:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:56
msgid "Player Scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:58
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:63
msgid "Node Structure"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:65
msgid ""
"To begin, click the \"Add/Create a New Node\" button and add an :ref:`Area2D "
"<class_Area2D>` node to the scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:70
msgid ""
"With ``Area2D`` we can detect objects that overlap or run into the player. "
"Change its name to ``Player`` by clicking on the node's name. This is the "
"scene's root node. We can add additional nodes to the player to add "
"functionality."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:74
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:81
msgid ""
"Save the scene. Click Scene -> Save, or press ``Ctrl+S`` on Windows/Linux or "
"``Command+S`` on Mac."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:83
msgid ""
"For this project, we will be following the Godot naming conventions. Classes "
"(nodes) use ``PascalCase``, variables and functions use ``snake_case``, and "
"constants use ``ALL_CAPS``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:88
msgid "Sprite Animation"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:90
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 \"<null>\" -> \"New SpriteFrames\". Next, in the same location, click "
"``<SpriteFrames>`` to open the \"SpriteFrames\" panel:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:102
msgid ""
"On the left is a list of animations. Click the \"default\" one and rename it "
"to \"right\". Then click the \"Add\" button to create a second animation "
"named \"up\". 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:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:109
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:116
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 \"<null>\"\" -> \"New "
"CapsuleShape2D\".  Resize the shape to cover the sprite:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:124
msgid ""
"Don't scale the shape's outline! Only use the size handles (circled in red) "
"to adjust the shape!"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:132
msgid "Moving the Player"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:134
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 \"Add "
"Script\" button:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:140
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:143
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:148
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:151
msgid "Start by declaring the member variables this object will need:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:172
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 set the speed property to ``400``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:177
msgid ""
"If you're using C#, you need to restart godot editor temporarily to see "
"exported variables in the editor until it's fixed."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:182
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:198
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. Here we'll make it:"
msgstr ""

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

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:206
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\". 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:213
msgid ""
"You can detect whether a key is pressed using ``Input.is_action_pressed()``, "
"which returns ``true`` if it is pressed or ``false`` if it isn't."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:266
msgid ""
"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* than if it just moved horizontally."
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:276
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:280
msgid ""
"We also check whether the player is moving so we can start or stop the "
"AnimatedSprite animation."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:283
msgid ""
"``$`` returns the node at the relative path from this 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:286
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:289
msgid ""
"Now that we have a movement direction, we can update ``Player``'s position "
"and use ``clamp()`` to prevent it from leaving the screen by adding the "
"following to the bottom of the ``_process`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:309
msgid "*Clamping* a value means restricting it to a given range."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:311
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:314
msgid ""
"If you get an error in the \"Debugger\" panel that refers to a \"null "
"instance\", this likely means you spelled the node name wrong. Node names "
"are case-sensitive and ``$NodeName`` or ``get_node(\"NodeName\")`` must "
"match the name you see in the scene tree."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:319
msgid "Choosing Animations"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:350
msgid ""
"Play the scene again and check that the animations are correct in each of "
"the directions. 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:365
msgid "Preparing for Collisions"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:367
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:371
msgid "Add the following at the top of the script, after ``extends Area2d``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:383
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:390
msgid ""
"Notice our custom \"hit\" signal is there as well! Since our enemies are "
"going to be ``RigidBody2D`` nodes, we want the ``body_entered( Object "
"body )`` signal; this will be emitted when a body contacts the player. Click "
"\"Connect..\" and then \"Connect\" again on the \"Connecting Signal\" "
"window. We don't need to change any of these settings - Godot will "
"automatically create a function called ``_on_Player_body_entered`` in your "
"player's script."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:398
msgid ""
"When connecting a signal, instead of having Godot create a function for you, "
"you can also give the name of an existing function that you want to link the "
"signal to."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:402
msgid "Add this code to the function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:425
msgid ""
"Disabling the area's collision shape means it won't detect collisions. By "
"turning it off, we make sure we don't trigger the ``hit`` signal more than "
"once."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:430
msgid ""
"The last piece for our player 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:453
msgid "Enemy Scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:455
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 and move in a random direction in a straight line, then despawn "
"when they go offscreen."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:460
msgid ""
"We will build this into 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:464
msgid "Node Setup"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:466
msgid "Click Scene -> New Scene and we'll create the Mob."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:468
msgid "The Mob scene will use the following nodes:"
msgstr ""

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

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:474
msgid ""
":ref:`VisibilityNotifier2D <class_VisibilityNotifier2D>` (named "
"``Visibility``)"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:476
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:479
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:486
msgid ""
"Set up the :ref:`AnimatedSprite <class_AnimatedSprite>` like you did for the "
"player. This time, we have 3 animations: ``fly``, ``swim``, and ``walk``. "
"Set the ``Playing`` property in the Inspector to \"On\" and adjust the "
"\"Speed (FPS)\" setting as shown below. 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:493
msgid ""
"``fly`` should be set to 3 FPS, with ``swim`` and ``walk`` set to 4 FPS."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:495
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:498
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 ``Node2D``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:503
msgid "Enemy Script"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:529
msgid ""
"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). Set them to ``150`` and ``250`` in the Inspector. We also have "
"an array containing the names of the three animations, which we'll use to "
"select a random one."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:535
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:559
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. ``randi() % "
"n`` is the standard way to get a random integer between ``0`` and ``n-1``."
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:585
msgid "Main Scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:587
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:593
msgid "See :ref:`doc_instancing` to learn more about instancing."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:595
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:598
msgid ""
":ref:`Timer <class_Timer>` (named ``MobTimer``) - to control how often mobs "
"spawn"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:601
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:603
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:606
msgid "``MobTimer``: ``0.5``"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:610
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:614
msgid "Spawning Mobs"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:616
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:623
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 \"Snap to Grid\" is checked. This option can be found under the "
"\"Snapping options\" button to the left of the \"Lock\" button, appearing as "
"a series of three vertical dots."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:631
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:634
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:637
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:643
msgid "Main Script"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:645
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:684
msgid ""
"Drag ``Mob.tscn`` from the \"FileSystem\" panel and drop it in the ``Mob`` "
"property under the Script Variables of the ``Main`` node."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:687
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 \"Method In Node\" box at the "
"bottom of the \"Connecting Signal\" window. Add the following code, as well "
"as a ``new_game`` function to set everything up for a new game:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:729
msgid ""
"Now connect the ``timeout()`` signal of each of the Timer nodes. "
"``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:760
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:766
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:814
msgid ""
"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:820
msgid "HUD"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:822
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:828
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:832
msgid "The HUD displays the following information:"
msgstr ""

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

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:838
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:842
msgid "Create the following as children of the ``HUD`` node:"
msgstr ""

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

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

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:849
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:856
msgid ""
"Arrange the nodes as shown below. Click the \"Anchor\" button to set a "
"Control node's anchor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:861
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:865
msgid "ScoreLabel"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:867
msgid "``Layout``: \"Center Top\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:868
#: ../../docs/getting_started/step_by_step/your_first_game.rst:881
#: ../../docs/getting_started/step_by_step/your_first_game.rst:894
msgid "``Margin``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:870
msgid "Left: ``-25``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:871
msgid "Top: ``0``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:872
msgid "Right: ``25``"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:878
msgid "MessageLabel"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:880
msgid "``Layout``: \"Center\""
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:883
msgid "Left: ``-200``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:884
msgid "Top: ``-150``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:885
msgid "Right: ``200``"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:886
msgid "Bottom: ``0``"
msgstr ""

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

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:896
msgid "Left: ``-100``"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:898
msgid "Right: ``100``"
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:903
msgid ""
"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 for each of the three ``Control`` "
"nodes:"
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:912
msgid ""
"Click on the \"DynamicFont\" you added, and under \"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:918
msgid "Now add this script to ``HUD``:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:935
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:958
msgid ""
"This function is called when we want to display a message temporarily, such "
"as \"Get Ready\". 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:987
msgid ""
"This function is called when the player loses. It will show \"Game Over\" "
"for 2 seconds, then return to the title screen and show the \"Start\" button."
msgstr ""

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1007
msgid ""
"Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` "
"signal of ``StartButton``."
msgstr ""

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

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

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1046
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:1049
msgid ""
"In the Node tab, connect the HUD's ``start_game`` signal to the "
"``new_game()`` function."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1052
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:1067
msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1079
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:1092
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:1096
msgid "Finishing Up"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1098
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:1103
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:62
msgid "Background"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1105
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 drag the size of the ``ColorRect`` so that it covers the "
"screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1112
msgid ""
"You can also add a background image, if you have one, by using a ``Sprite`` "
"node."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1116
msgid "Sound Effects"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1118
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:1123
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:1128
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:1131
msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1134
#: ../../docs/tutorials/shading/shading_language.rst:1077
msgid "Particles"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1136
msgid ""
"For one last bit of visual appeal, let's add a trail effect to the player's "
"movement. Choose your ``Player`` scene and add a :ref:`Particles2D "
"<class_Particles2D>` node named ``Trail``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1140
msgid ""
"There are a large number of properties to choose from when configuring "
"particles. Feel free to experiment and create different effects. For the "
"effect in this example, use the following settings:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1146
msgid ""
"You also need to create a ``Material`` by clicking on ``<null>`` and then "
"\"New ParticlesMaterial\". The settings for that are below:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1151
msgid ""
"To make the gradient for the \"Color Ramp\" setting, we want a gradient "
"taking the alpha (transparency) of the sprite from 0.5 (semi-transparent) to "
"0.0 (fully transparent)."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1155
msgid ""
"Click \"New GradientTexture\", then under \"Gradient\", click \"New Gradient"
"\". You'll see a window like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1160
msgid ""
"The left and right boxes represent the start and end colors. Click on each "
"and then click the large square on the right to choose the color. For the "
"first color, set the ``A`` (alpha) value to around halfway. For the second, "
"set it all the way to ``0``."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1165
msgid ""
"See :ref:`Particles2D <class_Particles2D>` for more details on using "
"particle effects."
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1169
msgid "Project Files"
msgstr ""

#: ../../docs/getting_started/step_by_step/your_first_game.rst:1171
msgid ""
"You can find a completed version of this project here: https://github.com/"
"kidscancode/Godot3_dodge/releases"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:4
#: ../../docs/getting_started/editor/command_line_tutorial.rst:128
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 ""
"The first step is to open \"Project Settings\" and find the *Handheld* "
"section. Enable the *Emulate Touchscreen* option. This lets you treat mouse "
"click events the same as touch events, so you can test the game on a "
"computer without a touchscreen. Also, make sure to select \"portrait\" under "
"*Orientation*."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:36
msgid ""
"In the *Stretch* section, 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/exporting.rst:41
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:45
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:122
#, fuzzy
msgid "Export Templates"
msgstr "منوی خروجی گرفتن"

#: ../../docs/getting_started/step_by_step/exporting.rst:124
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:131
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:136
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:140
#, fuzzy
msgid "Export Presets"
msgstr "منوی خروجی گرفتن"

#: ../../docs/getting_started/step_by_step/exporting.rst:142
msgid ""
"Next, you can configure the export settings by clicking on *Project -> "
"Export*:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:146
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:149
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:153
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:156
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:160
msgid "Exporting by Platform"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:162
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:166
msgid "PC (Linux/MacOS/Windows)"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:168
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:173
msgid "Click \"Save\" and the engine will build the export files."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:175
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:180
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:187
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:193
msgid ""
"Before you can export your project for Android, you must download the "
"following software:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:196
msgid "Android SDK: https://developer.android.com/studio/"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:197
msgid ""
"Java JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:199
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:203
msgid ""
"Next, create a debug keystore with by running the following command on your "
"system's command line:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:210
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:216
msgid ""
"Now you're ready to export. Click on *Project -> Export* and add a preset "
"for Android (see above)."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:219
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:226
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:229
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:234
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:239
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:242
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:246
msgid "You must also provide icons and splash screen images as shown below:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:250
msgid "Click \"Export Project\" and select a destination folder."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:252
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:257
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:263
msgid "HTML5 (web)"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:265
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:268
msgid ""
"When the export is complete, you'll have a folder containing the following "
"files:"
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:273
msgid ""
"Viewing the `.html` file in your browser lets you play the game. However, "
"you can't open the file directly, it neds to be served by a web server. If "
"you don't have one set up on your computer, you can use Google to find "
"suggestions for your specific OS."
msgstr ""

#: ../../docs/getting_started/step_by_step/exporting.rst:278
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:283
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:286
msgid ""
"Browser support for WASM is not very widespread. Firefox and Chrome both "
"support it, but you may still 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, 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:11
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:17
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:20
msgid "Object-oriented design and composition"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:22
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:26
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:33
msgid "On top of that, you can **inherit** from any scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:35
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:40
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:48
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:56
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:61
msgid "All-inclusive package"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:63
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:70
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:75
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:80
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:84
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:90
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:94
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:101
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:105
msgid "Open-source"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:107
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 coded from the ground-up by contributors."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:111
msgid ""
"Anyone can plug in proprietary tools for the needs of their projects - they "
"just won’t ship with the engine. This may include NViDia PhysX, Google "
"Admob, or an FBX file importer. Any of these can come as third-party plugins "
"instead."
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:116
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:122
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:127
msgid "Community-driven"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:129
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:134
msgid ""
"That said, although a handful of core developers work on it full-time, the "
"project has over 500 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:141
msgid "The Godot editor is a Godot game"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:143
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:148
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:153
msgid ""
"*RPG in a Box is a voxel RPG editor made in 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:157
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:163
msgid "Separate 2D and 3D engines"
msgstr ""

#: ../../docs/getting_started/step_by_step/godot_design_philosophy.rst:165
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 interface 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 screen 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 "
"responsive User Interface. 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, to create anything from life bars to complex applications. Godot's "
"entire editor and plugins use these nodes."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:17
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:19
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:21
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:22
msgid "How to work with the anchor of UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:23
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:25
msgid "The five most common containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:27
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:30
msgid ""
"Only use Control nodes when you design your interfaces. They have unique "
"properties that allow them to work with one another. Other nodes like "
"Node2D, Sprite, etc. will not work. You can still use some nodes that work "
"with others like the AnimationPlayer, Tween or the StreamPlayer. Control "
"nodes are CanvasItems like Node2D, so you can apply shaders to them."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:37
msgid "All control nodes share the same main properties:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:39
msgid "Anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:40
msgid "Bounding rectangle"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:41
msgid "Focus and focus neighbour"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:42
msgid "Size flags"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:43
msgid "Margin"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:44
msgid "The optional UI theme"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:46
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:51
msgid "The 5 most common UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:53
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:56
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:59
msgid "Label: for displaying text"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:60
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:62
msgid ""
"TextureProgress: for lifebars, loading bars, horizontal, vertical or radial"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:64
msgid "NinePatchRect: for scalable panels"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:65
msgid "TextureButton: to create buttons"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:69
msgid "The 5 most common Control nodes for UI design"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:72
msgid "TextureRect"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:74
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 behaviour:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:78
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:79
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:80
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:81
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:84
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:85
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:87
msgid ""
"As with Sprite nodes, you can modulate the TextureRect's colour. Click the "
"``Modulate`` property and use the color picker."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:92
msgid "TextureRect modulated with a red color"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:95
msgid "TextureButton"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:97
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 2-bit, pure black and white image."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:104
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:114
msgid "TextureButton and its 5 texture slots"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:117
msgid "TextureProgress"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:119
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:123
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:128
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 ``1`` 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:138
msgid "TextureProgress bar, two thirds filled"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:143
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:152
msgid "Picture of a Label"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:155
msgid "NinePatchRect"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:157
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, dialogue boxes and scalable "
"backgrounds for your UI."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:164
msgid "NinePatchRect scaled with the min\\_size property"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:167
msgid "There are two workflows to build responsive UIs"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:169
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:171
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:172
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:174
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:176
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:180
msgid "Place UI elements precisely with anchors"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:182
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:189
msgid "The anchor property"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:192
msgid "How to change the anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:194
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:203
msgid "The layout menu in the viewport"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:206
msgid "Anchors are relative to the parent container"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:208
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:218
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:223
msgid "Margins change with the anchor"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:225
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:235
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:237
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:246
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:248
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:258
msgid "3 UI elements in an HBoxContainer, they align horizontally"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:260
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:266
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:269
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:273
msgid "Arrange control nodes automatically with containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:275
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:281
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:286
msgid "The 5 most useful containers"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:288
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:291
msgid "MarginContainer, to add margins around part of the UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:292
msgid "CenterContainer, to center its children in its bounding box"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:293
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:295
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:297
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:305
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:308
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:317
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:319
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:328
msgid "The HBoxContainer horizontally aligns UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:330
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:337
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:348
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:350
msgid ""
"Godot's UI system is complex, and has a lot more to offer. To learn how to "
"design more advanced interface, 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 UI 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:33
msgid "How to design your game UI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:35
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:45
msgid "The UI's rough plan or mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:47
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 had players playtest your UI. Otherwise:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:51
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:53
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:57
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:64
msgid "There are two ways to design your UI in Godot. You can:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:66
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:68
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:71
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:78
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:82
msgid "Design the main menu"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:84
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:88
#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:277
msgid "Break down the UI mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:90
msgid "Here are my three rules of thumb to find the right containers:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:92
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:95
msgid "If there's some padding around an area, use a ``MarginContainer``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:96
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:99
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:102
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:111
msgid "Interface building blocks, broken down using the three rules of thumb"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:115
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:120
msgid "Prepare the Main Menu scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:122
msgid ""
"Let's create the main menu. We'll build it in a single scene. To create an "
"empty scene, click on the Scene menu -> New Scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:125
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 ``Meta+S`` to "
"save the scene to the disk. Name it *MainMenu*."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:131
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:135
msgid "Margin Right: *120*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:136
msgid "Margin Top: *80*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:137
msgid "Margin Left: *120*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:138
msgid "Margin Bottom: *80*"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:140
msgid ""
"We want the container to fit the window. In the Viewport, open the "
"``Layout`` menu and select the last option, ``Full Rect``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:144
msgid "Add the UI sprites"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:146
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:149
msgid "The title, or logo"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:150
msgid "The three text options, as individual nodes"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:151
msgid "The version note"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:152
msgid "And the main menu’s illustration"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:154
msgid ""
"Click the ``Add Node`` button or press ``Meta+A`` on your keyboard. Start to "
"type ``TextureRect`` to find the corresponding node and press enter. With "
"the new node selected, press ``Meta+D`` five times to create five extra "
"``TextureRect`` instances."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:159
msgid ""
"Click each of the nodes to select it. In the inspector, click the ``…`` Icon "
"to the right of the Texture property, and click on ``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:165
msgid "The file browser lets you find and load textures"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:167
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 Inspector to "
"rename them"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:174
msgid "The six nodes, with textures loaded"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:178
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:182
msgid "Add containers to place UI elements automatically"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:184
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 "
"behaviour, I recommend to favour box containers."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:195
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:202
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:205
msgid ""
"In the node tree, select all the ``TextureRect`` nodes that should go on the "
"left side: the logo, the menu options and the version note. Drag and drop "
"them into the ``VBoxContainer``. Then, drag the illustration node into the "
"``CenterContainer``. The nodes should position automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:212
msgid "Containers automatically place and resize textures"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:214
msgid "We're left with two problems to solve:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:216
msgid "The characters on the right aren't centered"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:217
msgid "There's no space between the logo and the other UI elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:219
msgid ""
"To center the characters on the right, we'll use a ``CenterContainer``.  Add "
"a ``CenterContainer`` node as a child of the ``HBoxContainer``. 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``. Do the same "
"for the ``Horizontal`` property. Finally drag and drop the Characters into "
"the ``CenterContainer``. The Characters element will center automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:228
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:231
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 ``Meta"
"+A`` 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:241
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:244
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``. The container expands to take all the available vertical "
"space. But it respects its neighbors, the ``Logo`` and ``Version`` elements."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:252
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:257
msgid "The menu options should center vertically in the UI's left column"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:259
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:267
msgid "The final interface"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_main_menu.rst:269
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:272
msgid ""
"Congratulations for getting there! You can download the `final menu <#>`__ "
"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:279
msgid ""
"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:284
msgid ""
"The order in which you nest matters. To see if your UI adapts nicely to "
"different screen ratios, select the root node, press the Q key 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:290
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:296
msgid ""
"You can change the scale mode in the project settings: click the Project "
"menu -> Project Settings. 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 "
"User Interface (GUI) with reusable UI components: a life bar, an energy bar, "
"and bomb and rupee 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:616
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 rupee 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 rupee 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``. Then save the scene as ``GUI.tscn``. It will contain the entire "
"GUI."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:75
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:81
msgid ""
"We want to stack the bars vertically inside the ``HBoxContainer``. To do "
"this, let's add a ``VBoxContainer``. Name it ``Bars``. Select the parent "
"``HBoxContainer`` again and this time, add another ``HBoxContainer``. This "
"one will hold the counters, so 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:89
msgid "You should have 4 containers that look like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:93
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:99
msgid "Create the bars' base"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:101
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:107
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:118
msgid "A ``NinePatchRect`` named ``Background``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:119
msgid "A ``TextureRect`` named ``Title``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:120
msgid "And a ``Label`` named ``Number``"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:122
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:126
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:129
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:135
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:138
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:147
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:155
msgid "If you select both nodes, you should see something like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:157
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 Ctrl Up or 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:164
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:173
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:176
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:189
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:193
msgid "Replace the Label's font"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:195
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:201
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:209
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:221
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:223
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:227
msgid "Add the progress bar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:229
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:232
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:240
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:244
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:248
msgid "Design the bomb and rupee counters"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:250
msgid ""
"The bomb and rupee 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:253
msgid ""
"Under the ``Bar`` node, select ``Count`` and press 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:258
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 background, a ``NinePatchFrame``, 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:267
msgid "Here's how your node tree should look so far"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:269
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:279
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:281
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 little 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:289
msgid "The Number node aligned to the left and centre"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:291
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:299
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:307
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:310
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:317
msgid ""
"While we are at it, let's make it so the ``Counters`` snap to the right edge "
"of the viewport. To achieve this we will set the ``Bars`` container to "
"expand and take all the horizontal space. 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 rightmost of the screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:326
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:330
msgid "Turn the bar and counter into reusable UI components"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:332
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:338
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 ``RupeeCounter``. 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:347
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 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:355
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 place 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:365
msgid "With no extra changes, our Bar is ready to use"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:368
msgid "Use Scene Inheritance to create the remaining elements"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:370
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:378
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:381
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 overrides 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:390
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:395
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:401
msgid "Inherit the Bar Scene to build the LifeBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:403
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 ``Meta"
"+S`` to save the new inherited scene and name it ``LifeBar``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:411
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:413
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:422
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:431
msgid "Design the EnergyBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:433
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:436
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:442
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:447
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:456
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:459
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:467
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:471
msgid ""
"When you duplicate a node from the Scene tree, with ``Meta+D``, 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:476
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:483
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:485
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:489
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:496
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:504
msgid "The Count looks better now it's a bit smaller"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:508
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:515
msgid "Prepare the bomb and rupee counters"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:517
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:524
msgid "The bomb counter is the same as the original Counter scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:526
msgid ""
"Go to ``Scene -> New Inherited Scene`` again and select ``Counter.tscn`` "
"once more. Rename the root node ``RupeeCounter`` and save the scene as "
"``RupeeCounter.tscn``. For this one, we mainly need to replace the bomb icon "
"with the rupee icon. In the FileSystem tab, drag the ``rupees_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 ``RupeeCounter`` container. Shift the "
"rupee icon a little 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:539
msgid "The rupee counter should look about like this"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:542
msgid "Add the UI components to the final GUI"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:544
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:552
msgid "The LifeBar and the EnergyBar align automatically"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:554
msgid ""
"Now, drag and drop the ``BombCounter.tscn`` and ``RupeeCounter.tscn`` scenes "
"onto the ``Counters`` node. They'll resize automatically."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:559
msgid "The nodes resize to take all the available vertical space"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:561
msgid ""
"To let the ``RupeeCounter`` 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:570
msgid "Now both counters have a decent size"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:574
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:577
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 "
"Constant`` 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:588
msgid "The 2 bars align perfectly"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:592
msgid ""
"We could have setup 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:597
msgid "Place the GUI onto the game's mockup"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:599
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:602
msgid "Head to the FileSystem dock and open ``LevelMockup.tscn``."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:604
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:611
msgid ""
"Congratulations for getting to the end of this long tutorial. You can find "
"final project `here <#>`__."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:620
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 "Create a main menu screen"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:29
msgid "Create a 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 on 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 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 organisation 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 <http://"
"gameprogrammingpatterns.com/observer.html>`_. The `full book <http://"
"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 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 parens 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 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:445
msgid ""
"The last two arguments are constants from the ``Tween`` class. "
"``TRANS_LINEAR`` means the animation should be linear. ``EASE_IN`` doesn't "
"do anything with a linear transition, but we must provide this last argument "
"or we'll get an error."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:450
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:469
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:472
msgid "Assign the animated\\_health to the LifeBar"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:474
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:477
msgid "So far, the update\\_health method looks like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:501
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:523
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:525
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:531
msgid "The animation is smooth but the number is broken"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:533
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:555
msgid "Try the game again to see a nice blocky animation."
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:559
msgid "By rounding out animated\\_health we hit two birds with one stone"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:563
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:571
msgid "Fade the bar when the Player dies"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:573
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:578
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:583
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:587
msgid "The signal should already have the Enemy connected to it"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:589
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:597
msgid "You should get these values in the Connecting Signal window"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:601
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:603
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:609
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:611
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:615
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:637
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:641
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:654
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 again, because the transition is linear, the easing "
"does not matter. Here's the complete ``_on_Player_died`` method:"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:679
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:683
msgid "The final result. Congratulations for getting there!"
msgstr ""

#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:687
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/gui/bbcode_in_richtextlabel.rst:16
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 new animation button and name "
"the animation \"intro\" when the dialog appears."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:38
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:46
msgid "Editing the animation"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:48
msgid "The logo will appear from the top of the screen."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:50
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:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:56
msgid "When the dialog appears, confirm that you are creating a new track."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:58
msgid "The keyframe will be added in the animation player editor:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:62
msgid "Move the editor cursor to the end by clicking here:"
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:66
msgid ""
"Change the logo position to ``(118, 0)`` and add a keyframe again. With two "
"keyframes, the animation happens."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:71
msgid ""
"Pressing \"Play selected animation from start. (Shift-D)\" on the animation "
"panel will make the logo descend."
msgstr ""

#: ../../docs/getting_started/step_by_step/animations.rst:76
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:81
msgid ""
"And finally, when running the scene, the animation should look like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:4
#: ../../docs/development/cpp/creating_android_modules.rst:185
#: ../../docs/development/file_formats/tscn.rst:249
#: ../../docs/community/resources.rst:4
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 ""
"So far, :ref:`Nodes <class_Node>` have been the most important datatype in "
"Godot as most of the behaviors and features of the engine are implemented "
"through them. There is another datatype that is equally important: :ref:"
"`Resource <class_Resource>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:15
msgid ""
"Where *Nodes* focus on behaviors, such as drawing a sprite, drawing a 3D "
"model, physics, GUI controls, etc,"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:18
msgid ""
"**Resources** are mere **data containers**. This means that they don't do "
"any action nor process any information. Resources just contain data."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:22
msgid ""
"Examples of resources are :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>`, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:32
msgid ""
"When Godot saves or loads (from disk) a scene (.tscn or .scn), an image "
"(png, jpg), a script (.gd) or pretty much anything, that file is considered "
"a resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:36
msgid ""
"When a resource is loaded from disk, **it is always loaded once**. That "
"means, if there is a copy of that resource already loaded in memory, trying "
"to load the resource again will return the same copy again and again. This "
"corresponds with the fact that resources are just data containers, so there "
"is no need to have them duplicated."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:42
msgid ""
"Typically, every object in Godot (Node, Resource, or anything else) can "
"export properties. Properties can be of many types (like a string, integer, "
"Vector2, etc) and one of those types can be a resource. This means that both "
"nodes and resources can contain resources as properties. To make it a little "
"more visual:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:51
msgid "External vs built-in"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:53
msgid ""
"The resource properties can reference resources in two ways, *external* (on "
"disk) or **built-in**."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:56
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:61
msgid ""
"Pressing the \">\" button on the right side of the preview allows us to view "
"and edit the resources properties. One of the properties (path) shows where "
"it comes from. In this case, it comes from a png image."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:67
msgid ""
"When the resource comes from a file, it is considered an *external* "
"resource. If the path property is erased (or it never had a path to begin "
"with), it is considered a built-in resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:71
msgid ""
"For example, if the path \\`\"res://robi.png\"\\` is erased from the \"path"
"\" property in the above example, and then the scene is saved, the resource "
"will be saved inside the .tscn scene file, no longer referencing the "
"external \"robi.png\". However, even if saved as built-in, and even though "
"the scene can be instanced multiple times, the resource will always be "
"loaded only once. That means, different Robi robot scenes instanced at the "
"same time will still share the same image."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:80
msgid "Loading resources from code"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:82
msgid ""
"Loading resources from code is easy. There are two ways to do it. The first "
"is to use load(), like this:"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:101
msgid ""
"The second way is more optimal, but only works with a string constant "
"parameter because it loads the resource at compile-time."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:116
msgid "Loading scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:117
msgid ""
"Scenes are also resources, but there is a catch. Scenes saved to disk are "
"resources of type :ref:`PackedScene <class_PackedScene>`. This means that "
"the scene is packed inside a resource."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:121
msgid ""
"To obtain an instance of the scene, the method :ref:`PackedScene.instance() "
"<class_PackedScene_instance>` must be used."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:143
msgid ""
"This method creates the nodes in the scene's hierarchy, configures them "
"(sets all the properties) and returns the root node of the scene, which can "
"be added to any other node."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:147
msgid ""
"The approach has several advantages. As the :ref:`PackedScene.instance() "
"<class_PackedScene_instance>` function is pretty fast, adding extra content "
"to the scene can be done efficiently. New enemies, bullets, effects, etc can "
"be added or removed quickly, without having to load them again from disk "
"each time. It is important to remember that, as always, images, meshes, etc "
"are all shared between the scene instances."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:156
msgid "Freeing resources"
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:158
msgid ""
"Resource extends from :ref:`Reference <class_Reference>`. As such, when a "
"resource is no longer in use, it will automatically free itself. Since, in "
"most cases, Resources are contained in Nodes, scripts or other resources, "
"when a node is removed or freed, all the children resources are freed too."
msgstr ""

#: ../../docs/getting_started/step_by_step/resources.rst:167
msgid ""
"Like any object in Godot, not just nodes, resources can be scripted, too. "
"However, there isn't generally much of an advantage, as resources are just "
"data containers."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:4
msgid "File system"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:9
msgid ""
"File systems are yet another hot topic in engine development. The file "
"system manages how the 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 together."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:14
msgid ""
"Initial versions of the Godot engine (and previous iterations before it was "
"named Godot) used a database. Assets were stored in it and assigned an ID. "
"Other approaches were tried as well, such as local databases, files with "
"metadata, etc. In the end the simple approach won and now Godot stores all "
"assets as files in the file system."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:21
#: ../../docs/tutorials/3d/inverse_kinematics.rst:68
msgid "Implementation"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:23
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:30
msgid ""
"In general the Godot file system avoids using metadata files. The reason for "
"this is simple, existing asset managers and VCSs are simply much better than "
"anything we can implement, so Godot tries the best to play along with SVN, "
"Git, Mercurial, Perforce, etc."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:35
msgid "Example of a file system contents:"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:46
msgid "project.godot"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:48
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:52
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:57
msgid "Path delimiter"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:59
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:65
#: ../../docs/tutorials/io/data_paths.rst:16
msgid "Resource path"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:67
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:71
msgid ""
"The path ``res://`` will always point at the project root (where project."
"godot is located, so in fact ``res://project.godot`` is always valid)."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:75
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:81
msgid "User path"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:83
msgid ""
"Writing to disk is often still needed for various 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."
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:88
msgid "Host file system"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:90
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:96
msgid "Drawbacks"
msgstr ""

#: ../../docs/getting_started/step_by_step/filesystem.rst:98
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:103
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:108
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 platorm, 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:114
msgid ""
"It is recommended that your team clearly defines 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:41
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:288
msgid "SceneTree"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:9
msgid ""
"This is where things start getting abstract, but don't panic. There's not "
"much more depth than this."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:12
msgid ""
"In previous tutorials, everything revolved around the concept of nodes. "
"Scenes are simply a collection of nodes. They become active once they enter "
"the *scene tree*."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:16
msgid ""
"This concept deserves going into a little more detail. In fact, the scene "
"system is not even a core component of Godot as it is possible to skip it "
"and write a script (or C++ code) that talks directly to the servers, but "
"making a game that way would be a lot of work."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:22
msgid "MainLoop"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:24
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:29
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:35
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:43
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:46
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:49
msgid ""
"In any case, 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:54
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:57
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:60
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:62
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:65
msgid ""
"When a node is part of the Scene Tree, the :ref:`SceneTree "
"<class_SceneTree>` singleton can be obtained by simply calling :ref:`Node."
"get_tree() <class_Node_get_tree>`."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:71
msgid "Root viewport"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:73
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:88
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:93
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:98
msgid "Scene tree"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:100
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:103
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:108
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, "
"notifications, play sound, groups, etc. When they are removed from the "
"*scene tree*, they lose access."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:114
msgid "Tree order"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:116
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 smaller rank in the tree order will get notified before the current "
"node."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:124
msgid "\"Becoming active\" by entering the *Scene Tree*"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:126
msgid "A scene is loaded from disk or created by scripting."
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:127
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:130
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:133
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:136
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:141
msgid "Changing current scene"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:143
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_change_scene>` function:"
msgstr ""

#: ../../docs/getting_started/step_by_step/scene_tree.rst:161
msgid ""
"This is a quick and useful way to switch scenes but has the drawback that "
"the game will stall until the new scene is loaded and running. At some point "
"in your game, it may be desired 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 ""
"Scene singletons are useful, catering to a common use case where you need to "
"store persistent information between scenes."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:12
msgid "Albeit powerful, the scene system by itself has a few drawbacks:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:14
msgid ""
"There is no common place to store information (e.g. a player's items etc.) "
"required by more than one scene."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:16
msgid ""
"While it is possible for a scene that loads and unloads other scenes as its "
"children to store information common to these child scenes, it is no longer "
"possible to run these scenes by themselves and expect them to work correctly."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:20
msgid ""
"While information can be stored to disk in \\`user://\\` and this "
"information can be loaded by scenes that require it, continuously saving and "
"loading this data when changing scenes is cumbersome and may be slow."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:24
msgid "However there is still a need in Godot to create parts of a scene that:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:26
msgid "Are always loaded, no matter which scene is opened from the editor"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:27
msgid ""
"Can store global variables, such as player information, items, money etc. "
"and share information between scenes"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:29
msgid "Can handle switching scenes and transitions"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:30
msgid ""
"Acts like a singleton, since GDScript does not support global variables by "
"design."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:32
msgid "Auto-loading nodes and scripts caters to this need."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:35
msgid "AutoLoad"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:37
msgid ""
"You can use AutoLoad to load a scene, or a script that inherits from Node (a "
"node will be created and the script will be set to it)."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:40
msgid ""
"To autoload a scene or script, select Project > Project Settings from the "
"menu and switch to the AutoLoad tab. Each entry in the list requires a name, "
"which is used as the name of the node, and the node is always added to the "
"root viewport before any other scenes are loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:47
msgid ""
"This means that any node can access a singleton named \"playervariables\" "
"with:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:60
msgid "Or even simpler using the name directly:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:73
msgid "Custom scene switcher"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:75
msgid ""
"This short tutorial will explain how to make a scene switcher using "
"autoload. For simple scene switching, the :ref:`SceneTree.change_scene() "
"<class_SceneTree_change_scene>` method suffices (described in :ref:"
"`doc_scene_tree`), so this method is for more complex behavior when "
"switching between scenes."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:81
msgid ""
"First download the template from here: :download:`autoload.zip <files/"
"autoload.zip>`, then open it."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:84
msgid ""
"Two scenes are present, scene_a.tscn and scene_b.tscn on an otherwise empty "
"project. Each are identical and contain a button connected to a callback for "
"switching to the other scene. When the project runs, it starts in scene_a."
"tscn. However, this currently does nothing and pressing the button does not "
"work."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:91
msgid "global.gd"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:93
msgid ""
"First of all, create a global.gd script. The easy way to create a resource "
"from scratch is from the new resource button in the inspector tab:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:98
msgid "Save the script as `global.gd`:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:102
msgid ""
"The script should open in the script editor. The next step is to add it to "
"AutoLoad list. Select Project > Project Settings from the menu, switch to "
"the AutoLoad tab and add a new entry with name \"global\" that points to "
"this file:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:109
msgid "Now, whenever you run any of your scenes, the script is always loaded."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:111
msgid ""
"Returning to our script, the current scene needs to be fetched in the "
"`_ready()` function. Both the current scene and `global.gd` are children of "
"root, but the 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:116
msgid ""
"Note: Make sure that global.gd extends Node, otherwise it won't be loaded!"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:146
msgid ""
"Next up is the function for changing the scene. This function frees the "
"current scene and replaces it with the requested one."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:216
msgid ""
"As mentioned in the comments above, we want to avoid the situation of having "
"the current scene being deleted while being used (code from functions of it "
"being run), so using :ref:`Object.call_deferred() "
"<class_Object_call_deferred>` is desired at this point. The result is that "
"execution of the commands in the second function will happen at a later time "
"when no code from the current scene is running."
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:224
msgid ""
"Finally, all that is left is to fill the empty functions in scene_a.gd and "
"scene_b.gd:"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:245
#: ../../docs/tutorials/math/vector_math.rst:276
#: ../../docs/development/cpp/core_types.rst:122
msgid "and"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:265
msgid ""
"Now if you run the project, you can switch between both scenes by pressing "
"the button!"
msgstr ""

#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:268
msgid ""
"To load scenes with a progress bar, check out 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
msgid "From Unity3D 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:14
msgid "Differences"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:17
msgid "Unity"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:17
msgid "Godot"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:19
#: ../../docs/community/contributing/documentation_guidelines.rst:102
msgid "License"
msgstr "مجوز"

#: ../../docs/getting_started/editor/unity_to_godot.rst:19
msgid ""
"Proprietary, closed, free license with revenue caps and usage restrictions"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:19
msgid "MIT license, free and fully open source without any restriction"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:21
msgid "OS (editor)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:21
msgid "Windows, macOS, Linux (unofficial and unsupported)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:21
msgid "Windows, macOS, X11 (Linux, \\*BSD)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
msgid "OS (export)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
msgid "**Desktop:** Windows, macOS, Linux"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:24
msgid "**Mobile:** Android, iOS, Windows Phone, Tizen"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:25
msgid "**Web:** WebAssembly or asm.js"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:26
msgid "**Consoles:** PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:27
msgid ""
"**VR:** Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, "
"HoloLens"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:28
msgid "**TV:** Android TV, Samsung SMART TV, tvOS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:23
msgid "**Desktop:** Windows, macOS, X11"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:24
msgid "**Mobile:** Android, iOS"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:25
msgid "**Web:** WebAssembly"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:26
msgid "**Console:** See :ref:`doc_consoles`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:27
msgid "**VR:** Oculus Rift, SteamVR"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:30
msgid "Scene system"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:30
msgid "Component/Scene (GameObject > Component)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:31
msgid "Prefabs"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:30
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:33
msgid "Third-party tools"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:33
msgid "Visual Studio or VS Code"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:33
msgid ":ref:`External editors are possible <doc_external_editor>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:34
msgid ":ref:`Android SDK for Android export <doc_exporting_for_android>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:36
msgid "Killer features"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:36
msgid "Huge community"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:37
msgid "Large assets store"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:36
msgid "Scene System"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:37
msgid ":ref:`Animation Pipeline <doc_animations>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:38
msgid ":ref:`Easy to write Shaders <doc_shading_language>`"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:39
msgid "Debug on Device"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:46
msgid "The editor"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:48
msgid ""
"Godot Engine provides a rich-featured editor that allows you to build your "
"games. The pictures below display both editors with colored blocks to "
"indicate common functionalities."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:55
msgid ""
"Note that Godot editor allows you to dock each panel at the side of the "
"scene editor you wish."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:57
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. All this contributes to Godot being much friendlier "
"to VCS systems such as Git, Subversion, or Mercurial."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:62
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. In other words, it's easier to understand what a specific scene "
"does at a glance."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:66
msgid ""
"The Inspector in Godot is more minimalist and designed to only show "
"properties. Thanks to this, objects can export a much larger amount of "
"useful parameters to the user without having to hide functionality in "
"language APIs. As a plus, Godot allows animating any of those properties "
"visually, so changing colors, textures, enumerations, or even links to "
"resources in real-time is possible without involving code."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:71
msgid ""
"Finally, the Toolbar at the top of the screen is similar in the sense that "
"it allows controlling the project playback, but projects in Godot run in a "
"separate window, as they don't execute 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:75
msgid ""
"This approach has the disadvantage that the running game can't be explored "
"from different angles (though this may be supported in the future and "
"displaying collision gizmos in the running game is already possible), but in "
"exchange has several advantages:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:79
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:80
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:81
msgid "The editor is more stable because the game runs in a separate process."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:83
msgid ""
"Finally, the top toolbar includes a menu for remote debugging. These options "
"make it simple to deploy to a device (connected phone, tablet, or browser "
"via HTML5), and debug/live edit on it after the game was 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, actually, "
"the favourite feature of most Godot users."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:92
msgid ""
"Unity's scene system consists of embedding all the required assets in a "
"scene and linking them together by setting components and scripts to them."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:95
msgid ""
"Godot's scene system is different: it actually consists in a tree made of "
"nodes. Each node serves a purpose: Sprite, Mesh, Light, etc. Basically, this "
"is similar to Unity scene system. However, 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:100
msgid ""
"For example, think of a platformer level. You would compose it with multiple "
"elements:"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:102
msgid "Bricks"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:103
msgid "Coins"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:104
msgid "The player"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:105
msgid "The enemies"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:108
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:113
msgid ""
"In Godot, you would split your whole scene into 3 separate, smaller scenes, "
"which you would then instance in the main scene."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:115
msgid "**First, a scene for the Player alone.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:117
msgid ""
"Consider the player as a reusable element in other levels. It is composed of "
"one node in particular: an AnimatedSprite node, which contains the sprite "
"textures to form various animations (for example, walking animation)"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:120
msgid "**Second, a scene for the Enemy.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:122
msgid ""
"There again, an enemy is a reusable element in other levels. It is almost "
"the same as the Player node - the only differences are the script (that "
"manages AI, mostly) and sprite textures used by the AnimatedSprite."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:126
msgid "**Lastly, the Level scene.**"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:128
msgid ""
"It is composed of Bricks (for platforms), Coins (for the player to grab) and "
"a certain number of instances of the previous Enemy scene. These will be "
"different, separate enemies, whose behaviour and appearance will be the same "
"as defined in the Enemy scene. Each instance is then considered as a node in "
"the Level scene tree. Of course, you can set different properties for each "
"Enemy node (to change its color, for example)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:134
msgid ""
"Finally, the main scene would then 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:140
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 of the use (see the :ref:`Physics "
"introduction <doc_physics_introduction>`)."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:145
msgid ""
"Question: What are the advantages of this system? Wouldn't this system "
"potentially increase the depth of the scene tree? Besides, Unity allows "
"organizing GameObjects by putting them in empty GameObjects."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:147
msgid ""
"First, this 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:148
msgid ""
"Second, it allows the extraction a subtree of scene to make it a scene of "
"its own, which answers the second and third questions: even if a scene tree "
"gets too deep, it can be split into smaller subtrees. This also allows a "
"better solution for reusability, as you can include any subtree as a child "
"of any node. Putting multiple nodes in an empty GameObject in Unity does not "
"provide the same possibility, apart from a visual organization."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:151
msgid ""
"These are the most important concepts you need to remember: \"node\", "
"\"parent node\", and \"child node\"."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:155
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4
msgid "Project organization"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:159
msgid ""
"We previously observed that there is no perfect solution to set a project "
"architecture. Any solution will work for Unity and Godot, so this point has "
"a lesser importance."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:162
msgid ""
"However, we often observe a common architecture for Unity projects, which "
"consists of having one Assets folder in the root directory that contains "
"various folders, one per type of asset: Audio, Graphics, Models, Materials, "
"Scripts, Scenes, etc."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:165
msgid ""
"As described before, the Godot scene system allows splitting scenes into "
"smaller scenes. Since each scene and subscene is actually one scene 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:171
msgid "Where are my prefabs?"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:173
msgid ""
"The concept of prefabs 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:177
msgid ""
"Godot does not provide prefabs as such, but this functionality is here, "
"again, filled thanks to its scene system: As we saw the scene system is "
"organized as a tree. Godot allows you to save a subtree of a scene as its "
"own scene, thus saved into its own file. This new scene can then be "
"instanced as many times as you want. 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:185
msgid ""
"To be precise, you can modify the parameters of the instance in the "
"Inspector panel. However, the nodes that compose this instance are locked "
"although 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 children nodes to this node, but it is possible. "
"Remember that these new children will belong to the instance, not the "
"'template' scene. If you want to add new children to all the instances of "
"your 'template' scene, then you need to add them in the 'template' scene."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:195
msgid "Glossary correspondence"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:197
msgid ""
"GameObject -> Node Add a component -> Inheriting Prefab -> Externalized "
"branch"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:203
msgid "Scripting: GDScript, C# and Visual Script"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:206
msgid "Design"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:208
msgid ""
"As you may know already, Unity supports C#. C# benefits from its integration "
"with Visual Studio and other features, such as static typing."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:210
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:`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 :ref:`GDScript <doc_gdscript>` and "
"`FAQ <faq>`_ pages. GDScript is strongly attached to the Godot API and is "
"really easy 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:216
msgid ""
"Unity allows you to attach as many scripts as you want to a GameObject. Each "
"script adds a behaviour 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:220
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:224
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:225
msgid ""
"or, your 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:227
msgid ""
"As you can see, it can be easy to turn a scene tree to a mess. This is why "
"it is important to have a real reflection and consider splitting a "
"complicated scene into multiple, smaller branches."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:231
msgid "Connections : groups and signals"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:233
msgid ""
"You can control nodes by accessing them using a script and calling functions "
"(built-in or user-defined) on them. But there's more: You can also place "
"them in a group and call a function on all nodes contained in this group! "
"This is explained in :ref:`this page <doc_scripting_continued>`."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:237
msgid ""
"But there's more! Certain nodes throw signals when certain actions happen. "
"You can connect these signals to call a specific function when they happen. "
"Note that you can define your own signals and send them whenever you want. "
"This feature is documented `here <gdscript.html#signals>`_."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:243
msgid "Using Godot in C++"
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:245
msgid ""
"For your information, Godot also 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 Godot API."
msgstr ""

#: ../../docs/getting_started/editor/unity_to_godot.rst:247
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 little to 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 "Path"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:17
msgid ""
"It is recommended that your Godot binary is 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:23
msgid "Setting the project path"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:25
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:29
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:36
msgid "Or by using the ``--path`` argument:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:42
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:49
msgid "Creating a project"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:52
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:63
msgid "The project can now be opened with Godot."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:67
msgid "Running the editor"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:69
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:77
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:85
msgid "Erasing a scene"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:87
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:96
msgid "Running the game"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:98
msgid ""
"To run the game, simply execute Godot within the project directory or "
"subdirectory."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:105
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:113
msgid "Debugging"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:115
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 both running the game or a simple scene."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:130
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:139
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:145
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:149
msgid "Running a script"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:151
msgid ""
"It is possible to run a simple .gd script from the command line. This "
"feature is especially useful in large projects, for batch conversion of "
"assets or custom import/export."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:155
msgid "The script must inherit from SceneTree or MainLoop."
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:157
msgid "Here is a simple example of how it works:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:168
msgid "And how to run it:"
msgstr ""

#: ../../docs/getting_started/editor/command_line_tutorial.rst:175
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 ""
"While godot has an inbuilt text editor, some developers have a tendency to "
"want to use a text editor they are familiar with. Godot provides this option "
"via the options under ``Editor -> Editor Settings -> Text Editor -> "
"External``"
msgstr ""

#: ../../docs/getting_started/editor/external_editor.rst:13
msgid ""
"There are two fields: the executable path and command line flags. The flags "
"allow you to better integrate the editor with godot. Godot will replace the "
"following inside the flags parameter:"
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/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:19
msgid ""
"In the early days, the engine used the `Lua <http://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/getting_started/scripting/gdscript/gdscript_basics.rst:25
msgid ""
"The last third party scripting language that was used for shipped games was "
"`Squirrel <http://squirrel-lang.org>`__, but it was dropped as well. At that "
"point, it became evident that a custom scripting language could more "
"optimally make use of Godot's particular architecture:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:30
msgid ""
"Godot embeds scripts in nodes. Most languages are not designed with this in "
"mind."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:32
msgid ""
"Godot uses several built-in data types for 2D and 3D math. Script languages "
"do not provide this, and binding them is inefficient."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:34
msgid ""
"Godot uses threads heavily for lifting and initializing data from the net or "
"disk. Script interpreters for common languages are not friendly to this."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:37
msgid ""
"Godot already has a memory management model for resources, most script "
"languages provide their own, which results in duplicate effort and bugs."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:40
msgid ""
"Binding code is always messy and results in several failure points, "
"unexpected bugs and generally low maintainability."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:43
msgid ""
"The result of these considerations is *GDScript*. The language and "
"interpreter for GDScript ended up being smaller than the binding code itself "
"for Lua and Squirrel, while having equal functionality. With time, having a "
"built-in language has proven to be a huge advantage."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:49
msgid "Example of GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:51
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:123
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:128
msgid "Language"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:130
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:135
msgid "Identifiers"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:137
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:143
msgid "Keywords"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:145
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:150
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:154
msgid "Keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:154
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:7
#: ../../docs/getting_started/workflow/assets/importing_images.rst:50
#: ../../docs/tutorials/inputs/inputevent.rst:117
#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:27
#: ../../docs/tutorials/shading/shading_language.rst:50
#: ../../docs/tutorials/shading/shading_language.rst:383
#: ../../docs/tutorials/shading/shading_language.rst:420
#: ../../docs/tutorials/shading/shading_language.rst:460
#: ../../docs/tutorials/shading/shading_language.rst:653
#: ../../docs/tutorials/shading/shading_language.rst:712
#: ../../docs/tutorials/shading/shading_language.rst:792
#: ../../docs/tutorials/shading/shading_language.rst:875
#: ../../docs/tutorials/shading/shading_language.rst:925
#: ../../docs/tutorials/shading/shading_language.rst:948
#: ../../docs/tutorials/shading/shading_language.rst:1003
#: ../../docs/tutorials/shading/shading_language.rst:1040
#: ../../docs/tutorials/shading/shading_language.rst:1085
#: ../../docs/tutorials/shading/shading_language.rst:1098
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:92
#: ../../docs/tutorials/misc/binary_serialization_api.rst:101
#: ../../docs/tutorials/misc/binary_serialization_api.rst:110
#: ../../docs/tutorials/misc/binary_serialization_api.rst:119
#: ../../docs/tutorials/misc/binary_serialization_api.rst:132
#: ../../docs/tutorials/misc/binary_serialization_api.rst:143
#: ../../docs/tutorials/misc/binary_serialization_api.rst:158
#: ../../docs/tutorials/misc/binary_serialization_api.rst:171
#: ../../docs/tutorials/misc/binary_serialization_api.rst:190
#: ../../docs/tutorials/misc/binary_serialization_api.rst:205
#: ../../docs/tutorials/misc/binary_serialization_api.rst:220
#: ../../docs/tutorials/misc/binary_serialization_api.rst:239
#: ../../docs/tutorials/misc/binary_serialization_api.rst:264
#: ../../docs/tutorials/misc/binary_serialization_api.rst:295
#: ../../docs/tutorials/misc/binary_serialization_api.rst:310
#: ../../docs/tutorials/misc/binary_serialization_api.rst:319
#: ../../docs/tutorials/misc/binary_serialization_api.rst:330
#: ../../docs/tutorials/misc/binary_serialization_api.rst:340
#: ../../docs/tutorials/misc/binary_serialization_api.rst:359
#: ../../docs/tutorials/misc/binary_serialization_api.rst:371
#: ../../docs/tutorials/misc/binary_serialization_api.rst:383
#: ../../docs/tutorials/misc/binary_serialization_api.rst:396
#: ../../docs/tutorials/misc/binary_serialization_api.rst:407
#: ../../docs/tutorials/misc/binary_serialization_api.rst:418
#: ../../docs/tutorials/misc/binary_serialization_api.rst:426
#: ../../docs/tutorials/misc/binary_serialization_api.rst:439
#: ../../docs/tutorials/misc/binary_serialization_api.rst:452
#: ../../docs/tutorials/misc/binary_serialization_api.rst:467
msgid "Description"
msgstr "توضیحات"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:156
msgid "if"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:156
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:158
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:160
msgid "See `if/else/elif`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:158
msgid "elif"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:160
msgid "else"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:162
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:695
msgid "for"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:162
msgid "See for_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:164
msgid "do"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:164
msgid "Reserved for future implementation of do...while loops."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:166
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:684
msgid "while"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:166
msgid "See while_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:168
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:724
msgid "match"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:168
msgid "See match_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:170
msgid "switch"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:170
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:172
msgid "Reserved for future implementation."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:172
msgid "case"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:174
msgid "break"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:174
msgid "Exits the execution of the current ``for`` or ``while`` loop."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:176
msgid "continue"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:176
msgid ""
"Immediately skips to the next iteration of the ``for`` or ``while`` loop."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:178
msgid "pass"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:178
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:180
msgid "return"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:180
msgid "Returns a value from a function."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:182
msgid "class"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:182
msgid "Defines a class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:184
msgid "extends"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:184
msgid "Defines what class to extend with the current class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:186
#: ../../docs/tutorials/i18n/locales.rst:360
msgid "is"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:186
msgid "Tests whether a variable extends a given class."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:188
msgid "self"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:188
msgid "Refers to current class instance."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:190
msgid "tool"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:190
msgid "Executes the script in the editor."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:192
msgid "signal"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:192
msgid "Defines a signal."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:194
msgid "func"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:194
msgid "Defines a function."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:196
msgid "static"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:196
msgid "Defines a static function. Static member variables are not allowed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:198
msgid "const"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:198
msgid "Defines a constant."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:200
msgid "enum"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:200
msgid "Defines an enum."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:202
msgid "var"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:202
msgid "Defines a variable."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:204
msgid "onready"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:204
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:206
msgid "export"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:206
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:208
msgid "setget"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:208
msgid "Defines setter and getter functions for a variable."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:210
msgid "breakpoint"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:210
msgid "Editor helper for debugger breakpoints."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:212
msgid "preload"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:212
msgid "Preloads a class or variable. See `Classes as resources`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:214
msgid "yield"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:214
msgid "Coroutine support. See `Coroutines with yield`_."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:216
msgid "assert"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:216
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:218
msgid "remote"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:218
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:220
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:222
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:224
msgid ""
"Networking RPC annotation. See :ref:`high-level multiplayer docs "
"<doc_high_level_multiplayer>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:220
msgid "master"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:222
msgid "slave"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:224
msgid "sync"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:226
msgid "PI"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:226
#, fuzzy
msgid "PI constant."
msgstr "ثابت ها"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:228
msgid "TAU"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:228
#, fuzzy
msgid "TAU constant."
msgstr "ثابت ها"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:230
msgid "INF"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:230
msgid "Infinity constant. Used for comparisons."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:232
msgid "NAN"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:232
msgid "NAN (not a number) constant. Used for comparisons."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:236
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:472
msgid "Operators"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:238
msgid "The following is the list of supported operators and their precedence."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:241
msgid "**Operator**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:241
#: ../../docs/getting_started/workflow/export/feature_tags.rst:32
msgid "**Description**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:243
msgid "``x[index]``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:243
msgid "Subscription, Highest Priority"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:245
msgid "``x.attribute``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:245
msgid "Attribute Reference"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:247
msgid "``is``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:247
msgid "Instance Type Checker"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:249
msgid "``~``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:249
msgid "Bitwise NOT"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:251
msgid "``-x``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:251
msgid "Negative"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:253
msgid "``*`` ``/`` ``%``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:253
msgid "Multiplication / Division / Remainder"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:255
msgid ""
"NOTE: The result of these operations depends on the operands types. If both "
"are Integers, then the result will be an Integer. That means 1/10 returns 0 "
"instead of 0.1. If at least one of the operands is a float, then the result "
"is a float: float(1)/10 or 1.0/10 return both 0.1."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:264
msgid "``+`` ``-``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:264
msgid "Addition / Subtraction"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:266
msgid "``<<`` ``>>``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:266
msgid "Bit Shifting"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:268
msgid "``&``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:268
msgid "Bitwise AND"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:270
msgid "``^``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:270
msgid "Bitwise XOR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:272
msgid "``|``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:272
msgid "Bitwise OR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:274
msgid "``<`` ``>`` ``==`` ``!=`` ``>=`` ``<=``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:274
msgid "Comparisons"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:276
msgid "``in``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:276
msgid "Content Test"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:278
msgid "``!`` ``not``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:278
msgid "Boolean NOT"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:280
msgid "``and`` ``&&``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:280
msgid "Boolean AND"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:282
msgid "``or`` ``||``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:282
msgid "Boolean OR"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:284
msgid "``if x else``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:284
msgid "Ternary if/else"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:286
msgid "``=`` ``+=`` ``-=`` ``*=`` ``/=`` ``%=`` ``&=`` ``|=``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:286
msgid "Assignment, Lowest Priority"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:290
msgid "Literals"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:293
msgid "**Literal**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:293
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:262
msgid "**Type**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:295
msgid "``45``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:295
msgid "Base 10 integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:297
msgid "``0x8F51``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:297
msgid "Base 16 (hex) integer"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:299
msgid "``3.14``, ``58.1e-10``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:299
msgid "Floating point number (real)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:301
msgid "``\"Hello\"``, ``\"Hi\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:301
msgid "Strings"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:303
msgid "``\"\"\"Hello\"\"\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:303
msgid "Multiline string"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:305
msgid "``@\"Node/Label\"``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:305
msgid "NodePath or StringName"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:309
msgid "Comments"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:311
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:319
msgid ""
"Multi-line comments can be created using \"\"\" (three quotes in a row) at "
"the beginning and end of a block of text. Note that this creates a string, "
"therefore, it will not be stripped away when the script is compiled."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:330
msgid "Built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:332
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. (Not ``PoolArray``\\ s like "
"``PoolByteArray`` though, those are passed as values too, so consider this "
"when deciding which to use!)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:339
msgid "Basic built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:341
msgid "A variable in GDScript can be assigned to several built-in types."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:344
#: ../../docs/tutorials/misc/binary_serialization_api.rst:25
msgid "null"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:346
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:350
#: ../../docs/tutorials/misc/binary_serialization_api.rst:27
msgid "bool"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:352
msgid "The Boolean data type can only contain ``true`` or ``false``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:355
msgid "int"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:357
msgid ""
"The integer data type can only contain integer numbers, (both negative and "
"positive)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:361
#: ../../docs/tutorials/misc/binary_serialization_api.rst:31
msgid "float"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:363
msgid "Used to contain a floating point value (real numbers)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:366
msgid ":ref:`String <class_String>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:368
msgid ""
"A sequence of characters in `Unicode format <https://en.wikipedia.org/wiki/"
"Unicode>`_. Strings can contain the `standard C escape sequences <https://en."
"wikipedia.org/wiki/Escape_sequences_in_C>`_. GDScript supports :ref:`format "
"strings aka printf functionality <doc_gdscript_printf>`."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:374
msgid "Vector built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:377
msgid ":ref:`Vector2 <class_Vector2>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:379
msgid ""
"2D vector type containing ``x`` and ``y`` fields. Can also be accessed as "
"array."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:383
msgid ":ref:`Rect2 <class_Rect2>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:385
msgid ""
"2D Rectangle type containing two vectors fields: ``position`` and ``size``. "
"Alternatively contains an ``end`` field which is ``position+size``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:389
msgid ":ref:`Vector3 <class_Vector3>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:391
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:395
msgid ":ref:`Transform2D <class_Transform2D>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:397
msgid "3x2 matrix used for 2D transforms."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:400
msgid ":ref:`Plane <class_Plane>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:402
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:406
msgid ":ref:`Quat <class_Quat>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:408
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:412
msgid ":ref:`AABB <class_AABB>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:414
msgid ""
"Axis-aligned bounding box (or 3D box) contains 2 vectors fields: "
"``position`` and ``size``. Alternatively contains an ``end`` field which is "
"``position+size``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:419
msgid ":ref:`Basis <class_Basis>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:421
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:426
msgid ":ref:`Transform <class_Transform>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:428
msgid ""
"3D Transform contains a Basis field ``basis`` and a Vector3 field ``origin``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:432
msgid "Engine built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:435
msgid ":ref:`Color <class_Color>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:437
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:441
msgid ":ref:`NodePath <class_NodePath>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:443
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:447
msgid ":ref:`RID <class_RID>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:449
msgid "Resource ID (RID). Servers use generic RIDs to reference opaque data."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:452
msgid ":ref:`Object <class_Object>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:454
msgid "Base class for anything that is not a built-in type."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:457
msgid "Container built-in types"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:460
msgid ":ref:`Array <class_Array>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:462
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``. Starting with Godot 2.1, indices may be "
"negative like in Python, to count from the end."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:476
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 "
"also 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:483
msgid ""
":ref:`PoolByteArray <class_PoolByteArray>`: An array of bytes (integers from "
"0 to 255)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:484
msgid ":ref:`PoolIntArray <class_PoolIntArray>`: An array of integers."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:485
msgid ":ref:`PoolRealArray <class_PoolRealArray>`: An array of floats."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:486
msgid ":ref:`PoolStringArray <class_PoolStringArray>`: An array of strings."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:487
msgid ""
":ref:`PoolVector2Array <class_PoolVector2Array>`: An array of :ref:`Vector2 "
"<class_Vector2>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:488
msgid ""
":ref:`PoolVector3Array <class_PoolVector3Array>`: An array of :ref:`Vector3 "
"<class_Vector3>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:489
msgid ""
":ref:`PoolColorArray <class_PoolColorArray>`: An array of :ref:`Color "
"<class_Color>` objects."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:492
msgid ":ref:`Dictionary <class_Dictionary>`"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:494
msgid "Associative container which contains values referenced by unique keys."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:507
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). Note however that like any GDScript identifier, keys written in this "
"form cannot start with a digit."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:521
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:530
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:228
msgid "Data"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:533
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:131
msgid "Variables"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:535
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:547
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:193
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:211
#: ../../docs/development/cpp/object_class.rst:94
msgid "Constants"
msgstr "ثابت ها"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:549
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:563
msgid "Enums"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:565
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:568
msgid ""
"If you pass a name to the enum, it would also put all the values inside a "
"constant dictionary of that name."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:589
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:391
#: ../../docs/tutorials/shading/shading_language.rst:255
msgid "Functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:591
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:604
msgid ""
"A function can ``return`` at any point. The default return value is ``null``."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:607
msgid "Referencing Functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:609
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:613
msgid ""
"To reference a function by name at runtime, (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:626
msgid ""
"Remember that default functions like  ``_init``, and most notifications such "
"as ``_enter_tree``, ``_exit_tree``, ``_process``, ``_physics_process``, etc. "
"are called in all base classes automatically. So there is only a need to "
"call the function explicitly when overloading them in some way."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:634
msgid "Static functions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:636
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:647
msgid "Statements and control flow"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:649
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:654
msgid "if/else/elif"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:656
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:670
msgid "Short statements can be written on the same line as the condition::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:677
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:686
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:697
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:726
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:729
msgid "Basic syntax:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:742
msgid "**Crash-course for people who are familiar to switch statements**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:744
msgid "Replace ``switch`` with ``match``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:745
msgid "Remove ``case``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:746
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:747
msgid "Change ``default`` to a single underscore."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:750
msgid "**Control flow**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:752
msgid ""
"The patterns are matched from top to bottom. If a pattern matches, the "
"corresponding block will be executed. After that, the execution continues "
"below the ``match`` statement. If you want to have a fallthrough you can use "
"``continue`` to stop execution in the current block and check the ones below "
"it."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:756
msgid "There are 6 pattern types:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:768
msgid "constant pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:759
msgid "constant primitives, like numbers and strings ::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:780
msgid "variable pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:771
msgid "matches the contents of a variable/enum ::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:794
msgid "wildcard pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:783
msgid "This pattern matches everything. It's written as a single underscore."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:785
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:807
msgid "binding pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:797
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:826
msgid "array pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:810
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:812
msgid ""
"The length of the array is tested first, it has to be the same size as the "
"pattern, otherwise the pattern don't match."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:814
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:816
msgid "Every subpattern has to be comma separated. ::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:851
msgid "dictionary pattern"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:829
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:831
msgid ""
"The size of the dictionary is tested first, it has to be the same size as "
"the pattern, otherwise the pattern don't match."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:833
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:835
msgid "Every subpattern has to be comma separated."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:837
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:839
msgid "A value pattern is separated from the key pattern with a ``:`` ::"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:862
msgid "Multipatterns:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:854
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:865
msgid "Classes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:867
msgid ""
"By default, the body of a script file is an unnamed class and it can only be "
"referenced externally as a resource or file. Class syntax is meant to be "
"compact and can only contain member variables or functions. Static functions "
"are allowed, but not static members (this is in the spirit of thread safety, "
"since scripts can be initialized in separate threads without the user "
"knowing). In the same way, member variables (including arrays and "
"dictionaries) are initialized every time an instance is created."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:876
msgid "Below is an example of a class file."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:888
msgid "Inheritance"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:890
msgid "A class (stored as a file) can inherit from"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:892
msgid "A global class"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:893
msgid "Another class file"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:894
msgid "An inner class inside another class file."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:896
msgid "Multiple inheritance is not allowed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:898
msgid "Inheritance uses the ``extends`` keyword:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:912
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:926
msgid ""
"To call a function in a *base class* (i.e. one ``extend``-ed in your current "
"class), prepend ``.`` to the function name:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:933
msgid ""
"This is especially useful because functions in extending classes replace "
"functions with the same name in their base classes. So if you still want to "
"call them, you can use ``.`` like the ``super`` keyword in other languages:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:943
msgid "Class Constructor"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:945
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:949
msgid "If a parent constructor takes arguments, they are passed like this:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:957
msgid "Inner classes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:959
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:979
msgid "Classes as resources"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:981
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:997
msgid "Exports"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:999
msgid ""
"Class members can be exported. This means their value gets saved along with "
"the resource (e.g. 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_basics.rst:1008
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 below)."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1011
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_basics.rst:1097
msgid ""
"It must be noted that even if the script is not being run while at the "
"editor, the exported properties are still editable (see below for \"tool\")."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1102
msgid "Exporting bit flags"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1104
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_basics.rst:1113
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_basics.rst:1121
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_basics.rst:1126
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_basics.rst:1130
msgid "Exporting arrays"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1132
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_basics.rst:1169
msgid "Setters/getters"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1171
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:1174
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:1181
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:1198
msgid "Either of the *setter* or *getter* functions can be omitted:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1207
msgid ""
"Get/Setters are especially useful when exporting variables to editor in tool "
"scripts or plugins, for validating input."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1210
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:1225
msgid "Tool mode"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1227
msgid ""
"Scripts, by default, 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:1242
msgid "Memory management"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1244
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:1252
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:1257
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:183
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:164
#: ../../docs/development/cpp/object_class.rst:211
msgid "Signals"
msgstr "سیگنال‌ها"

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1259
msgid ""
"It is often desired to send a notification that something happened in an "
"instance. GDScript supports creation of built-in Godot signals. Declaring a "
"signal in GDScript is easy using the `signal` keyword."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1270
msgid ""
"These signals can be connected in the editor or from code like regular "
"signals. Take the instance of a class where the signal was declared and "
"connect it to the method of another instance:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1286
msgid ""
"It is also possible to bind arguments to a signal that lacks them with your "
"custom values:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1294
msgid ""
"This is useful when a signal from many objects is connected to a single "
"callback and the sender must be identified:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1306
msgid ""
"Finally, emitting a custom signal is done by using the Object.emit_signal "
"method:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1317
msgid "Coroutines with yield"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1319
msgid ""
"GDScript offers support for `coroutines <https://en.wikipedia.org/wiki/"
"Coroutine>`_ via the ``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:1341
#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1365
msgid "Will print:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1349
msgid ""
"It is also possible to pass values between yield() and resume(), for example:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1374
msgid "Coroutines & signals"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1376
msgid ""
"The real strength of using ``yield`` is when combined with signals. "
"``yield`` can accept two parameters, 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:1391
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:1404
msgid ""
"``my_func`` will only continue execution once both the buttons are pressed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1407
msgid "Onready keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1409
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:1421
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:1431
msgid "Assert keyword"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_basics.rst:1433
msgid ""
"The ``assert`` keyword can be used to check conditions in debug builds. "
"These assertions are ignored in non-debug builds."
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 to still create the "
"entire 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
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 on 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 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:317
msgid "For & while"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:319
msgid "Iterating in some statically typed languages can be quite complex:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:340
msgid "This is usually greatly simplified in dynamically typed languages:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:347
msgid ""
"Container datatypes (arrays and dictionaries) are iterable. Dictionaries "
"allow iterating the keys:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:355
msgid "Iterating with indices is also possible:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:362
msgid "The range() function can take 3 arguments:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:370
msgid "Some examples:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:380
msgid "Translate to:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:393
msgid "And backwards looping is done through a negative counter:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:399
msgid "Becomes:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:407
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:384
#, fuzzy
msgid "While"
msgstr "تا زمانی که"

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:409
msgid "while() loops are the same everywhere:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:420
msgid "Custom iterators"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:421
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:453
msgid "And it can be used like any other iterator:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:461
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:465
msgid "Duck typing"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:467
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:472
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:483
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:491
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:500
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:506
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:509
msgid "In this case, it translates to:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:511
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:513
msgid "Yes, we should call it Hulk typing instead."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:515
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 more strict, so checking if the "
"function exists is desirable:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:526
msgid ""
"Then, simply define that method and anything the rock touches can be smashed."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:4
msgid "GDScript Style Guide"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:9
msgid ""
"This styleguide 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 encourage "
"development of auto-formatting tools."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:14
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 styleguide."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:18
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:22
msgid "Code Structure"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:25
msgid "Indentation"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:27
msgid "Indent type: Tabs *(editor default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:29
msgid "Indent size: 4 *(editor default)*"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:31
msgid "Each indent level should be one greater than the block containing it."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:33
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:53
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:83
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:107
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:127
msgid "**Good**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:40
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:61
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:93
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:114
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:137
msgid "**Bad**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:50
msgid ""
"Use 2 indent levels to distinguish continuation lines from regular code "
"blocks."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:70
msgid "Blank lines"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:72
msgid "Surround functions and class definitions by a blank line."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:74
msgid "Use one blank line inside functions to separate logical sections."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:77
msgid "One Statement per Line"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:79
msgid ""
"Never combine multiple statements on a single line. No, C programmers, not "
"with a single line conditional statement (except with the ternary operator)!"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:102
msgid "Avoid Unnecessary Parentheses"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:104
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:122
msgid "Whitespace"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:124
msgid ""
"Always use one space around operators and after commas. Avoid extra spaces "
"in dictionary references and function calls, or to create \"columns.\""
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:147
msgid "**NEVER**:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:156
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:193
msgid "Naming Conventions"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:158
msgid ""
"These naming conventions follow the Godot Engine style. Breaking these will "
"make your code clash with the built-in naming conventions, which is ugly."
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:163
msgid "Classes and Nodes"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:165
msgid "Use PascalCase: ``extends KinematicBody``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:167
msgid "Also when loading a class into a constant or variable:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:174
msgid "Functions and Variables"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:176
msgid "Use snake\\_case: ``get_node()``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:178
msgid ""
"Prepend a single underscore (\\_) to virtual methods (functions the user "
"must override), private functions, and private variables: ``func _ready()``"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:185
msgid "Use past tense:"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:195
msgid ""
"Use CONSTANT\\_CASE, all caps, with an underscore (\\_) to separate words: "
"``const MAX_SPEED = 200``"
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 "``+``"
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:94
#: ../../docs/tutorials/misc/binary_serialization_api.rst:103
#: ../../docs/tutorials/misc/binary_serialization_api.rst:121
#: ../../docs/tutorials/misc/binary_serialization_api.rst:312
#: ../../docs/tutorials/misc/binary_serialization_api.rst:332
#: ../../docs/tutorials/misc/binary_serialization_api.rst:334
#: ../../docs/tutorials/misc/binary_serialization_api.rst:342
#: ../../docs/tutorials/misc/binary_serialization_api.rst:361
#: ../../docs/tutorials/misc/binary_serialization_api.rst:373
#: ../../docs/tutorials/misc/binary_serialization_api.rst:385
#: ../../docs/tutorials/misc/binary_serialization_api.rst:398
#: ../../docs/tutorials/misc/binary_serialization_api.rst:400
#: ../../docs/tutorials/misc/binary_serialization_api.rst:409
#: ../../docs/tutorials/misc/binary_serialization_api.rst:411
#: ../../docs/tutorials/misc/binary_serialization_api.rst:420
#: ../../docs/tutorials/misc/binary_serialization_api.rst:428
#: ../../docs/tutorials/misc/binary_serialization_api.rst:441
#: ../../docs/tutorials/misc/binary_serialization_api.rst:454
#: ../../docs/tutorials/misc/binary_serialization_api.rst:469
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 "``-``"
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:262
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:275
msgid "**Example**"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:242
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:262
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:275
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:195
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
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/c_sharp/c_sharp_differences.rst:174
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:182
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:257
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:264
msgid "Infix (default)"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:264
msgid "\"Hi, {0} v{1}\".format([\"Godette\", \"3.0\"], \"{_}\")"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:264
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
msgid "Hi, Godette v3.0"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
msgid "Postfix"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:266
msgid "\"Hi, 0% v1%\".format([\"Godette\", \"3.0\"], \"_%\")"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
msgid "Prefix"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:268
msgid "\"Hi, %0 v%1\".format([\"Godette\", \"3.0\"], \"%_\")"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:271
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:277
msgid ""
"\"Hi, {0} v{version}\".format({0:\"Godette\", \"version\":\"%0.2f\" % 3.114})"
msgstr ""

#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:277
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
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 to start the editing of 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 case for this is to "
"separate a function into more, or 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:28
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 the beginning, 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 the "
"*Control* key (or Command on Mac). 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\" options "
"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 *Control* (*Command* on Mac) 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 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 "Ctrl-F (Command-F on Mac) 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 as 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
#: ../../docs/tutorials/shading/shading_language.rst:222
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
#, fuzzy
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
#: ../../docs/tutorials/shading/shading_language.rst:712
#: ../../docs/tutorials/shading/shading_language.rst:792
#: ../../docs/tutorials/shading/shading_language.rst:948
#: ../../docs/tutorials/shading/shading_language.rst:1003
#: ../../docs/tutorials/shading/shading_language.rst:1040
#: ../../docs/tutorials/shading/shading_language.rst:1098
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 GDScript (@TODO, link to gdscript methods?). 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:406
msgid "By Type"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:408
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:413
msgid "Call"
msgstr "فراخوانی"

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:415
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:419
msgid "Constructors"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:421
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:427
msgid "Destructor"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:429
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:435
msgid "Emit Signal"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:437
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:441
msgid "Get/Set"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:443
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:447
msgid "Wait"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:449
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:454
msgid "Yield"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:456
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:460
msgid "Yield Signal"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:462
msgid "Same as Yield, but will wait until a given signal is emitted."
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:466
msgid "Index"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:468
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:474
msgid ""
"These are mostly generic operators such as addition, multiplication, "
"comparison, etc. By default, these mostly accept any datatype (and will "
"error in run-time if the types feeded do not match for 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:483
msgid "Expression Node"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:485
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:488
msgid "Expression nodes can:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:490
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:495
msgid "Access local variables or properties:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:500
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:505
msgid "Call API functions:"
msgstr ""

#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:510
msgid ""
"Use sequenced mode, which makes more sense in case of respecting the "
"processing order:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/index.rst:2
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:114
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:129
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:142
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:153
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:161
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:180
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:223
msgid "C#"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:6
msgid ""
"C# support is a new feature in 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:11
msgid ""
"This page provides a brief intro 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:16
msgid ""
"C# is a high-level programming language developed by Microsoft. In Godot it "
"is implemented with the Mono 5.x .NET framework including full support for "
"C# 7.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:20
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:25
msgid "Setup C# for Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:27
msgid ""
"To use C# in Godot you must have `Mono <http://www.mono-project.com/download/"
">`_ installed. Godot 3.0.2 requires Mono 5.4, 3.0.3 requires Mono 5.12 on "
"all platforms. You also need MSBuild (at least version 15.0) which should "
"come with the Mono installation."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:30
msgid ""
"For instructions on installing older versions of Mono on Linux see `this "
"page <http://www.mono-project.com/docs/getting-started/install/linux/"
"#accessing-older-releases>`_. Older versions of Mono for MacOS and Windows "
"can be found `here <https://download.mono-project.com/archive/>`_."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:33
msgid ""
"Additionally, your Godot version must have Mono support enabled, so take "
"care to download the **Mono version** of Godot. If you are building Godot "
"from source, make sure to follow the steps to include Mono support in your "
"build outlined on the  :ref:`doc_compiling_with_mono` page."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:37
msgid "Configuring an external editor"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:39
msgid ""
"While Godot does have its own scripting editor, its support for C# is kept "
"minimal, and it's recommended that you use an external IDE or editor, such "
"as Microsoft Visual Studio Code, or MonoDevelop, which provide auto-"
"completion, debugging and other features useful when working with C#. To set "
"it up, in Godot click on ``Editor``, then ``Editor Settings``. Scroll down "
"to the bottom, to the ``Mono`` settings. Under Mono click on ``Editor``, and "
"on that page choose your external editor of choice."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:48
msgid "Creating a C# script"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:50
msgid ""
"After you successfully setup 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:54
msgid ""
"Note that while some specifics change, most of the things work the same when "
"using C# for scripting. If you're new to Godot, you may want to peruse the "
"tutorials on :ref:`doc_scripting` at this point. While some places in the "
"documentation still lack C# examples, most things can be transferred easily "
"from GDScript."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:59
msgid "Project setup and workflow"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:61
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 project (``.csproj``) as well as some utility files and folders (``."
"mono``, sometimes ``Properties``). All of these but ``.mono`` are important "
"and should be kept in your version control system. ``.mono`` can be safely "
"added to the ignore list of your VCS. When troubleshooting, it sometimes can "
"help to delete the ``.mono`` folder and let it regenerate."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:66
msgid ""
"Note that currently there are some issues where the Godot and the C# project "
"don't stay in sync; if you delete, rename or move things like scripts or "
"nodes, they may no longer match up. In this case, it can help to edit the "
"solution files manually."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:69
msgid ""
"Example: If you created a script (e.g. ``Test.cs``) and delete it in Godot, "
"compilation will fail because the now missing file is still expected to be "
"there by the CS project. You can for now simply open up the ``.csproj`` and "
"look for the ``ItemGroup``, there should be a line included like the "
"following:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:80
msgid ""
"Simply remove that line and your project should now again build fine. Same "
"for renaming and moving things, simply rename and move them in the project "
"file if needed."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:83
#: ../../docs/tutorials/io/background_loading.rst:87
#: ../../docs/tutorials/misc/pausing_games.rst:72
msgid "Example"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:85
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:112
msgid ""
"As you can see, the things normally in global scope in GDScript like Godot's "
"``print`` function are available in the ``GD`` namespace. For a list of "
"those, 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:116
msgid ""
"Keep in mind that the class you wish to attach to your node should be named "
"as the ``.cs`` file. If not, 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:120
msgid "General differences between C# and GDScript"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:122
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:126
msgid "For more, see the :ref:`doc_c_sharp_differences` page."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:129
msgid "Current gotchas and known issues"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:131
msgid ""
"As C# support is quite new to Godot, there are some growing pains and things "
"that still 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:134
msgid ""
"As explained above, the C# project isn't always kept in sync automatically "
"when things are deleted, renamed or moved in Godot (`#12917 <https://github."
"com/godotengine/godot/issues/12917>`_)"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:135
msgid "Writing editor plugins and tool scripts in C# is not yet supported"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:136
msgid ""
"Exporting a project may not yet work (`#15615 <https://github.com/"
"godotengine/godot/issues/15615>`_)"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:137
msgid ""
"Signals with parameters are broken in 3.0.2-stable (`#17553 <https://github."
"com/godotengine/godot/issues/17553>`_)"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:140
msgid "Performance of C# in Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:142
msgid ""
"According to some preliminary `benchmarks <https://github.com/cart/godot3-"
"bunnymark>`_, performance of C# in Godot - while generally in the same order "
"of magnitude - is roughly **~4x** that of GDScript in some naive cases. For "
"full performance, 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:147
msgid "Using Nuget Packages in Godot"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:149
msgid ""
"`Nuget <https://www.nuget.org/>`_ Packages can be installed and used with "
"Godot, as with any project. Many IDEs (such as vs code) can 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:164
msgid ""
"Whenever packages are added or modified, run nuget restore in the root of "
"the project directory, to ensure that the nuget packages will be available "
"for msbuild to use, run::"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:4
msgid "Features"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:6
msgid ""
"This page provides an overview over 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:10
msgid "Type Conversion and Casting"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:12
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:19
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:22
msgid "For this, you have various options in C#."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:24
msgid "**Casting and Type Checking**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:26
msgid ""
"Throws ``InvalidCastException`` if the returned node cannot be casted 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:34
msgid "**Using the AS operator**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:36
msgid ""
"The ``as`` operator returns null if the node cannot be casted to Sprite, and "
"for this reason it cannot be used with value types."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:45
msgid "**Type checking using the IS operator**"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:47
msgid ""
"To check if the node can be casted to Sprite, you can use the ``is`` "
"operator. The ``is`` operator returns false if the node cannot be casted to "
"Sprite, otherwise it returns true."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:58
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:63
msgid "C# Signals"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:65
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:67
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:77
msgid ""
"These signals can then be connected either in the editor or from code with "
"``Connect``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:97
msgid "Emitting signals is done with the ``EmitSignal`` method."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:107
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:109
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:129
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:141
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_differences.rst:4
msgid "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`` in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:15
msgid "Global Scope"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:17
msgid ""
"Available under ``Godot.GD``. Some things were moved to their own classes, "
"like Math and Random. See below."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:20
msgid ""
"Global functions like ``print``, ``var2str`` and ``weakref`` are located "
"under ``GD`` in C#."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:23
msgid "``ERR_*`` constants were moved to ``Godot.Error``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:26
#: ../../docs/tutorials/math/index.rst:2
msgid "Math"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:28
msgid ""
"Math functions like ``abs``, ``acos``, ``asin``, ``atan`` and ``atan2`` are "
"located under ``Mathf`` instead of in global scope. ``PI`` is ``Mathf.PI``"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:33
msgid "Random"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:35
msgid ""
"Random functions like ``rand_range`` and ``rand_seed`` are located under "
"``Random``, so use ``Random.RandRange`` instead of ``rand_range``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:39
msgid "Export keyword"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:41
msgid ""
"Use the ``[Export]`` attribute instead of the GDScript ``export`` keyword."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:44
msgid "Signal keyword"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:46
msgid ""
"Use the ``[Signal]`` attribute 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:54
msgid "See also: :ref:`c_sharp_signals`"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:57
msgid "Singletons"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:59
msgid ""
"Singletons provide static methods rather than using the singleton pattern in "
"C#. This is to make code less verbose and similar to GDScript. Example:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:67
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
#: ../../docs/development/cpp/core_types.rst:175
msgid "String"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:69
msgid ""
"Use ``System.String`` (``string``). All the Godot String methods are "
"provided by the ``StringExtensions`` class as extension methods. Example:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:77
msgid "There are a few differences though:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:79
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:83
msgid ""
"``IsSubsequenceOf``/``IsSubsequenceOfi``: An additional method is provided "
"which is an overload of ``IsSubsequenceOf`` allowing to explicitly specify "
"case sensitivity:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:94
msgid ""
"``Match``/``Matchn``/``ExprMatch``: An additional method is provided besides "
"``Match`` and ``Matchn``, which allows to explicitly specify case "
"sensitivity:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:105
#: ../../docs/tutorials/math/matrices_and_transforms.rst:126
#: ../../docs/tutorials/math/matrices_and_transforms.rst:614
msgid "Basis"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:107
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 to ``Basis()`` in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:111
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:126
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:139
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:158
msgid ""
"The following methods were converted to properties with their respective "
"names changed:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133
msgid "get_scale()"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:116
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:133
#: ../../docs/tutorials/2d/particle_systems_2d.rst:265
#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:81
#: ../../docs/tutorials/math/matrices_and_transforms.rst:309
msgid "Scale"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:120
#: ../../docs/tutorials/math/matrices_and_transforms.rst:157
msgid "Transform2D"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:122
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 to ``Transform2D()`` "
"in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:131
msgid "get_origin()"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:131
msgid "Origin"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:132
msgid "get_rotation()"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:132
#: ../../docs/tutorials/math/matrices_and_transforms.rst:223
#: ../../docs/tutorials/animation/cutout_animation.rst:320
msgid "Rotation"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:137
msgid "Plane"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:144
msgid "center()"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:144
msgid "Center"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:148
msgid "Rect2"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:150
msgid ""
"The following fields were converted to properties with their respective "
"names changed:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:155
msgid "end"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:155
msgid "End"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:163
msgid "get_area()"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:163
msgid "Area"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:167
msgid "Quat"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:169
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 to ``Quat()`` in GDScript and C++."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:176
msgid ""
"*This is temporary. Array is ref-counted, so it will need its own type that "
"wraps the native side. PoolArrays will also need their own type to be used "
"the way they are meant to.*"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:182
msgid "object[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:183
msgid "PoolIntArray"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:183
msgid "int[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:184
msgid "PoolByteArray"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:184
msgid "byte[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:185
msgid "PoolFloatArray"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:185
msgid "float[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:186
msgid "PoolStringArray"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:186
msgid "String[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:187
msgid "PoolColorArray"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:187
msgid "Color[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:188
msgid "PoolVector2Array"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:188
msgid "Vector2[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:189
msgid "PoolVector3Array"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:189
msgid "Vector3[]"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:192
msgid ""
"In some exceptional cases a raw array (``type[]``) may be required instead "
"of a ``List``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:197
msgid ""
"*This is temporary. Array is ref-counted, so it will need its own type that "
"wraps the native side.*"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:199
msgid "Use ``Dictionary<object, object>``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:202
msgid "Variant"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:204
msgid "``System.Object`` (``object``) is used in place of ``Variant``."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:207
msgid "Communicating with other scripting languages"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:209
msgid ""
"The methods ``object Object.call(string method, params object[] args)``, "
"``object Object.get(string field)`` and ``object Object.set(string field, "
"object value)`` are provided to communicate with instances of other "
"scripting languages via the Variant API."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:215
msgid "Other differences"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:217
msgid ""
"``preload``, ``assert`` and ``yield`` as they work in GDScript are currently "
"not available in C#."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:220
msgid "Other differences:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:225
msgid "Color8"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:225
msgid "Color.Color8"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
msgid "is_inf"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
msgid "float.IsInfinity"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:227
msgid "is_nan"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:227
msgid "float.IsNaN"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
msgid "dict2inst"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:229
msgid "? TODO"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:229
msgid "inst2dict"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:230
msgid "load"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:230
msgid "GD.load which is the same as ResourceLoader.load"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:4
msgid "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 and "
"contributors of 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 ""
"Currently, Godot uses C# version 6.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.0 or later, such as pattern "
"matching or expression-bodied members inside get/set accessors."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:27
msgid ""
"For detailed information of 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:31
msgid "Formatting Conventions"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:33
msgid ""
"If you create a new file, make sure that it uses linefeed (*LF*) characters "
"to break lines, not *CRLF* or *CR*."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:34
msgid ""
"Use UTF-8 encoding without a byte order mark (BOM <https://en.wikipedia.org/"
"wiki/Byte_order_mark>)."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:35
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:38
msgid "Line Breaks and Blank Lines"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:40
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:57
msgid "However, you may choose to omit line breaks inside brackets,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:59
msgid "For simple property accessors."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:60
msgid "For simple object, array, or collection initializers."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:61
msgid "For abstract auto property, indexer, or event declarations."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:83
msgid "Insert a blank line,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:85
msgid "After *using* statement list."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:86
msgid "Between method, properties, and inner type declarations."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:88
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:91
msgid "Avoid inserting a blank line,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:93
msgid "After an opening bracket ('{')."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:94
msgid "Before a closing bracket ('}')."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:95
msgid "After a comment block, or a single line comment."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:96
msgid "Adjacent to another blank line."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:133
msgid ""
"Consider breaking a line when it's longer than 100 characters. And it's also "
"a good practice to insert a line feed (LF) character at the end of a file "
"because some utilities have trouble recognizing the last line without it (i."
"e. Linux's *cat* command)."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:138
msgid "Using Spaces"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:140
msgid "Insert a space,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:142
msgid "Around a binary and tertiary operator."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:143
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:144
msgid "Before and within a single line accessor block."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:145
msgid "Between accessors in a single line accessor block."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:146
msgid "After a comma."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:147
msgid "After a semi-colon in a *for* statement."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:148
msgid "After a colon in a single line *case* statement."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:149
msgid "Around a colon in a type declaration."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:150
msgid "Around a lambda arrow."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:151
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:153
msgid "Do not use a space,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:155
msgid "After a type cast parentheses."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:156
msgid "Within single line initializer braces."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:158
msgid ""
"The following example shows a proper use of spaces, according to some of the "
"the above mentioned conventions:"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:195
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:216
msgid ""
"Use *camelCase* for all other identifiers (i.e. local variables, method "
"arguments), and use 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:230
msgid ""
"There's an exception with acronyms which consist of two letters like *'UI'* "
"which should be written in upper case letters when used where Pascal case "
"would be expected, and in lower case letters otherwise."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:233
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:244
msgid ""
"It is generally discouraged to use a type name as a prefix of an identifier "
"like *'string strText'* or *'float fPower'*, for example. However, there's "
"an exception about interfaces, in which case they **should** be named using "
"an upper case *'I'* as a prefix, like *'IInventoryHolder'* or "
"*'IDamageable'*."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:248
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:251
msgid ""
"For instance, if you want to write a code to find a nearby enemy and hit "
"with an weapon, prefer"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:257
msgid "Rather than,"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:264
msgid "Implicitly Typed Local Variables"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:266
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:296
msgid "Other Considerations"
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:298
msgid "Use explicit access modifiers."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:299
msgid "Use properties instead of non-private fields."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:300
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:301
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:302
msgid "Remove unused *'using'* statements and unnecessary parentheses."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:303
msgid "Consider omitting default initial value for a type."
msgstr ""

#: ../../docs/getting_started/scripting/c_sharp/c_sharp_style_guide.rst:304
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:305
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/workflow/index.rst:2
msgid "Project workflow"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/index.rst:2
msgid "Project setup"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:9
msgid ""
"This tutorial is aimed to propose a simple workflow on how to organize "
"projects. Since Godot allows the programmer to use the file-system as they "
"please, figuring out a way to organize the projects when starting to use the "
"engine can be a little challenging. Because of this, a simple workflow will "
"be described, which can be used or not, but should work as a starting point."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:16
msgid ""
"Additionally, using version control can be challenging so this proposition "
"will include that too."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:20
msgid "Organization"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:22
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:25
msgid ""
"Unlike other engines, a lot of resource 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:28
msgid ""
"Considering that, the most common approach is to group assets close to "
"scenes as, when a project grows, it makes it more maintainable."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:31
msgid ""
"As example, base sprite images, 3D model scenes or meshes, materials, etc. "
"can usually be organized in a place, while a separate folder is used to "
"store built levels that use them."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:52
msgid "Importing"
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:54
msgid ""
"Godot version previous 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:58
msgid ""
"Because of this, assets are now imported from within the project folder "
"transparently."
msgstr ""

#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:61
msgid ""
"If a folder shouldn't be imported into Godot an exception can be made with "
"a .gdignore file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:2
msgid "Godot-Blender-Exporter"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:5
msgid "Details on exporting"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:16
msgid "Disabling specific objects"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:17
msgid ""
"Sometimes you don't want some objects exported (eg 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:23
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:28
msgid "Build Pipeline Integration"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/index.rst:29
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 is 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:132
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:6
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:11
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:19
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:33
msgid "This can take the value of:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:25
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:29
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:32
msgid "None - Do not search for materials. Export them from the Blender file."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:36
#, fuzzy
msgid "Export of Blender materials"
msgstr "منوی خروجی گرفتن"

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:38
msgid ""
"The other way materials are handled is for the exporter to export them from "
"Blender. Currently only the diffuse color and a few flags (eg unshaded) are "
"exported."
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:43
msgid ""
"Export of Blender materials is currently very primitive. However, it is the "
"focus of a current GSOC project"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/material.rst:47
msgid ""
"Materials are currently 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:2
#: ../../docs/tutorials/3d/introduction_to_3d.rst:214
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
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/physics.rst:2
msgid "Physics Properties"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:3
msgid ""
"Exporting physics properties is done by enabling \"Rigid Body\" in Blenders "
"physics tab:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:9
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:15
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/physics/physics_introduction.rst:55
msgid "Collision Shapes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:24
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:38
msgid "There are the following caveats:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:32
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:35
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 it's collision group. Most of the time, this is "
"what you want."
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:48
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 objects "
"maximum draw type to Wire:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/escn_exporter/physics.rst:55
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/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, audios, "
"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, audios, 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\". The parameters "
"used will be only for this asset and will be used on future reimports."
msgstr ""

#: ../../docs/getting_started/workflow/assets/import_process.rst:34
msgid ""
"Changing 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 save time on "
"reimporting time when checking out in 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 importing 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 "Compression:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:30
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:34
msgid "Compress Mode"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:36
msgid ""
"VRAM Compression: This is the most common compression mode for 3D assets. "
"File on disk is reduced and video memory usage is also reduced considerably. "
"For 3D, it may present unwanted artifacts, though."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:38
msgid ""
"Lossless Compression: This is the most common compression 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, "
"though."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:40
msgid ""
"Lossy Compression: For games with lots of large 2D assets, lossy compression "
"can be a great choice. It has some artifacting, but less than VRAM and the "
"file size is almost a tenth of Lossless."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:42
msgid ""
"Uncompressed: Only useful for formats that can't be compressed (like, raw "
"float)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:44
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:48
msgid "Uncompressed"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:48
msgid "Compress Lossless (PNG)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:48
msgid "Compress Lossy (WebP)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:48
msgid "Compress VRAM"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:50
msgid "Stored as raw pixels"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:50
msgid "Stored as PNG"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:50
msgid "Stored as WebP"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:50
msgid "Stored as S3TC/BC,PVRTC/ETC, depending on platform"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
msgid "Size on Disk"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
#: ../../docs/getting_started/workflow/assets/importing_images.rst:54
msgid "|bad| Large"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
msgid "|regular| Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
msgid "|good| Very Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:54
msgid "Memory Usage"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:54
msgid "|good| Small"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:56
#: ../../docs/tutorials/2d/canvas_layers.rst:70
msgid "Performance"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:56
#: ../../docs/getting_started/workflow/assets/importing_images.rst:60
msgid "|regular| Normal"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:56
#: ../../docs/getting_started/workflow/assets/importing_images.rst:60
msgid "|good| Fast"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:58
msgid "Quality Loss"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:58
msgid "|good| None"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:58
msgid "|regular| Slight"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:58
msgid "|bad| Moderate"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:60
msgid "Load Time"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:60
msgid "|bad| Slow"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:70
msgid "HDR Mode"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:72
msgid ""
"Godot supports high dynamic range textures (as .HDR or .EXR). These are "
"mostly useful as high dynamic range equirectancular panorama skys (the "
"internet has plenty of if you look 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:75
msgid ""
"If you want Godot to ensure full compatibility in for kind of textures, "
"enable the \"Force RGBE\" option."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:78
msgid "Normal Map"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:80
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:86
#: ../../docs/tutorials/3d/spatial_material.rst:20
msgid "Flags"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:88
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:91
msgid "Repeat"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:93
msgid ""
"This setting is mosty commonly used in 3D than 2D (thus it's generally "
"disabled in 2D). It makes UV coordinates going beyond the 0,0 - 1,1 range to "
"\"loop\". Repeating can optionally be set to mirrored mode."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:97
msgid "Filter"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:99
msgid ""
"When pixels become larger than the screen pixels, this options enable 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:103
msgid "Mipmaps"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:105
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:108
msgid "Texture width and height must be powers of 2"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:109
msgid "Repeat must be enabled"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:111
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:113
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:116
msgid "Anisotropic"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:118
msgid ""
"When textures are near parallel to the view (like floors), this option makes "
"them have more detail by reducing blurryness."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:121
msgid "SRGB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:123
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:127
msgid "Process"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:129
msgid ""
"Some special processes can be applied to images when importe as texture."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:132
msgid "Fix Alpha Border"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:134
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 likes."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:139
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:142
msgid "Premultiplied Alpha"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:144
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:148
msgid "HDR as SRGB"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:150
msgid ""
"Some few HDR files are broken and contain SRGB color data. It is advised to "
"not use them but, in the worst case, toggling this option on will make them "
"look right."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:154
msgid "Detect 3D"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_images.rst:156
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_audio_samples.rst:4
msgid "Importing audio samples"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:7
msgid "Why importing?"
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. * Wav files use raw data or light "
"compression, require small amount of CPU to play back (hundreds of "
"simultaneous voices in this format are fine), but take up significant space. "
"* Ogg Vorbis files use a stronger compression that results in much smaller "
"file size, but uses significantly more processor to play back."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:19
msgid "Here is a comparative chart."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:22
msgid "Format"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:22
msgid "1 Second of Audio"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:24
msgid "WAV 24 bits, 96 kHz, Stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:24
msgid "576kb"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:26
msgid "WAV 16 bits, 44 kHz, Mono"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:26
msgid "88kb"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:28
msgid "WAV 16 bits, IMA-ADPCM, Mono"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:28
msgid "22kb"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:30
msgid "OGG 128kbps, Stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:30
msgid "16kb"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:32
msgid "OGG Vorbis 96kbps, Stereo"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:32
msgid "12kb"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:35
msgid ""
"In general, what is recommended, is to use WAV for most sound effects, "
"especially those that are short and repetitive, and OGG for music, voice and "
"long sound effects."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:38
msgid "Best Practices"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:40
msgid ""
"Godot 3+ has an amazing bus system 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:47
msgid "As you can see above, sound effects become huge with reverb added."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:50
msgid "Trimming"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:52
msgid ""
"One issue that happens often is that the waveform are 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:57
msgid "Importing as WAV with the Trimming option enabled solves this."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:61
msgid "Looping"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_audio_samples.rst:63
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:68
msgid ""
"As an alternative, the import screen 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 "Translators also usually prefer to work with spreadsheets."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:36
msgid "Translation format"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:38
msgid ""
"To complete the picture and allow efficient support for translations, Godot "
"has a special importer that can read CSV files. All spreadsheet editors (be "
"it Libreoffice, Microsoft Office, Google Docs, etc.) can export to this "
"format, so the only requirement is that the files have a special "
"arrangement. The CSV files must be saved in UTF-8 encoding and be formatted "
"as follows:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:46
msgid "<lang1>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:46
msgid "<lang2>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:46
msgid "<langN>"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:48
msgid "KEY1"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:48
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:50
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:52
#: ../../docs/tutorials/misc/binary_serialization_api.rst:33
msgid "string"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:50
msgid "KEY2"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:52
msgid "KEYN"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:55
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). Here's an example:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
#: ../../docs/tutorials/i18n/locales.rst:352
msgid "id"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
#: ../../docs/tutorials/i18n/locales.rst:178
msgid "en"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
#: ../../docs/tutorials/i18n/locales.rst:220
msgid "es"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
#: ../../docs/tutorials/i18n/locales.rst:372
msgid "ja"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:63
msgid "GREET"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:63
msgid "Hello, friend!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:63
msgid "Hola, Amigo!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:63
msgid "こんにちは"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:65
msgid "ASK"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:65
msgid "How are you?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:65
msgid "Cómo está?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:65
msgid "元気ですか"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:67
msgid "BYE"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:67
msgid "Good Bye"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:67
msgid "Adiós"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:67
msgid "さようなら"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:71
msgid "CSV Importer"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_translations.rst:73
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:76
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_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 fomats*:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:16
msgid "DAE (Collada), which is currently the most mature workflow."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:17
msgid ""
"GLTF 2.0. Both text and binary formats are supported. Godot has full support "
"for it, but the format is new and gaining traction."
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:20
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:23
msgid "Why not FBX?"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:25
msgid ""
"Most game engines use the FBX format for importing 3D scenes, which is "
"definitely one of the most standardized in the industry. However, this "
"format requires the use of a closed library from Autodesk which is "
"distributed with a more restrictive licensing terms than Godot."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:30
msgid ""
"The plan is, sometime in the future, to offer a binary plug-in using "
"GDNative."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:33
msgid "Exporting DAE files from Maya and 3DS Max"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:35
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:43
msgid "Exporting DAE files from Blender"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:45
msgid ""
"Blender has built-in collada support too, but it's also broken and should "
"not be used."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:48
msgid ""
"Godot provides a `Python Plugin <https://github.com/godotengine/collada-"
"exporter>`__ that will do a much better job of exporting the scenes."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:53
msgid "Exporting ESCN files from Blender"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55
msgid ""
"The most powerful one, called `godot-blender-exporter <https://github.com/"
"godotengine/godot-blender-exporter>`__. It uses .escn files which is kind of "
"another name of .tscn file(Godot scene file), it keeps as much information "
"as possible from a Blender scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:60
msgid ""
"ESCN exporter has a detailed `document <escn_exporter/index.html>`__ "
"describing its functionality and usage."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:64
msgid "Import workflows"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66
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:69
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:70
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:71
msgid ""
"External animations: Allowing saved animations to be modified and merged "
"when sources change."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:72
msgid ""
"External scenes: Save the root nodes of the imported scenes each as a "
"separate scene."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:73
msgid "Single Scene: A single scene file with everything built in."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:77
msgid ""
"As different developers have different needs, this import process is highly "
"customizable."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:80
msgid "Import Options"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:82
msgid "The importer has several options, which will be discussed below:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:87
msgid "Nodes:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:90
msgid "Root Type"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:92
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:95
msgid "Root Name"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:97
msgid "Allows setting a specific name to the generated root node."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:100
msgid "Custom Script"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:102
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:106
msgid "Create a script that like this:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:117
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:122
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:141
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:236
msgid "Storage"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124
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:128
msgid ""
"Of course, instancing such imported scenes in other places manually works "
"too."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:135
msgid "Location"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:137
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:143
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:147
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:151
msgid "Keep on Reimport"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153
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:158
msgid "Compress"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160
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:173
msgid "These are:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:164
msgid ""
"Transform Matrix (Location, rotation, and scale)             : 32-bit float "
"to 16-bit signed integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165
msgid ""
"Vertices                                                     : 32-bit float "
"to 16-bit signed integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166
msgid ""
"Normals                                                      : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:167
msgid ""
"Tangents                                                     : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:168
msgid ""
"Vertex Colors                                                : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:169
msgid ""
"UV                                                           : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:170
msgid ""
"UV2                                                          : 32-bit float "
"to 32-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:171
msgid ""
"Vertex weights                                               : 32-bit float "
"to 16-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:172
msgid ""
"Armature bones                                               : 32-bit float "
"to 16-bit unsigned integer."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:173
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:177
msgid "Additional info:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:176
msgid ""
"UV2 = The second UV channel for detail textures and baked lightmap textures."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177
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:179
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(s) may lead to gaps in geometry or vertices not being exactly "
"where they should be."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185
msgid "Meshes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:188
msgid "Ensure Tangents"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:190
msgid ""
"If textures with normalmapping 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:198
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:201
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:205
msgid "External Files"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:207
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:211
msgid "Animation Options"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:213
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:220
msgid "Import of animations is enabled by default."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:223
msgid "FPS"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225
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 minimal jitter."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:230
msgid "Filter Script"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:232
msgid ""
"It is possible to specify a filter script in a special syntax to decide "
"which tracks from which animations should be kept. (@TODO this needs "
"documentation)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:238
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:243
msgid "Optimizer"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:245
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:249
msgid "Clips"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:251
msgid ""
"It is possible to specify multiple animations from a single timeline as "
"clips. Specify from which frame to which frame each clip must be taken (and, "
"of course, don't forget to specify the FPS option above)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:255
msgid "Scene Inheritance"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257
msgid ""
"In many cases, it may be desired to do 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:260
msgid ""
"It is possible, however, to do 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:265
msgid "In inherited scenes, the only limitations for modifications are:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267
msgid "Nodes can't be removed (but can be added anywhere)."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268
msgid ""
"Sub-Resources can't be edited (save them externally as described above for "
"this)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:270
msgid "Other than that, everything is allowed!"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:273
msgid "Import Hints"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:275
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:277
msgid "Adding collision detection to objects:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:278
msgid "Setting objects as navigation meshes"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:279
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:281
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:286
msgid "Remove nodes (-noimp)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:288
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:292
msgid "Create collisions (-col, -colonly, -convcolonly)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:294
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:297
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:300
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:304
msgid ""
"Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead "
"of :ref:`class_concavepolygonshape`."
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:306
msgid ""
"Option \"-colonly\" can be also used with Blender's empty objects. On import "
"it will create a :ref:`class_staticbody` with collision node as a child. "
"Collision node will have one of predefined shapes, depending on the "
"Blender's empty draw type:"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313
msgid "Single arrow will create :ref:`class_rayshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:314
msgid "Cube will create :ref:`class_boxshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:315
msgid "Image will create :ref:`class_planeshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:316
msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:318
msgid ""
"For better visibility in Blender's editor 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:322
msgid "Create navigatopm (-navmesh)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:324
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:328
msgid "Rigid Body (-rigid)"
msgstr ""

#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:330
msgid "Creates a rigid body from this mesh."
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:7
msgid "Why exporting?"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:9
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:13
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:18
msgid "On PC"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:20
msgid ""
"Distributing a game project on PC with Godot is rather easy. Drop the godot."
"exe (or godot) binary together in the same place as the engine.cfg file, zip "
"it and you are done. This can be taken advantage of to make custom "
"installers."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:25
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, etc."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:31
msgid ""
"Another reason is that, for distribution, the developer might prefer a "
"specially compiled binary, which is smaller in size, more optimized and does "
"not include tools inside (like the editor, debugger, etc.)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:35
msgid ""
"Finally, Godot has a simple but efficient system for creating DLCs as extra "
"package files."
msgstr ""
"در نهایت، Godot سیستمی ساده اما کارآمد برای ایجاد DLC به عنوان بسته‌های اضافی "
"دارد."

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:39
msgid "On mobile"
msgstr "در موبایل"

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:41
msgid ""
"The same scenario in mobile is a little worse. To distribute a project in "
"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 PVRCT (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
#, fuzzy
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."
msgstr "منوی خروجی گرفتن باز می‌شود، اما کاملا خالی خواهد بود."

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:72
msgid ""
"That is because we need to add an export preset. To do that 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 ""
"به این دلیل که باید ابتدا یک پیش‌تنظیم خروجی (Export Preset) اضافه کنیم. برای "
"انجام آن روی دکمه‌ی `اضافه کردن ...` که در بالای منوی خروجی گرفتن قرار دارد "
"کلیک کنید. یک لیست از پلتفرم‌های مختلف باز میشود تا یکی را برای پیش‌تنظیم "
"خروجی انتخاب کنیم."

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:78
msgid ""
"The default options are often enough to export, so tweaking them is not "
"necessary, but provide extra control. 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:87
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:91
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:199
msgid "Export templates"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:93
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 (a renamed ."
"zip) file from the `download page of the website <https://www.godotengine."
"org/download>`_."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:98
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:104
msgid "Export mode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:106
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:109
msgid "Export every single file in the project"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:110
msgid "Export only resources (+custom filter), this is default."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:111
msgid "Export only selected resources (+custom filter)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:115
msgid ""
"**Export every single file** - This mode exports every single file in the "
"project. This is good to test if something is being forgotten, but "
"developers often have a lot of unrelated stuff around in the dev directory, "
"which makes it a bad idea."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:120
msgid ""
"**Export only resources** - Only resources are exported. For most projects, "
"this is enough. However many developers like to use custom datafiles in "
"their games. To compensate for this, filters can be added for extra "
"extensions (like, *.txt,*.csv, etc.)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:125
msgid ""
"**Export only selected resources** - Only select resources from a list are "
"exported. This is probably overkill for most projects, but in some cases it "
"is justified (usually huge projects). This mode offers total control of what "
"is exported. Individual resources can be selected and dependency detection "
"is performed to ensure that everything needed is added. As a plus, this mode "
"allows to \"Bundle\" scenes and dependencies into a single file, which is "
"*really* useful for games distributed on optical media."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:139
msgid "Export from Command Line"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:141
msgid ""
"In production it is useful to automate builds, and Godot supports this with "
"the ``--export`` and ``--export-debug`` command line parameters. Exporting "
"from command line still requires an export template to define the export "
"parameters. A basic invocation of the export would be ``godot --export "
"\"Windows Desktop\" some_name``"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:147
msgid ""
"Which, assuming there is a preset called \"Windows Desktop\" and the "
"template can be found, will export to ``some_name.exe``. 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:152
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:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:156
msgid "The export preset is not marked as runnable"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:157
msgid "The target name ends with `.pck` or with `.zip`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_projects.rst:159
msgid ""
"It is often useful to combine the ``--export`` flag with the ``--path`` "
"flag, and to create a dedicated export template for automated export: "
"``godot --path path/to/project --export \"pck\" game_name.pck``"
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, and it 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 bits (64/32)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:14
msgid "Platform type (desktop/mobile)."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:15
msgid "Supported texture compression in platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:16
msgid "Whether a build is debug or release."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:17
msgid "Many more things."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:19
msgid "Features can be queried in run-time to the singleton API by calling:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:27
msgid "Default features"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:29
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:32
msgid "**Feature Tag**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:34
msgid "**Android**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:34
msgid "Running on Android"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:36
msgid "**HTML5**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:36
msgid "Running on HTML5"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:38
msgid "**JavaScript**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:38
msgid ":ref:`JavaScript singleton <doc_javascript_eval>` is available"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:41
msgid "**OSX**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:41
msgid "Running on macOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:43
msgid "**iOS**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:43
msgid "Running on iOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:45
msgid "**UWP**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:45
msgid "Running on UWP"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:47
msgid "**Windows**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:47
msgid "Running on Windows"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:49
msgid "**X11**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:49
msgid "Running on X11"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:51
msgid "**debug**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:51
msgid "Running on a debug build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:53
msgid "**release**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:53
msgid "Running on a release build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:55
msgid "**32**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:55
msgid "Running on a 32-bit build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:57
msgid "**64**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:57
msgid "Running on a 64-bit build"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:59
msgid "**mobile**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:59
msgid "Host OS is a mobile platform"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:61
msgid "**pc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:61
msgid "Host OS is a PC platform (desktop/laptop)"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:63
msgid "**web**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:63
msgid "Host OS is a Web browser"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:65
msgid "**etc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:65
msgid "Textures using ETC1 compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:67
msgid "**etc2**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:67
msgid "Textures using ETC2 compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:69
msgid "**s3tc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:69
msgid "Textures using S3TC (DXT/BC) compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:71
msgid "**pvrtc**"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:71
msgid "Textures using PVRTC compression are supported"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:75
msgid "Custom features"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:77
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:83
msgid "Overriding project settings"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:85
msgid ""
"Features can be used to override specific configuration values in the "
"*Project Settings*. This allows to better customize any configuration when "
"doing a build."
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:88
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:93
msgid "After overriding, a new field is added for this specific configuration:"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:98
msgid "Default overrides"
msgstr ""

#: ../../docs/getting_started/workflow/export/feature_tags.rst:100
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:106
msgid "Customizing Build"
msgstr "سفارشی سازی ساخت"

#: ../../docs/getting_started/workflow/export/feature_tags.rst:108
msgid ""
"Feature tags can be used to customize a build process too, by writing a "
"custom **ExportPlugin**. They also are 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), zip 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, Mac), 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 lacks "
"tools and debugger."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_pc.rst:16
msgid ""
"Optionally, the files can be bundled inside the executable, though this does "
"not always works properly."
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/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:18
msgid "Export a Godot project to Xcode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:20
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:23
msgid ""
"The following export options are required. Leaving any blank with cause the "
"exporter to throw an error:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:26
msgid "In the **Application** category * **App Store Team ID**"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:28
msgid "Everything in the **Required Icons** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:29
msgid "Everything in the **Landscape Launch Screens** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:30
msgid "Everything in the **Portrait Launch Screens** category"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:32
msgid ""
"After you click **Export Project**, there are still two important options "
"left:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:34
msgid ""
"**Path** is an empty folder that will contain the exported Xcode project "
"files."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:35
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:39
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:43
msgid "When the export completes, the output folder should look like this:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:47
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:52
msgid "Active development considerations"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:54
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:57
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:60
msgid "In the following example:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:62
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:63
msgid "**godot_project_to_export** is the name of the Godot project."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:66
msgid "Steps to link an Godot project folder to Xcode"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:68
msgid "Start from an exported iOS project (follow the steps above)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:69
msgid "In Finder, drag the Godot project folder into the Xcode file browser."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:73
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:78
msgid "See the **godot_project_to_export** folder in the Xcode file browser."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:79
msgid "Delete **exported_xcode_project_name.pck** from the Xcode project."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:83
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:89
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:93
#: ../../docs/tutorials/platform/services_for_ios.rst:4
msgid "Services for iOS"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_ios.rst:95
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 submited 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. Currently, Godot does not support signing of packages, so "
"you need to use external tools to do so."
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 `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
msgid "Signing the package"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:66
msgid "Finally, use ``SignTool.exe`` from the Windows SDK or Visual Studio::"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:71
msgid "Installing the package"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:73
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:76
msgid ""
"It's also possible to install by using the ``Add-AppxPackage`` PowerShell "
"cmdlet."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_uwp.rst:78
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 https://developer.android.com/"
"studio/"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:17
msgid "Install OpenJDK or Oracle JDK"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:18
msgid ""
"Download and install  `OpenJDK <https://github.com/ojdkbuild/ojdkbuild>`__ "
"or `Oracle JDK <http://www.oracle.com/technetwork/java/javase/downloads/"
"index.html>`__. Versions below JDK 8 may not work, some users have reported "
"issues with the jarsigner (used to sign the APKs) in JDK 7."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:21
msgid "Create a debug.keystore"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:23
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:28
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 "Make sure you have adb"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:38
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:43
msgid "Setting it up in Godot"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:45
msgid ""
"Enter the Editor Settings screen. This screens contains the editor settings "
"for the user account in the computer (It's independent from the project)."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:51
msgid "Scroll down to the section where the Android settings are located:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:55
msgid "In that screen, the path to 3 files needs to be set:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:57
msgid "The *adb* executable (adb.exe on Windows)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:58
msgid "The *jarsigner* executable (from JDK 6 or 8)"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:59
msgid "The debug *keystore*"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:61
msgid "Once that is configured, everything is ready to export to Android!"
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 the recent technologies `WebAssembly <https://"
"webassembly.org/>`__ and `WebGL 2.0 <https://www.khronos.org/webgl/>`__ in "
"the user's browser. **Firefox** and **Chromium** (Chrome, Opera) are the "
"most popular supported browsers, **Safari** and **Edge** do not work yet. On "
"**iOS**, all browsers must be based on WebKit (i.e. Safari), so they will "
"also not work."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:15
msgid "Limitations"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:17
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:22
msgid "Exported ``.html`` file must not be reused"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:24
msgid ""
"On export, several text placeholders are replaced in the **generated HTML "
"file** specifically for the given export options. It must not be reused in "
"further exports."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:29
msgid "Using cookies for data persistence"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:31
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:36
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:41
msgid "Full screen and mouse capture"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:43
msgid ""
"Browsers do not allow arbitrarily **entering full screen** at any time. The "
"same goes for **capturing the cursor**. Instead, these actions have to occur "
"as a response to a JavaScript input event. In Godot, this is most easily "
"done by entering full screen from within an input callback such as "
"``_input`` or ``_unhandled_input``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:49
msgid "For the same reason, the full screen project setting is ignored."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:52
msgid "HTTPClient"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:54
msgid ""
"The ``HTTPClient`` implementation for the HTML5 platform has several "
"restrictions:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:57
msgid "Accessing or changing the ``StreamPeer`` is not possible"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:58
msgid "Blocking mode is not available"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:59
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:60
msgid "No chunked responses"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:61
msgid "Host verification cannot be disabled"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:62
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:65
msgid "Unimplemented functionality"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:67
msgid ""
"The following functionality is currently unavailable on the HTML5 platform:"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:69
msgid "Threads"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:70
#: ../../docs/tutorials/plugins/gdnative/index.rst:2
msgid "GDNative"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:71
msgid "Clipboard synchronisation between engine and operating system"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:72
msgid "Networking other than ``HTTPClient``"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:74
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 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:79
msgid "Starting exported games from the local file system"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:81
msgid ""
"Many browsers, Chromium-based browsers specifically, 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:85
msgid ""
"Python offers an easy method for this, using ``python -m SimpleHTTPServer`` "
"with Python 2 or ``python -m http.server`` with Python 3 will serve the "
"current working directory on ``http://localhost:8000``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:90
msgid "Serving the files"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:92
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:96
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:100
msgid ""
"The HTML page is designed to fit the game perfectly without cutting off "
"parts of the canvas when the browser window is scaled to the game's "
"dimensions. 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:105
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:113
msgid ""
"The ``.pck`` file is binary, usually delivered with the MIME-type "
"``application/octet-stream``. The ``.wasm`` file is delivered as "
"``application/wasm``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:117
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:123
msgid "Export options"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:125
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:129
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:132
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:136
msgid ""
"Turning on **Export with Debug** when exporting will, in addition to "
"enabling various debug features of the engine, display a debug output below "
"the canvas when using the default HTML page, displaying JavaScript and "
"engine errors. You can also use the browser-integrated developer console, "
"usually opened with the F12 key, which often shows more information, "
"including WebGL errors."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:145
msgid "Calling JavaScript from script"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:147
msgid ""
"In web builds, the ``JavaScript`` singleton is implemented. If 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:158
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:161
msgid "JavaScript ``number`` is returned as GDScript :ref:`class_float`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:162
msgid "JavaScript ``boolean`` is returned as GDScript :ref:`class_bool`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:163
msgid "JavaScript ``string`` is returned as GDScript :ref:`class_String`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:164
msgid ""
"JavaScript ``ArrayBuffer``, ``TypedArray`` and ``DataView`` are returned as "
"GDScript :ref:`class_PoolByteArray`"
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:173
msgid "Any other JavaScript value is returned as ``null``."
msgstr ""

#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:175
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:186
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/customizing_html5_shell.rst:4
msgid "Customizing the Web export HTML page"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:6
msgid ""
"Rather than the default HTML page that comes with the export templates, it "
"is also possible to use a custom HTML page. This allows drastic "
"customization of the final web presentation and behavior. The path to the "
"custom HTML page is specified in the export options as ``Html/Custom Html "
"Shell``."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:11
msgid ""
"The default HTML page is available in the Godot Engine repository at `/mist/"
"dist/html/default.html <https://github.com/godotengine/godot/blob/master/"
"misc/dist/html/default.html>`_. Some simple use-cases where customizing the "
"default page is useful include:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:15
msgid "Loading files from a different directory"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:16
msgid "Loading a ``.zip`` file instead of a ``.pck`` file as main pack"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:17
msgid "Loading engine files from a different directory than the main pack file"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:18
msgid ""
"Loading some extra files before the engine starts, so they are available in "
"the file system later"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:20
msgid ""
"Passing custom \"command line\" arguments, e.g. ``-s`` to start a MainLoop "
"script"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:23
msgid "Placeholder substitution"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:25
msgid ""
"When exporting the game, several placeholders in the HTML page are "
"substituted by values dependening on the export:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:29
msgid "Placeholder"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:29
msgid "substituted by"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:31
msgid "``$GODOT_BASENAME``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:31
msgid ""
"Basename of exported files without suffixes, e.g. ``game`` when exporting "
"``game.html``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:34
msgid "``$GODOT_DEBUG_ENABLED``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:34
msgid "``true`` if debugging, ``false`` otherwise"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:36
msgid "``$GODOT_HEAD_INCLUDE``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:36
msgid ""
"Custom string to include just before the end of the HTML ``<head>`` element"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:40
msgid ""
"The HTML file must evaluate the JavaScript file ``$GODOT_BASENAME.js``. This "
"file defines a global ``Engine`` object used to start the engine, :ref:`see "
"below <doc_javascript_engine_object>` for details."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:44
msgid ""
"The boot splash image is exported as ``$GODOT_BASENAME.png`` and can be used "
"e.g. in ``<img />`` elements."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:47
msgid ""
"``$GODOT_DEBUG_ENABLED`` can be useful to optionally display e.g. an output "
"console or other debug tools."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:50
msgid ""
"``$GODOT_HEAD_INCLUDE`` is substituted with the string specified by the "
"export option ``Html/Head Include``."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:56
msgid "The ``Engine`` object"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:58
msgid ""
"The JavaScript global object ``Engine`` is defined by ``$GODOT_BASENAME.js`` "
"and serves as an interface to the engine start-up process."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:61
msgid "The object itself has only two methods, ``load()`` and ``unload()``."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:64
msgid "``Engine.load(basePath)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:66
msgid "Loads the engine from the passed base path."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:68
msgid "Returns a promise that resolves once the engine is loaded."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:71
msgid "``Engine.unload()``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:73
msgid ""
"Unloads the module to free memory. This is called automatically once the "
"module is instantiated unless explicitly disabled."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:77
msgid "``Engine.isWebGLAvailable(majorVersion = 1)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:79
msgid ""
"Returns ``true`` if the given major version of WebGL is available, ``false`` "
"otherwise. Defaults to ``1`` for WebGL 1.0."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:83
msgid "Starting an ``Engine`` instance"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:85
msgid ""
"The more interesting interface is accessed by instantiating ``Engine`` using "
"the ``new`` operator:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:92
msgid ""
"This ``Engine`` instance, referred to as ``engine`` with a lower-case ``e`` "
"from here, is a startable instance of the engine, usually a game. To start "
"such an instance, the global ``Engine`` object must be loaded, then the "
"``engine`` instance must be initialized and started."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:98
msgid "``engine.init(basePath)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:100
msgid ""
"Initializes the instance. If the engine wasn't loaded yet, a base path must "
"be passed from which the engine will be loaded."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:103
msgid ""
"Returns a promise that resolves once the engine is loaded and initialized. "
"It can then be started with ``engine.startGame()``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:107
msgid "``engine.preloadFile(file, path)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:109
msgid ""
"This loads a file so it is available in the file system once the instance is "
"started. This must be called **before** starting the instance."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:112
msgid ""
"If ``file`` is a string, the file will be loaded from that URL. If ``file`` "
"is an ``ArrayBuffer`` or a view on one, the buffer will used as content of "
"the file."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:116
msgid ""
"If ``path`` is a string, it specifies the path by which the file will be "
"available. This is mandatory if ``file`` is not a string. Otherwise, the "
"path is derived from the URL of the loaded file."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:120
msgid "Returns a promise that resolves once the file is preloaded."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:123
msgid "``engine.start(arg1, arg2, …)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:125
msgid ""
"Starts the instance of the engine, handing the passed strings as arguments "
"to the ``main()`` function. This allows great control over how the engine is "
"used, but usually the other methods whose names start with ``engine.start`` "
"are simpler to use."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:130
msgid "Returns a promise that resolves once the engine started."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:133
msgid "``engine.startGame(mainPack)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:135
msgid ""
"Starts the game with the main pack loaded from the passed URL string and "
"starts the engine with it."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:138
msgid ""
"If the engine isn't loaded yet, the base path of the passed URL will be used "
"to load the engine."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:141
msgid "Returns a promise that resolves once the game started."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:144
msgid "Configuring start-up behaviour"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:146
msgid ""
"Beside starting the engine, other methods of the engine instance allow "
"configuring the behavior:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:150
msgid "``engine.setUnloadAfterInit(enabled)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:152
msgid ""
"Sets whether the Engine will be unloaded automatically after the instance is "
"initialized. This frees browser memory by unloading files that are no longer "
"needed once the instance is initialized. However, if more instances of the "
"engine will be started, the Engine will have to be loaded again."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:157
msgid "Defaults to ``true``."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:160
msgid "``engine.setCanvas(canvasElem)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:162
msgid ""
"By default, the first canvas element on the page is used for rendering. By "
"calling this method, another canvas can be specified."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:166
msgid "``engine.setCanvasResizedOnStart(enabled)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:168
msgid ""
"Sets whether the canvas will be resized to the width and height specified in "
"the project settings on start. Defaults to ``true``."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:172
msgid "``engine.setLocale(locale)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:174
msgid ""
"By default, the engine will try to guess the locale to use from the "
"JavaScript environment. It is usually preferable to use a server-side user-"
"specified locale, or at least use the locale requested in the HTTP ``Accept-"
"Language`` header. This method allows specifying such a custom locale string."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:181
msgid "``engine.setExecutableName(execName)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:183
msgid ""
"By default, the base name of the loaded engine files is used for the "
"executable name. This method allows specifying another name."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:187
msgid "Customizing the presentation"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:189
msgid "The following methods are used to implement the presentation:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:192
msgid "``engine.setProgressFunc(func)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:194
msgid ""
"This method is used to display download progress. The passed callback "
"function is called with two number arguments, the first argument specifies "
"bytes loaded so far, the second argument specifies the total number of bytes "
"to load."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:206
msgid "If the total is 0, it couldn't be calculated. Possible reasons include:"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:209
msgid "Files are delivered with server-side chunked compression"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:210
msgid "Files are delivered with server-side compression on Chromium"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:211
msgid ""
"Not all file downloads have started yet (usually on servers without multi-"
"threading)"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:214
msgid "``engine.setStdoutFunc(func)``, ``engine.setStderrFunc(func)``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:216
msgid ""
"These methods allow implementing custom behavior for the ``stdout`` and "
"``stderr`` streams. The functions passed in will be called with one string "
"argument specifying the string to print."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:227
msgid ""
"These methods should usually only be used in debug pages. The ``"
"$GODOT_DEBUG_ENABLED`` placeholder can be used to check for this."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:230
msgid ""
"By default, ``console.log()`` and ``console.warn()`` are used respectively."
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:233
msgid "Accessing the Emscripten ``Module``"
msgstr ""

#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:235
msgid ""
"If you know what you're doing, you can access the runtime environment "
"(Emscripten's ``Module``) as ``engine.rtenv``. Check the official Emscripten "
"documentation for information on how to use it: https://kripken.github.io/"
"emscripten-site/docs/api_reference/module.html"
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, kitty ate "
"the USB cable, etc.), it's good to let the user know that it exists."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:16
msgid ""
"Some platforms (at the time of this writing, only Android and Blackberry 10) "
"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 buzz-words, \"One Click "
"Deploy\" (though, it's technically two clicks...)."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:23
msgid "Steps for one-click deploy"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:25
msgid "Configure target platform."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:26
msgid ""
"Configure device (make sure it's in developer mode, likes the computer, usb "
"is recognized, usb cable is plugged, etc.)."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:28
msgid "Connect the device.."
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:29
msgid "And voila!"
msgstr ""

#: ../../docs/getting_started/workflow/export/one-click_deploy.rst:33
msgid "Click once.. and deploy!"
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 game icon will be the Godot icon. Most likely you "
"will want to change that for your game. There are two types of icons that "
"can be changed: the file icon and the taskbar icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:9
msgid "Changing the taskbar icon"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:11
msgid ""
"The taskbar icon is the icon that shows up on the taskbar when your game is "
"running."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:15
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:17
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:22
msgid "Changing the file icon"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:24
msgid ""
"The file icon is the icon of the executable that you click on to start the "
"game."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:28
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:32
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:34
msgid ""
"For Linux users, you will also need to install wine in order to use rcedit. "
"For more information, check https://www.winehq.org/"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:38
msgid ""
"Now you have everything ready for changing the file icon. To do that, you "
"will need to specify the icon when exporting. Go to Project>Export. Assuming "
"you have a windows desktop preset ready, in the options, under Application, "
"you will find Icon, select your desired image in ICO format as your file "
"icon."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:40
msgid ""
"To export an ICO image, you can use GIMP. For more details, 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:42
msgid "Check the documentation for more info about exporting."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:48
msgid "Testing the result"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:50
msgid ""
"You can now export the game and see whether you have change the icons "
"successfully or not. If everything works fine, you will see this."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:56
msgid "Icon (ICO) file requirements"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:58
msgid ""
"Regardless of which program you use to create your ICO file, 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:60
msgid ""
"This is a bit tricky, as can be seen in the following StackOverflow threads: "
"`one <https://stackoverflow.com/questions/3236115/which-icon-sizes-should-my-"
"windows-applications-icon-include>`__, `two <https://stackoverflow.com/"
"questions/40749785/windows-10-all-icon-resolutions-on-all-dpi-settings-"
"format-pixel-art-as-icon>`__."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:62
msgid ""
"Your ICO file should at least contain icons in the following resolutions: "
"16x16, 48x48 and 256x256. They should also be uncompressed. The 256x256 icon "
"*can* be compressed, but this breaks backwards compatibility with Windows XP."
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:65
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 255px. (I.e. 256 or 512 or 1024)"
msgstr ""

#: ../../docs/getting_started/workflow/export/changing_application_icon_for_windows.rst:68
msgid ""
"Note that for high-DPI compression may be used, also they should be using "
"24bpp mode in contrast to the lower resolutions."
msgstr ""

#: ../../docs/tutorials/2d/index.rst:2
msgid "2D"
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 and "
"they will inherit their transform. This means that when moving the parent, "
"the children will be moved too."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:16
msgid ""
"These nodes are placed as direct or indirect children to a :ref:`Viewport "
"<class_Viewport>`, and will be displayed through it."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:19
msgid ""
"Viewport has the property :ref:`Viewport.canvas_transform "
"<class_Viewport_canvas_transform>`, which allows to transform all the "
"CanvasItem hierarchy by a custom :ref:`Transform2D <class_Transform2D>` "
"transform. Nodes such as :ref:`Camera2D <class_Camera2D>`, work by changing "
"that transform."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:25
msgid ""
"Changing the canvas transform is useful because it is a lot more efficient "
"than moving the root canvas item (and hence the whole scene). Canvas "
"transform is a simple matrix that offsets the whole 2D drawing, so it's the "
"most efficient way to do scrolling."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:31
msgid "Not enough..."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:33
msgid ""
"But this is not enough. There are often situations where the game or "
"application may not want *everything* transformed by the canvas transform. "
"Examples of this are:"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:37
msgid ""
"**Parallax Backgrounds**: Backgrounds that move slower than the rest of the "
"stage."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:39
msgid ""
"**HUD**: Heads-up display, or user interface. If the world moves, the life "
"counter, score, etc. must stay static."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:41
msgid ""
"**Transitions**: Effects used for transitions (fades, blends) may also want "
"it to remain at a fixed location."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:44
msgid "How can these problems be solved in a single scene tree?"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:47
msgid "CanvasLayers"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:49
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-place while the world moves."
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:58
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:62
msgid "Here's a diagram of how it looks:"
msgstr ""

#: ../../docs/tutorials/2d/canvas_layers.rst:66
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:72
msgid ""
"Even though there shouldn't be any performance limitation, it is not advised "
"to use excessive amount of layers to arrange drawing order of nodes. The "
"most optimal way will always be arranging them by tree order. 2d nodes also "
"have a property for controlling their drawing order (see :ref:`Node2D."
"z_index <class_Node2D_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 tutorial is created after a topic that is a little dark for most users "
"and explains all the 2D transforms going on for nodes from the moment they "
"draw their content locally to the time they are drawn into the screen."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:15
msgid "Canvas transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:17
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:23
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:28
msgid "Global canvas transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:30
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:37
msgid "Stretch transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:39
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:44
msgid ""
"Input events received in the :ref:`MainLoop._input_event() "
"<class_MainLoop__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_make_input_local>` function was added for convenience."
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:51
msgid "Transform order"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:53
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:59
msgid "Transform functions"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:61
msgid "Obtaining each transform can be achieved with the following functions:"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:64
#: ../../docs/tutorials/shading/shading_language.rst:50
#: ../../docs/tutorials/shading/shading_language.rst:420
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:242
#: ../../docs/tutorials/misc/binary_serialization_api.rst:23
#: ../../docs/tutorials/misc/binary_serialization_api.rst:92
#: ../../docs/tutorials/misc/binary_serialization_api.rst:101
#: ../../docs/tutorials/misc/binary_serialization_api.rst:110
#: ../../docs/tutorials/misc/binary_serialization_api.rst:119
#: ../../docs/tutorials/misc/binary_serialization_api.rst:132
#: ../../docs/tutorials/misc/binary_serialization_api.rst:143
#: ../../docs/tutorials/misc/binary_serialization_api.rst:158
#: ../../docs/tutorials/misc/binary_serialization_api.rst:171
#: ../../docs/tutorials/misc/binary_serialization_api.rst:190
#: ../../docs/tutorials/misc/binary_serialization_api.rst:205
#: ../../docs/tutorials/misc/binary_serialization_api.rst:220
#: ../../docs/tutorials/misc/binary_serialization_api.rst:239
#: ../../docs/tutorials/misc/binary_serialization_api.rst:264
#: ../../docs/tutorials/misc/binary_serialization_api.rst:295
#: ../../docs/tutorials/misc/binary_serialization_api.rst:310
#: ../../docs/tutorials/misc/binary_serialization_api.rst:319
#: ../../docs/tutorials/misc/binary_serialization_api.rst:330
#: ../../docs/tutorials/misc/binary_serialization_api.rst:340
#: ../../docs/tutorials/misc/binary_serialization_api.rst:359
#: ../../docs/tutorials/misc/binary_serialization_api.rst:371
#: ../../docs/tutorials/misc/binary_serialization_api.rst:383
#: ../../docs/tutorials/misc/binary_serialization_api.rst:396
#: ../../docs/tutorials/misc/binary_serialization_api.rst:407
#: ../../docs/tutorials/misc/binary_serialization_api.rst:418
#: ../../docs/tutorials/misc/binary_serialization_api.rst:426
#: ../../docs/tutorials/misc/binary_serialization_api.rst:439
#: ../../docs/tutorials/misc/binary_serialization_api.rst:452
#: ../../docs/tutorials/misc/binary_serialization_api.rst:467
msgid "Type"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:64
#: ../../docs/tutorials/math/matrices_and_transforms.rst:342
#: ../../docs/tutorials/math/matrices_and_transforms.rst:705
msgid "Transform"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:66
msgid "CanvasItem"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:66
msgid ""
":ref:`CanvasItem.get_global_transform() "
"<class_CanvasItem_get_global_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:68
msgid "CanvasLayer"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:68
msgid ""
":ref:`CanvasItem.get_canvas_transform() "
"<class_CanvasItem_get_canvas_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:70
msgid "CanvasLayer+GlobalCanvas+Stretch"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:70
msgid ""
":ref:`CanvasItem.get_viewport_transform() "
"<class_CanvasItem_get_viewport_transform>`"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:73
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:85
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:91
msgid "Feeding custom input events"
msgstr ""

#: ../../docs/tutorials/2d/2d_transforms.rst:93
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 ""
"Tilemaps are a simple and quick way to make 2D game levels. Basically, you "
"start with bunch of reference tiles (or pieces) that can be put on a grid, "
"as many times each as desired - think of it like a map editor:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:15
msgid ""
"Collisions can also be added to the tiles, allowing for both 2D side "
"scrolling and top down games."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:19
msgid "Making a tileset"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:21
msgid ""
"To begin, a tileset needs to be made. Here are some tiles for it. They are "
"all in the same image for optimization reasons. There are so-called *texture "
"packers* that will generate these spritesheets out of your separate texture "
"files. Having them as separate images also works."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:29
msgid ""
"Create a new project and move the above PNG image into the directory. Next "
"go into the image's import settings and turn off ``Filter``, keeping it on "
"will cause issues later. ``Mipmaps`` should already be disabled, if not, "
"disable this too."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:33
msgid ""
"We will be creating a :ref:`TileSet <class_TileSet>` resource. While this "
"resource exports properties, it's pretty difficult to get complex data into "
"it and maintain it. Here is what it would look like to manually edit the "
"resource:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:40
msgid ""
"There's enough properties to get by. With some effort, editing this way can "
"work. But the easiest way to edit and maintain a tileset is exporting it "
"from a specially-crafted scene!"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:45
msgid "TileSet scene"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:47
msgid ""
"Create a new scene with a regular Node or Node2D as root. For each tile you "
"want to define, add a sprite node as a child. Since tiles here are 50x50, "
"you should turn on the grid (``View -> Show Grid`` or ``G`` key) and enable "
"snap (``Use Snap`` icon or ``S`` key). Moving tiles with the mouse might "
"still be a inaccurate so use your arrow keys as well."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:53
msgid ""
"If more than one tile is present in the source image, make sure to use the "
"region property of the sprite to adjust which part of the texture is being "
"used."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:57
msgid ""
"Finally, make sure to name your sprite node correctly. This will ensure "
"that, in subsequent edits to the tileset (for example, if added collision, "
"changed the region, etc), the tile will still be **identified correctly and "
"updated**. This name should be unique."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:62
msgid ""
"Sounds like a lot of requirements, so here's a screenshot that shows where "
"everything of relevance is:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:67
msgid ""
"Continue adding all the tiles, adjusting the offsets if needed (that is, if "
"you have multiple tiles in a single source image). Again, *remember that "
"their names must be unique*."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:74
msgid "Collision"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:76
msgid ""
"To add collision to a tile, create a StaticBody2D child for each sprite. "
"This is a static collision node. Then create a CollisionShape2D or "
"CollisionPolygon as a child of the StaticBody2D. The CollisionPolygon is "
"recommended because it is easier to edit."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:83
msgid ""
"Finally, edit the polygon, this will give the tile a collision and fix the "
"warning icon next to the CollisionPolygon node. **Remember to use snap!** "
"Using snap will make sure collision polygons are aligned properly, allowing "
"a character to walk seamlessly from tile to tile. Also **do not scale or "
"move** the collision and/or collision polygon nodes. Leave them at offset "
"0,0, with scale 1,1 and rotation 0 with respect to the parent sprite."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:92
msgid ""
"Keep adding collisions to the tiles until we are done. Note that BG is just "
"a background, so it should not have a collision."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:97
msgid ""
"OK! We're done! Remember to save this scene for future edit. Name it "
"\"tileset_edit.scn\" or something like that."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:101
msgid "Exporting a TileSet"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:103
msgid ""
"With the scene created and opened in the editor, the next step will be to "
"create a tileset. Use Scene > Convert To > Tile Set from the Scene Menu:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:108
msgid ""
"Then choose a filename, like \"mytiles.tres\". Make sure the \"Merge With "
"Existing\" option is toggled on. This way, every time the tileset resource "
"file is overwritten, existing tiles are merged and updated (they are "
"referenced by their unique name, so again, **name your tiles properly**)."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:117
msgid "Using the TileSet in a TileMap"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:119
msgid ""
"Create a new scene, using any node or node2d as root, and then create a :ref:"
"`TileMap <class_TileMap>` as a child."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:125
msgid ""
"Go to the TileSet property of this node and assign the one created in "
"previous steps:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:130
msgid ""
"Also set the cell size to '50', since that is the size used by the tiles. "
"Quadrant size is a tuning value, which means that the engine will draw and "
"cull the tilemap in blocks of 16x16 tiles. This value is usually fine and "
"does not need to be changed, but can be used to fine tune performance in "
"specific cases (if you know what you are doing)."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:137
msgid "Painting your world"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:139
msgid ""
"With all set, make sure the TileMap node is selected. A red grid will appear "
"on screen, allowing to paint on it with the selected tile on the left "
"palette."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:145
msgid ""
"To avoid accidentally moving and selecting the tilemap node (something "
"common, given it's a huge node), it is recommended that you lock it, using "
"the lock button:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:151
msgid ""
"If you accidentally place a tile somewhere you don't want it to be, you can "
"delete it with ``RMB`` while in the tilemap editor."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:154
msgid ""
"You can also flip and rotate sprites in the TileMap editor (note: flipping "
"the sprite in the TileSet will have no effect). Icons at the top right of "
"the editor allow flipping and rotating of the currently selected sprite - "
"you can also use the A and S keys to flip the sprite horizontally and "
"vertically. With a brick pattern like this tutorial uses, flipping the "
"sprites would create unpleasant discontinuities unless you're flipping an "
"entire region of bricks. But for some kinds of tiles, flipping can be a "
"convenient and space-saving feature."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:164
msgid "Offset and scaling artifacts"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:166
msgid ""
"When using a single texture for all the tiles, scaling the tileset (or even "
"moving to a non pixel-aligned location) will most likely result in filtering "
"artifacts like so:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:172
msgid ""
"This is unavoidable, as it is the way the hardware bilinear filter works. "
"So, to avoid this situation, there are a few workarounds. Try the one that "
"looks better for you:"
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:177
msgid ""
"Disable filtering and mipmaps for either the tileset texture or all tile "
"textures if using separate images (see the :ref:`doc_import_images` asset "
"pipeline tutorial)."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:178
msgid ""
"Enable pixel snap (Set ``Project > Project Settings > Rendering > Quality > "
"2d > Use Pixel Snap`` to true, you can also search for ``Pixel Snap``)."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:180
msgid ""
"Viewport Scaling can often help with shrinking the map (see the :ref:"
"`doc_viewports` tutorial). Simply adding a camera, setting it to ``Current`` "
"and playing around with it's ``Zoom`` may be a good starting point."
msgstr ""

#: ../../docs/tutorials/2d/using_tilemaps.rst:182
msgid ""
"You can use a single, separate image for each tile. This will remove all "
"artifacts but can be more cumbersome to implement and is less optimized."
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 ""
"Managing drawing logic of a large amount of simple objects (in the hundreds "
"of thousands). Using a thousand nodes is probably not nearly as efficient as "
"drawing, but a thousand of draw calls are cheap. Check the \"Shower of "
"Bullets\" demo as example."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:32
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:36
msgid "OK, how?"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:38
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:58
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:62
msgid "Updating"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:64
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:67
msgid ""
"If re-drawing is required because a state or something else changed, simply "
"call :ref:`CanvasItem.update() <class_CanvasItem_update>` in that same node "
"and a new _draw() call will happen."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:71
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:115
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:147
msgid "An example: drawing circular arcs"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:149
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:155
msgid "Arc function"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:158
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 parameters that "
"we have to provide to our drawing. 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:163
msgid ""
"Basically, drawing a shape on screen requires it to be decomposed into a "
"certain number of points linked from one to the following one. 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 reduce its "
"number of points to save processing costs. This is called *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:203
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."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:207
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:212
msgid ""
"The reason why each angle is reduced 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 reduce each angle by 90° in order to start "
"counting from 12 o'clock."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:218
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:226
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 this "
"happens, we simply would need to increase the number of points."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:236
msgid "Draw the arc on screen"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:237
msgid ""
"We now have a function that draws stuff on the screen: It is time to call in "
"the _draw() function."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:264
msgid "Result:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:271
msgid "Arc polygon function"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:272
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 previously, except that we draw a polygon instead of "
"lines:"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:312
msgid "Dynamic custom drawing"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:313
msgid ""
"Alright, we are now able to draw custom stuff on 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:319
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:341
msgid "We make these values change in the _process(delta) function."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:343
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. Since Godot doesn't provide a wrap() function, we'll create it "
"here, as it is relatively simple."
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:352
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:397
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:421
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:424
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, 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:432
msgid ""
"In our case, we simply need to multiply our 'rotation_ang' 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:466
msgid "Let's run again! This time, the rotation displays fine!"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:469
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:134
msgid "Tools"
msgstr ""

#: ../../docs/tutorials/2d/custom_drawing_in_2d.rst:471
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:475
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/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, magic, 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 every particle different and provides a more organic "
"look is the \"randomness\" associated to 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 "Particles2D"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:23
msgid ""
"Particle systems are added to the scene via the :ref:`Particles2D "
"<class_Particles2D>` node. However, 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:30
msgid "ParticlesMaterial"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:32
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 Particles Material."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:38
msgid "Your Particles2D node should now be emitting white points downward."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:44
msgid "Texture"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:46
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:53
msgid "Time Parameters"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:56
msgid "Lifetime"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:58
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:61
msgid "Lifetime: 0.5"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:65
msgid "Lifetime: 4.0"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:70
msgid "One Shot"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:72
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:76
msgid "Preprocess"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:78
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:85
msgid "Speed Scale"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:87
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:92
msgid "Explosiveness"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:94
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:98
msgid "0: Emit particles at regular intervals (default value)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:99
msgid "1: Emit all particles simultaneously."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:101
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:107
msgid "Randomness"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:109
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:117
msgid "Fixed FPS"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:119
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:124
msgid "Fract Delta"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:126
msgid "This can be used to turn Fract Delta on or off."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:129
msgid "Drawing Parameters"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:132
msgid "Visibility Rect"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:134
msgid ""
"The ``W`` and ``H`` values control width and height of the visibility "
"rectangle. The ``X`` and ``Y`` values control the position of the upper-left "
"corner of the visibility rectangle relative to the particle emitter."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:139
msgid "Local Coords"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:141
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:147
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:153
msgid "Draw Order"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:155
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:160
msgid "ParticlesMaterial settings"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:164
msgid "Commented out as not implemented in 3.x for now."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:169
msgid ""
"This is the base angle at which particles emit. Default is ``0`` (down):"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:173
msgid ""
"Changing it will change the emissor direction, but gravity will still affect "
"them:"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:178
msgid ""
"This parameter is useful because, by rotating the node, gravity will also be "
"rotated. Changing direction allows them to be separated."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:182
msgid "Spread"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:184
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)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:191
msgid "Gravity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:193
msgid "The gravity applied to every particle."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:198
msgid "Initial Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:200
msgid ""
"Linear 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:207
msgid "Angular Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:209
msgid "Angular velocity is the initial angular velocity applied to particles."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:212
msgid "Spin Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:214
msgid ""
"Spin velocity is the speed at which particles turn around their center (in "
"degrees/sec)."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:220
msgid "Orbit Velocity"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:222
msgid "Orbit velocity is used to make particles turn around their center."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:227
msgid "Linear Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:229
msgid "The linear acceleration applied to each particle."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:232
msgid "Radial Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:234
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:240
msgid "Tangential Acceleration"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:242
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:248
msgid "Damping"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:250
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:257
msgid "Angle"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:259
msgid ""
"Determines the initial angle of the particle (in degress). This parameter is "
"mostly useful randomized."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:267
msgid "Determines the initial scale of the particles."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:272
msgid "Color"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:274
msgid "Used to change the color of the particles being emitted."
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:277
msgid "Hue variation"
msgstr ""

#: ../../docs/tutorials/2d/particle_systems_2d.rst:279
msgid ""
"The Variation value sets the initial hue variation applied to each particle. "
"The Variation Rand value controls the hue variation randomness ratio."
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:17
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:41
msgid "Setup"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:19
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:23
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:29
msgid "8-Way Movement"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:31
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:37
msgid "Add a script to the kinematic body and add the following code:"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:104
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:109
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:112
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:120
msgid "Rotation + Movement"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:122
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:200
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:204
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:210
msgid "Rotation + Movement (mouse)"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:212
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:272
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:287
msgid "Click-and-Move"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:289
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:346
msgid ""
"Note the ``length()`` 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:351
msgid ""
"Uncommenting the ``rotation`` line will also turn the body to point in its "
"direction of motion if you prefer."
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:354
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:358
msgid "Summary"
msgstr ""

#: ../../docs/tutorials/2d/2d_movement.rst:360
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:363
msgid ""
"You can download this sample project here: :download:`2D_movement_demo.zip "
"<files/2D_movement_demo.zip>`"
msgstr ""

#: ../../docs/tutorials/3d/index.rst:2
msgid "3D"
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` in the wiki (which were especially created for game "
"developers, not mathematicians or engineers) will help pave the way into "
"efficiently developing 3D games."
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 **or inherits** of type Spatial). This "
"transform can be accessed as a 4x3 :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 "
"tool (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:50
msgid ""
"There are two pipelines to import 3D models in Godot. The first and most "
"common one is through the :ref:`doc_importing_3d_scenes` importer, which "
"allows 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:55
msgid ""
"The second pipeline is through the :ref:`doc_importing_3d_meshes` importer. "
"This second method allows 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:61
msgid "Generated geometry"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:63
msgid ""
"It is possible to create custom geometry by using the :ref:`Mesh "
"<class_Mesh>` resource directly. Simply create your arrays and use the :ref:"
"`Mesh.add_surface() <class_Mesh_add_surface>` 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:70
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:75
msgid "Immediate geometry"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:77
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:84
msgid "2D in 3D"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:86
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:94
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:99
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:10
msgid "Environment"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:101
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:108
msgid "3D viewport"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:110
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:116
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 Editor Settings:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:124
msgid "Coordinate system"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:126
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:131
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:138
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:143
msgid "**X** is sides"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:144
msgid "**Y** is up/down"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:145
msgid "**Z** is front/back"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:148
msgid "Space and manipulation gizmos"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:150
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:158
msgid "Some useful keybindings:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:160
msgid ""
"To snap motion or rotation, press the \"s\" key while moving, scaling or "
"rotating."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:162
msgid "To center the view on the selected object, press the \"f\" key."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:165
msgid "View menu"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:167
msgid ""
"The view options are controlled by the \"[ view ]\" menu. Pay attention to "
"this little menu inside the window because it is often overlooked!"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:173
msgid "Default environment"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:175
msgid ""
"When created from the Project Manager, the 3D environment has a default sky."
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:179
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:184
msgid "Cameras"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:186
msgid ""
"No matter how many objects are placed in 3D space, nothing will be displayed "
"unless a :ref:`Camera <class_Camera>` is also added to the scene. Cameras "
"can either work in orthogonal or perspective projections:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:193
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:201
msgid ""
"When dealing with multiple cameras, the following rules are followed for "
"each viewport:"
msgstr ""

#: ../../docs/tutorials/3d/introduction_to_3d.rst:204
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:207
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:210
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:216
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
msgid "Using 3D transforms in Godot"
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 (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:63
msgid "Interpolation"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:65
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:69
msgid "But this does not always have the expected effect when using angles:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:73
msgid "The camera actually rotated the opposite direction!"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:75
msgid "There are a few reasons this may happen:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:77
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:78
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:81
msgid "Say no to Euler Angles"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:83
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:85
msgid "Instead, there is a better way to solve your rotation problems."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:88
msgid "Introducing Transforms"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:90
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:92
msgid ""
"It is also possible to access the world coordinate transform via the "
"``global_transform`` property."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:94
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 "
"be 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:96
msgid "A default basis (unmodified) is akin to:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:124
msgid "This is also an analog to a 3x3 identity matrix."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:126
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:128
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:133
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:137
msgid ""
"The gizmo's arrows show the ``X``, ``Y``, and ``Z`` axes (in red, green, and "
"blue respectively) of the basis, while gizmo's center is at the object's "
"origin."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:141
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:144
msgid "Manipulating Transforms"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:146
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:148
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:165
msgid "A method in Spatial simplifies this:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:182
msgid "This rotates the node relative to the parent node."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:184
msgid ""
"To rotate relative to object space (the node's own transform) use the "
"following:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:198
msgid "Precision Errors"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:200
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:202
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:204
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:215
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:217
msgid ""
"It is recommended you don't 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:231
msgid "Obtaining Information"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:233
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:235
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:248
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:267
msgid "Strafe left:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:284
msgid "Jump:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:304
msgid "All common behaviors and logic can be done with just vectors."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:307
msgid "Setting Information"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:309
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:311
msgid ""
"For such cases, keep the angles and rotations *outside* the transform and "
"set them every frame. Don't try retrieve them and re-use them because the "
"transform is not meant to be used this way."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:313
msgid "Example of looking around, FPS style:"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:356
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:359
msgid "Interpolating with Quaternions"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:361
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:363
msgid "Converting a rotation to quaternion is straightforward."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:386
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 or they also "
"may suffer from numerical precision errors."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:388
msgid ""
"Quaternions are useful when doing camera/path/etc. interpolations, as the "
"result will be always correct and smooth."
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:391
msgid "Transforms are your friend"
msgstr ""

#: ../../docs/tutorials/3d/using_transforms.rst:393
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:395
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/3d_performance_and_limitations.rst:4
msgid "3D performance and limitations"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:9
msgid ""
"Godot follows a balanced performance philosophy. In performance world, there "
"are always trade-offs which consist in trading speed for usability and "
"flexibility. Some practical examples of this are:"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:13
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, less objects are rendered, so efficiency "
"overall improves."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:18
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/3d_performance_and_limitations.rst:22
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/3d_performance_and_limitations.rst:28
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 the fast in some situations and slow in others.. or algorithms "
"that are fast but make usability more difficult."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:33
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/3d_performance_and_limitations.rst:38
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/3d_performance_and_limitations.rst:42
#: ../../docs/tutorials/viewports/viewports.rst:175
msgid "Rendering"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:44
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/3d_performance_and_limitations.rst:48
msgid "Reuse shaders and materials"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:50
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/3d_performance_and_limitations.rst:57
msgid ""
"**Reusing Materials**: The less amount of 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/3d_performance_and_limitations.rst:61
msgid ""
"**Reusing Shaders**: If materials can't be reused, at least try to re-use "
"shaders (or SpatialMaterials with different parameters but same "
"configuration)."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:65
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 blazing fast."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:71
msgid "Pixels cost vs vertex cost"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:73
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/3d_performance_and_limitations.rst:77
msgid ""
"On a modern PC and console, vertex cost is low. GPUs originally only "
"rendered triangles, so all the vertices:"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:80
msgid "Had to be transformed by the CPU (including clipping)."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:82
msgid "Had to be sent to the GPU memory from the main RAM."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:84
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/3d_performance_and_limitations.rst:91
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/3d_performance_and_limitations.rst:96
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/3d_performance_and_limitations.rst:106
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 divide 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, less vertices and triangles can be "
"processed for drawing."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:114
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/3d_performance_and_limitations.rst:121
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/3d_performance_and_limitations.rst:126
msgid ""
"An extra situation where vertex cost must be considered is objects that have "
"extra processing per vertex, such as:"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:129
msgid "Skinning (skeletal animation)"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:130
msgid "Morphs (shape keys)"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:131
msgid "Vertex Lit Objects (common on mobile)"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:134
msgid "Texture compression"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:136
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 increase performance enormously when drawing."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:140
msgid ""
"This is because the main goal of texture compression is bandwidth reduction "
"between memory and the GPU."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:143
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 artifacting resulting from the "
"compression is more noticeable."
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:148
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/3d_performance_and_limitations.rst:152
msgid "Transparent objects"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:154
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/3d_performance_and_limitations.rst:162
msgid "Level of detail (LOD)"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:164
msgid ""
"As also mentioned before, using objects with less 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/3d_performance_and_limitations.rst:172
msgid "Use instancing (MultiMesh)"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:174
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/3d_performance_and_limitations.rst:181
msgid "Bake lighting"
msgstr ""

#: ../../docs/tutorials/3d/3d_performance_and_limitations.rst:183
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/3d_performance_and_limitations.rst:188
msgid ""
"If working on mobile, baking to texture is recommended, since this method is "
"even faster."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:4
msgid "Spatial Material"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:9
msgid ""
"For Godot 3, instead of following the trend and focusing on shader graphs, "
"we put in most of the work offering a default material that covers far more "
"use cases. This replaces the old \"FixedMaterial\" in Godot 2.x"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:13
msgid ""
"SpatialMaterial is a 3D material and aims to have most features artists look "
"for in a material. Additionally, it can be converted to shader code and be "
"further modified if desired."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:17
msgid ""
"This tutorial will attempt to cover most parameters present in "
"SpatialMaterial."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:22
msgid ""
"Spatial materials have many flags determining the general usage of a "
"material."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:27
msgid "Transparent"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:29
msgid ""
"In Godot, materials are not transparent unless specifically toggled as such. "
"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:33
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:37
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:40
msgid "Transparent flag (this one)"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:41
msgid "Blend mode set to other than Mix"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:42
msgid "Enabling distance or proximity fade"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:45
msgid "Unshaded"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:47
msgid ""
"In most cases, it is common for materials to be affected by lighting "
"(shaded)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:49
msgid ""
"Sometimes, however, one might want to show just the albedo (color) and "
"ignore the rest. Toggling this flag on will remove all shading and show "
"pure, unlit, color."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:55
msgid "Vertex Lighting"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:57
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:60
msgid ""
"As these calculations are costly, performance can be brought down "
"considerably in some corner cases such as drawing several layers of "
"transparency (common in particle systems). Switching to per vertex lighting "
"may help these cases."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:63
msgid ""
"Additionally, on low-end or mobile devices, switching to vertex lighting can "
"considerably increase rendering performance."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:68
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:71
msgid "No Depth Test"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:73
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:76
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 "
"bottom)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:82
msgid "Use Point Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:84
msgid ""
"This option is only active when the geometry rendered is made of points (it "
"generally is just made of triangles when imported from 3D DCCs). If so, then "
"points can be sized (see below)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:89
msgid "World Triplanar"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:91
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:95
msgid "Fixed Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:97
msgid ""
"Makes the object rendered at the same size no matter the distance. This is, "
"again, useful mostly for indicators (no depth test and high render priority) "
"and some types of billboards."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:101
msgid "Do Not Receive Shadows"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:103
msgid ""
"Makes the object not receive any kind of shadow that would otherwise be cast "
"onto it."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:106
msgid "Vertex Color"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:108
msgid ""
"This menu 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:114
msgid "Use as Albedo"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:116
msgid "Vertex color is used as albedo color."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:119
msgid "Is SRGB"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:121
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:126
#: ../../docs/tutorials/platform/services_for_ios.rst:86
#: ../../docs/tutorials/platform/services_for_ios.rst:126
#: ../../docs/tutorials/platform/services_for_ios.rst:176
#: ../../docs/tutorials/platform/services_for_ios.rst:220
#: ../../docs/tutorials/platform/services_for_ios.rst:365
msgid "Parameters"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:128
msgid ""
"SpatialMaterial also has several configurable parameters to tweak many "
"aspects of the rendering:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:133
msgid "Diffuse Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:135
msgid ""
"Specifies the algorithm used by diffuse scattering of light when hitting the "
"object. The default one is Burley. Other modes are also available:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:138
msgid ""
"**Burley:** Default mode, the original Disney Principled PBS diffuse "
"algorithm."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:139
msgid "**Lambert:** Is not affected by roughness."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:140
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:141
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:142
msgid ""
"**Toon:** Provides a hard cut for lighting, with smoothing affected by "
"roughness."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:147
msgid "Specular Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:149
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:151
msgid "**ShlickGGX:** The most common blob used by PBR 3D engines nowadays."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:152
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:153
msgid "**Phong:** Same as above."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:154
msgid ""
"**Toon:** Creates a toon blob, which changes size depending on roughness."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:155
msgid "**Disabled:** Sometimes, that blob gets in the way. Be gone!"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:161
msgid "Blend Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:163
msgid ""
"Controls the blend mode for the material. Keep in mind that any mode other "
"than Mix forces the object to go through transparent pipeline."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:165
msgid "Mix: Default blend mode, alpha controls how much the object is visible."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:166
msgid ""
"Add: Object is blended additively, nice for flares or some fire-like effects."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:167
msgid "Sub: Object is subtracted."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:168
msgid "Mul: Object is multiplied."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:173
msgid "Cull Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:175
msgid ""
"Determines which side of the object is not drawn when back-faces are "
"rendered:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:177
msgid "Back: Back of the object is culled when not visible (default)"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:178
msgid "Front: Front of the object is culled when not visible"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:179
msgid ""
"Disabled: Used for objects that are double sided (no culling is performed)"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:182
msgid "Depth Draw Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:184
msgid "Specifies when depth rendering must take place."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:186
msgid "Opaque Only (default): Depth is only drawn for opaque objects"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:187
msgid "Always: Depth draw is drawn for both opaque and transparent objects"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:188
msgid ""
"Never: No depth draw takes place (note: do not confuse with depth test "
"option above)"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:189
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:195
msgid "Line Width"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:197
msgid ""
"When drawing lines, specify the width of the lines being drawn. This option "
"is not available in most modern hardware."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:200
msgid "Point Size"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:202
msgid "When drawing points, specify the point size in pixels."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:205
msgid "Billboard Mode"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:207
msgid ""
"Enables billboard mode for drawing materials. This controls how the object "
"faces the camera:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:209
msgid "Disabled: Billboard mode is disabled"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:210
msgid ""
"Enabled: Billboard mode is enabled, object -Z axis will always face the "
"camera."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:211
msgid "Y-Billboard: Object X axis will always be aligned with the camera"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:212
msgid ""
"Particles: When using particle systems, this type of billboard is best, "
"because it allows specifying animation options."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:216
msgid "Above options are only enabled for Particle Billboard."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:219
msgid "Grow"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:221
msgid "Grows the object vertices in the direction pointed by their normals:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:225
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:232
msgid "Use Alpha Scissor"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:234
msgid ""
"When transparency other than 0 or 1 is not needed, it's possible to set a "
"threshold to avoid the object from rendering these pixels."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:238
msgid ""
"This renders the object via the opaque pipeline which is faster and allows "
"it to do mid and post process effects such as SSAO, SSR, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:241
msgid "Material colors, maps and channels"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:243
msgid ""
"Besides the parameters, what defines materials themselves are the colors, "
"textures and channels. Godot supports a extensive list of them. They will be "
"described in detail below:"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:247
msgid "Albedo"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:249
msgid ""
"Albedo is the base color for the material. Everything else works based on "
"it. When set to *unshaded* this is the only color that is visible as-is. In "
"previous versions of Godot, this channel was named *diffuse*. The change of "
"name mainly happened because, in PBR rendering, this color affects many more "
"calculations than just the diffuse lighting path."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:255
msgid "Albedo color and texture can be used together as they are multiplied."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:257
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:262
msgid "Metallic"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:264
msgid ""
"Godot uses a Metallic model over competing models due to its simplicity. "
"This parameter pretty much defines how reflective the materials is. The more "
"reflective it is, the least diffuse/ambient light and the more reflected "
"light. This model is called \"energy conserving\"."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:269
msgid ""
"The \"specular\" parameter here is just a general amount of for the "
"reflectivity (unlike *metallic*, this one is not energy conserving, so "
"simply leave it as 0.5 and don't touch it unless you need to)."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:273
msgid ""
"The minimum internal reflectivity is 0.04, so (just like in real life) it's "
"impossible to make a material completely unreflective."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:279
msgid "Roughness"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:281
msgid ""
"Roughness affects mainly the way reflection happens. A value of 0 makes it a "
"perfect mirror while a value of 1 completely blurs the reflection "
"(simulating the natural microsurfacing). Most common types of materials can "
"be achieved from the right combination of *Metallic* and *Roughness*."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:288
msgid "Emission"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:290
msgid ""
"Emission specifies how much light is emitted by the material (keep in mind "
"this does not do lighting on surrounding geometry unless GI Probe is used). "
"This value is just added to the resulting final image and is not affected by "
"other lighting in the scene."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:299
msgid "Normalmap"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:301
msgid ""
"Normal mapping allows to set a texture that represents finer shape detail. "
"This does not modify geometry, just the incident angle for light. In Godot, "
"only R and G are used for normalmaps, in order to attain better "
"compatibility."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:308
msgid "Rim"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:310
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:317
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:322
msgid "Clearcoat"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:324
msgid ""
"The *clearcoat* parameter is used mostly 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:329
msgid "Anisotropy"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:331
msgid ""
"Changes the shape of the specular blow and aligns it to tangent space. "
"Anisotropy is commonly used with hair, or to make materials such as brushed "
"aluminium more realistic. It works especially well when combined with "
"flowmaps."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:339
msgid "Ambient Occlusion"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:341
msgid ""
"In Godot's new PBR workflow, it is possible to specify a pre-baked ambient "
"occlusion map. This map affects how much ambient light reaches each surface "
"of the object (it does not affect direct light). While it is possible to use "
"Screen Space Ambient Occlusion (SSAO) to generate AO, nothing will beat the "
"quality of a nicely baked AO map. It is recommended to pre-bake AO whenever "
"possible."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:349
msgid "Depth"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:351
msgid ""
"Setting a depth map to 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 "
"objets, but it produces a realistic depth effect for textues. For best "
"results, *Depth* should be used together with normal mapping."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:359
msgid "Subsurface Scattering"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:361
msgid ""
"This effect emulates light that goes beneath an object's surface, is "
"scattered, and then comes out. It's useful to make realistic skin, marble, "
"colored liquids, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:368
msgid "Transmission"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:370
msgid ""
"Controls how much light from the lit side (visible to light) is transferred "
"to the dark side (opposite side to light). This works well for thin objects "
"such as tree/plant leaves, grass, human ears, etc."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:377
msgid "Refraction"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:379
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."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:386
msgid "Detail"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:388
msgid ""
"Godot allows using secondary albedo and normal maps to generate a detail "
"texture, which can be blended in many ways. Combining with secondary UV or "
"triplanar modes, many interesting textures can be achieved."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:395
msgid "UV1 and UV2"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:397
msgid ""
"Godot supports 2 UV channels per material. Secondary UV is often useful for "
"AO or Emission (baked light). UVs can be scaled and offseted which is useful "
"in textures with repeat."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:401
msgid "Triplanar Mapping"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:403
msgid ""
"Triplanar mapping is supported for both UV1 and UV2. This is an alternative "
"way to obtain texture coordinates, often called \"Autotexture\". Textures "
"are sampled in X,Y and Z and blended by the normal. Triplanar can be either "
"worldspace or object space."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:408
msgid ""
"In the image below, you can see how all primitives share the same material "
"with world triplanar, so bricks continue smoothly between them."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:414
msgid "Proximity and Distance Fade"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:416
msgid ""
"Godot allows materials to fade by proximity to each other as well as "
"depending on the distance to 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:420
msgid ""
"Keep in mind enabling these enables alpha blending, so abusing them for a "
"whole scene is not generally a good idea."
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:425
msgid "Render Priority"
msgstr ""

#: ../../docs/tutorials/3d/spatial_material.rst:427
msgid ""
"Rendering order can be changed for objects although this is mostly useful "
"for transparent objects (or opaque objects that do depth draw but no color "
"draw, useful for 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 ""
"Lights 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 ""
"As mentioned before, there are three types of light nodes: Directional, Omni "
"and Spot. Each has different uses and will be described in detail below, but "
"first let's take a look at the common parameters for lights:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:32
msgid "Each one has a specific function:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:34
msgid "**Color**: Base color for emitted light."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:35
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:36
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:37
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:38
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: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."
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 how 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 peformance 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. The closer the max distance, the higher quality they shadows will "
"have."
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 reduce 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 more costly."
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:180
msgid "Spot light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:182
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:189
msgid ""
"Spot lights share the same **Range** and **Attenuation** as **OmniLight**, "
"and add two extra parameters:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:191
msgid "**Angle**: The aperture angle of the light"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:192
msgid ""
"**Angle Attenuation**: The cone attenuation, which helps soften the cone "
"borders."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:196
msgid "Spot Shadow Mapping"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:198
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:202
msgid "Shadow Atlas"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:204
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:209
msgid ""
"The resolution applies to the whole Shadow Atlas. This atlas is divided in "
"four quadrants:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:213
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:217
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:222
msgid "Every frame, the following logic is done for all lights:"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:224
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:225
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:226
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:228
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:230
msgid ""
"This allocation strategy works for most games, but you may to use a separate "
"one in some cases (as example, a top-down game where all lights are around "
"the same size and quadrands may have all the same subdivision)."
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:234
msgid "Shadow Filter Quality"
msgstr ""

#: ../../docs/tutorials/3d/lights_and_shadows.rst:236
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:242
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 a 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"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:18
msgid ""
"behavior where they only capture on scene load. * 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
#: ../../docs/tutorials/3d/gi_probes.rst:32
#: ../../docs/tutorials/3d/baked_lightmaps.rst:41
msgid "Setting Up"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:25
msgid ""
"Create a ReflectionProbe node and wrap it around the area where you want to "
"have reflections:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:29
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:32
msgid ""
"By default, on interiors, reflections may appear to not have much "
"consistence. In this scenario, make sure to tick the *\"Box Correct\"* "
"property."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:38
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:43
msgid ""
"Adjusting the box walls may help improve the reflection a bit, but it will "
"always look the best in box shaped rooms."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:46
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:52
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:59
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:67
#: ../../docs/tutorials/3d/gi_probes.rst:85
msgid "Interior vs Exterior"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:69
msgid ""
"If you are using reflection probes in an interior setting, it is recommended "
"that the **Interior** property is enabled. This stops the probe from "
"rendering the sky and also allows custom ambient lighting settings."
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:75
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:78
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:84
msgid "Blending"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:86
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:90
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:96
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 fallback when "
"no screen-space information is found:"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:102
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:107
msgid "Reflection Atlas"
msgstr ""

#: ../../docs/tutorials/3d/reflection_probes.rst:109
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/gi_probes.rst:4
msgid "GI Probes"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:9
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:14
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:20
msgid ""
"Just like with ReflectionProbe, GIProbes 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:24
msgid "The main downside of GIProbes are:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:26
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:27
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:28
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:29
msgid ""
"They consume considerably more video memory than Reflection Probes, so they "
"must be used by care in the right subdivision sizes."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:34
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:39
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:44
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:50
msgid "Adding Lights"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:52
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:55
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:60
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:65
msgid ""
"And, as GIPRobe lighting updates in real-time, this effect is immediate:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:70
msgid "Reflections"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:72
msgid ""
"For materials with high metalness and 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:78
msgid ""
"GIProbes can easily be 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:87
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:92
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:97
msgid ""
"As complex buildings may mix interiors with exteriors, combining GIProbes "
"for both parts works well."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:102
msgid "Tweaking"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:104
msgid "GI Probes support a few parameters for tweaking:"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:108
msgid ""
"**Subdiv** Subdivision used for the probe. The default (128) is generally "
"good for small to medium size areas. Bigger subdivisions use more memory."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:109
msgid "**Extents** Size of the probe. Can be tweaked from the gizmo."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:110
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:111
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:112
msgid "**Propagation** How much light propagates through the probe internally."
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:113
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:114
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:118
msgid "Quality"
msgstr ""

#: ../../docs/tutorials/3d/gi_probes.rst:120
msgid ""
"GIProbes are quite demanding. It is possible to use lower quality voxel cone "
"tracing in exchange of 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 in run-time."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:14
msgid ""
"Unlike GIProbes, 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 less problems regarding to light bleeding than "
"GIProbe, 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 low-end compatibility or mobile, 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 "
"more smooth overall."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:43
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:48
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:51
msgid "Unwrap from your 3D DCC"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:53
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:59
msgid "Simply do an unwrap on the second UV2 layer."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:63
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:68
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 quick. You will mostly need to use seams or other techniques to create "
"better unwrapping."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:74
msgid "Unwrap from within Godot"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:76
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:81
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:85
msgid "Unwrap on Scene import"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:87
msgid ""
"This is probably the best approach overall. The only downside is that, on "
"large models, unwrap 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:94
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:98
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:101
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:108
msgid "Checking UV2"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:110
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:116
msgid "Setting up the Scene"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:118
msgid ""
"Before anything is done, a **BakedLight** 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:124
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:130
msgid "Configure Bounds"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:132
msgid ""
"Lightmap needs an approximate volume of the area affected because it uses it "
"to transfer light to dynamic objects inside (more on that later). Just cover "
"the scene with the volume as you do with GIProbe:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:139
msgid "Setting Up Meshes"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:141
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:146
msgid ""
"When auto-generating lightmaps on scene import, this is enabled "
"automatically."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:149
msgid "Setting up Lights"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:151
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:155
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:160
msgid "The modes are :"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:162
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:163
msgid ""
"**Indirect:** This is the default mode. Only indirect lighting will be baked."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:164
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:167
msgid "Baking Quality"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:169
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:173
msgid ""
"In general, the defaults are good enough. There is also a **Capture "
"Subdivision** (that must always be equal or less to the main subdivision), "
"which is used for capturing light in dynamic objects (more on that later). "
"It's default value is also good enough for more cases."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:180
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:185
msgid ""
"**Voxel Cone**: Trace: Is the default one, it's less precise but faster. "
"Looks similar (but slightly better) to GIProbe."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:186
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:190
msgid "Baking"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:192
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:197
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:201
msgid "Configuring Bake"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:203
msgid "Several more options are present for baking:"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:205
msgid ""
"**Bake Subdiv**: 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:206
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:207
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:208
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:209
msgid ""
"**Propagation**: Used for the *Voxel Cone Trace* mode. Works just like in "
"GIProbe."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:210
msgid ""
"**HDR**: If disabled, lightmaps are smaller but can't capture any light over "
"white (1.0)."
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:211
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:212
msgid "**Extents**: Size of the area affected (can be edited visually)"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:213
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:217
msgid "Dynamic Objects"
msgstr ""

#: ../../docs/tutorials/3d/baked_lightmaps.rst:219
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:224
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 brand 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:29
msgid "WorldEnvironment Node"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:31
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:36
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 "Default Environment"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:44
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:50
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:55
msgid "Environment Options"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:57
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:64
msgid ""
"The Background section contains settings on how to fill the background "
"(parts of the screen where objects where 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:71
msgid "There are many ways to set the background:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:73
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:74
msgid "**Custom Color** is like Clear Color but with a custom color value."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:75
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:76
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:80
msgid "Ambient Light"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:82
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:86
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:94
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 sky affects objects)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:98
msgid "Here is a comparison of how different ambient light affects a scene:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:102
msgid ""
"Finally there is a **Energy** setting, which is a multiplier, useful when "
"working with HDR."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:104
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 quality between using a "
"flat ambient color and a GIProbe:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:113
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:117
msgid "Fog"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:119
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:123
msgid ""
"**Depth Fog:** This one is applied based on the distance from the camera."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:124
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:128
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:130
msgid "Two properties can be tweaked to make the fog effect more interesting:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:132
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:136
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:142
msgid "Tonemap"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:144
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:149
msgid ""
"**Mode:** Tone mapping mode, which can be Linear, Reindhart, Filmic, or Aces."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:150
msgid ""
"**Exposure:** Tone mapping exposure which simulates amount of light received "
"over time."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:151
msgid ""
"**White:** Tone mapping white which simulates where in the scale is white "
"located (by default 1.0)."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:154
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 suports 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 the with "
"the directional light. Normally, values between 3.0 and 6.0 are enough to "
"simulate indoor-oudoor 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 then:"
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 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:196
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:203
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 is "
"great to make characters, cars, etc. reflect when moving around."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:207
msgid ""
"A few user-controlled parameters are available to better tweak the technique:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:209
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:210
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:211
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:212
msgid ""
"**Depth Tolerance** can be used for scren-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:213
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:215
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:218
msgid "Screen-Space Ambient Occlusion (SSAO)"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:220
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 before act more on a larger scale (large regions) than at "
"the smaller geometry level."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:227
msgid ""
"Constant ambient color and Sky are uniform and 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:231
msgid ""
"This can be simulated with Screen Space Ambient Occlusion. As you can see in "
"the image below, the goal of it 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:237
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:240
msgid ""
"This is why, in the image above, the effect is less noticeable under the "
"direct light (at 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:244
msgid ""
"SSAO looks best when combined with a real source of indirect light, like "
"GIProbe:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:248
msgid "Tweaking SSAO is possible with several parameters:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:252
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:253
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:254
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:255
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:256
msgid ""
"**Quality:** Depending on quality, SSAO will do more samplings over a sphere "
"for every pixel. High quality only works well on modern GPUs."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:257
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 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:258
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:261
msgid "Depth of Field / Far Blur"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:263
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:269
#: ../../docs/tutorials/3d/environment_and_post_processing.rst:282
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:274
msgid "Depth of Field / Near Blur"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:276
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:285
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:292
msgid "Glow"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:294
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:300
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:303
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:307
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:311
msgid "Both will cause the light to start bleeding out of the brighter areas."
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:313
msgid "Once glow is visible, it can be controlled with a few extra parameters:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:315
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:316
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:318
msgid "The **Blend Mode** of the effect can also be changed:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:320
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:321
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:322
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:323
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:325
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:331
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:336
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:343
msgid "Adjustments"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:345
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:350
msgid ""
"The first one is being able to change the typical Brightness, Contrast, and "
"Saturation:"
msgstr ""

#: ../../docs/tutorials/3d/environment_and_post_processing.rst:355
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:360
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 "High dynamic range"
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 where does all this HDR stuff thing come from? The idea is that instead "
"of dealing with colors that go from black to white (0 to 1), we use colors "
"whiter than white (for example, 0 to 8 times white)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:18
msgid ""
"To be more practical, imagine that in a regular scene, the intensity of a "
"light (generally 1.0) is set to 5.0. The whole scene will turn very bright "
"(towards white) and look horrible."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:22
msgid ""
"After this the luminance of the scene is computed by averaging the luminance "
"of every pixel of it, and this value is used to bring the scene back to "
"normal ranges. This last operation is called tone-mapping. Finally, we are "
"at a similar place from where we started:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:30
msgid ""
"Except the scene is more contrasted because there is a higher light range at "
"play. What is this all useful for? The idea is that the scene luminance will "
"change while you move through the world, allowing situations like this to "
"happen:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:37
msgid ""
"Additionally, it is possible to set a threshold value to send to the glow "
"buffer depending on the pixel luminance. This allows for more realistic "
"light bleeding effects in the scene."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:42
msgid "Linear color space"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:44
msgid ""
"The problem with this technique is that computer monitors apply a gamma "
"curve to adapt better to the way the human eye sees. Artists create their "
"art on the screen too, so their art has an implicit gamma curve applied to "
"it."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:49
msgid ""
"The color space where images created in computer monitors exist is called "
"\"sRGB\". All visual content that people have on their computers or download "
"from the internet (such as pictures, movies, etc.) is in this colorspace."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:56
msgid ""
"The mathematics of HDR require that we multiply the scene by different "
"values to adjust the luminance and exposure to different light ranges, and "
"this curve gets in the way as we need colors in linear space for this."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:62
msgid "Linear color space & asset pipeline"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:64
msgid ""
"Working in HDR is not just pressing a switch. First, imported image assets "
"must be converted to linear space on import. There are two ways to do this:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:69
msgid "SRGB -> linear conversion on image import"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:71
msgid ""
"This is the most compatible way of using linear-space assets, and it will "
"work everywhere including all mobile devices. The main issue with this is "
"loss of quality, as sRGB exists to avoid this same problem. Using 8 bits per "
"channel to represent linear colors is inefficient from the point of view of "
"the human eye. These textures might be later compressed too which makes the "
"problem worse."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:78
msgid "In any case though, this is the easy solution that works everywhere."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:81
msgid "Hardware sRGB -> linear conversion."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:83
msgid ""
"This is the most correct way to use assets in linear-space, as the texture "
"sampler on the GPU will do the conversion after reading the texel using "
"floating point. This works fine on PC and consoles, but most mobile devices "
"do no support it, or do not support it on compressed texture format (iOS for "
"example)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:90
msgid "Linear -> sRGB at the end."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:92
msgid ""
"After all the rendering is done, the linear-space rendered image must be "
"converted back to sRGB. To do this, simply enable sRGB conversion in the "
"current :ref:`Environment <class_Environment>` (more on that below)."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:96
msgid ""
"Keep in mind that sRGB -> Linear and 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:102
msgid "Parameters of HDR"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:104
msgid ""
"HDR is found in the :ref:`Environment <class_Environment>` resource. These "
"are found most of the time inside a :ref:`WorldEnvironment "
"<class_WorldEnvironment>` node or set in a camera. There are many parameters "
"for HDR:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:112
msgid "ToneMapper"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:114
msgid ""
"The ToneMapper is the heart of the algorithm. Many options for tonemappers "
"are provided:"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:117
msgid ""
"**Linear:** Simplest tonemapper. It does its job for adjusting scene "
"brightness, but if the differences in light are too big, it will cause "
"colors to be too saturated."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:120
msgid "**Log:** Similar to linear but not as extreme."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:121
msgid ""
"**Reinhardt:** Classical tonemapper (modified so it will not desaturate as "
"much)"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:123
msgid ""
"**ReinhardtAutoWhite:** Same as above but uses the max scene luminance to "
"adjust the white value."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:127
msgid "Exposure"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:129
msgid ""
"The same exposure parameter as in real cameras. Controls how much light "
"enters the camera. Higher values will result in a brighter scene, and lower "
"values will result in a darker scene."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:134
msgid "White"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:136
msgid "Maximum value of white."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:139
msgid "Glow threshold"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:141
msgid ""
"Determine above which value (from 0 to 1 after the scene is tonemapped), "
"light will start bleeding."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:145
msgid "Glow scale"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:147
msgid "Determine how much light will bleed."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:150
msgid "Min luminance"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:152
msgid ""
"Lower bound value of light for the scene at which the tonemapper stops "
"working. This allows dark scenes to remain dark."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:156
msgid "Max luminance"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:158
msgid ""
"Upper bound value of light for the scene at which the tonemapper stops "
"working. This allows bright scenes to remain saturated."
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:162
msgid "Exposure adjustment speed"
msgstr ""

#: ../../docs/tutorials/3d/high_dynamic_range.rst:164
msgid ""
"Auto-exposure will change slowly and will take a while to adjust (like in "
"real cameras). Bigger values means faster adjustment."
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:60
msgid "Exporting the MeshLibrary"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:62
msgid ""
"To export the library, click on Scene -> Convert To.. -> MeshLibrary.., and "
"save it as a resource."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:67
msgid ""
"You can find an already exported MeshLibrary in the project named "
"\"MeshLibrary.tscn\"."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:70
msgid "Using GridMap"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:72
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:78
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:81
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, use "
"Shift+Right-click."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:85
msgid ""
"Click on the \"GridMap\" menu to see options and shortcuts. For example, "
"pressing \"S\" rotates a tile around the y-axis."
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:90
msgid ""
"Holding <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:96
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:102
msgid "Using gridmap in code"
msgstr ""

#: ../../docs/tutorials/3d/using_gridmaps.rst:104
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 "
"favourable 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 ""
"Another node is used as the source, the mesh that you want to have "
"duplicated. In the tree case, this would be the tree."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:34
msgid ""
"In our example, we would use a :ref:`Node <class_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 simplification purposes, 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:57
msgid ""
"The mesh you would be using as the target surface for placing copies of you "
"source mesh on."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:61
msgid "Source Mesh"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:62
msgid "The mesh you want duplicated on the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:65
msgid "Mesh Up Axis"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:66
msgid "The axis used as the up axis of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:69
msgid "Random Rotation"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:70
msgid "Randomizing the rotation around the mesh up axis of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:73
msgid "Random Tilt"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:74
msgid "Randomizing the overall rotation of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:77
msgid "Random Scale"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:78
msgid "Randomizing the scale of the source mesh."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:82
msgid ""
"The scale of the source mesh that will be placed over the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:85
msgid "Amount"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:86
msgid "The amount of mesh instances placed over the target surface."
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:88
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:94
msgid "The end result should look like this:"
msgstr ""

#: ../../docs/tutorials/3d/using_multi_mesh_instance.rst:98
msgid "To change the result, repeat the same step with different parameters."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:4
msgid "Working with 3D skeletons"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:6
msgid ""
"Godot 3D skeleton support is currently quite rudimentary. The :ref:"
"`class_Skeleton` node and class were designed mainly to support importing "
"skeletal animations as a set of transformation matrices."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:11
msgid "Skeleton node"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:13
msgid ""
"The Skeleton node can be directly added anywhere you want on a scene. "
"Usually the target mesh is a child of Skeleton, as it easier to manipulate "
"this way, since Transforms within a skeleton are relative to where the "
"Skeleton is. But you can specify a Skeleton node in every MeshInstance."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:18
msgid ""
"Naturally, Skeleton is intended to deform meshes and consists of structures "
"called \"bones\". Each \"bone\" is represented as a Transform, which is "
"applied to a group of vertices within a mesh. You can directly control a "
"group of vertices from Godot. For that please reference the :ref:"
"`class_MeshDataTool` class and its method :ref:`set_vertex_bones "
"<class_MeshDataTool_set_vertex_bones>`."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:24
msgid ""
"The \"bones\" are organized hierarchically. Every bone, except for root "
"bone(s) have a parent. Every bone also has an associated name you can use to "
"refer to it (e.g. \"root\" or \"hand.L\", etc.). All bones are numbered, and "
"these numbers are bone IDs. Bone parents are referred by their numbered IDs."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:30
msgid "For the rest of the article we consider the following scene:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:38
msgid ""
"This scene is imported from Blender. It contains an arm mesh with 2 bones, "
"upperarm and lowerarm, with the lowerarm bone parented to the upperarm."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:42
msgid "Skeleton class"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:44
msgid ""
"You can view Godots internal help for descriptions of all functions. "
"Basically, all operations on bones are done using their numeric ID. You can "
"convert from a name to a numeric ID and vice versa."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:48
msgid ""
"**To find the number of bones in a skeleton we use the get_bone_count() "
"function:**"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:61
msgid "**To find the ID of a bone, use the find_bone() function:**"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:73
msgid ""
"Now, we want to do something interesting with the ID, not just printing it. "
"Also, we might need additional information, finding bone parents to complete "
"chains, etc. This is done with the get/set_bone\\_\\* functions."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:77
msgid ""
"**To find the parent of a bone we use the get_bone_parent(id) function:**"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:91
msgid ""
"The bone transforms are the things of our interest here. There are 3 kind of "
"transforms: local, global, custom."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:94
msgid ""
"**To find the local Transform of a bone we use get_bone_pose(id) function:**"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:110
msgid ""
"So we get a 3x4 matrix there, with the first column filled with 1s. What can "
"we do with this matrix? It is a Transform, so we can do everything we can do "
"with Transforms (basically translate, rotate and scale). We could also "
"multiply transforms to have more complex transforms. Remember, \"bones\" in "
"Godot are just Transforms over a group of vertices. We could also copy "
"Transforms of other objects there. So let's rotate our \"upperarm\" bone:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:138
msgid ""
"Now we can rotate individual bones. The same happens for scale and "
"translate. Try these on your own and check the results."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:141
msgid ""
"What we used here was the local pose. By default all bones are not modified. "
"But this Transform tells us nothing about the relationship between bones. "
"This information is needed for quite a number of tasks. How can we get it? "
"Here the global transform comes into play:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:146
msgid ""
"**To find the bone global Transform we use get_bone_global_pose(id) function:"
"**"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:149
msgid "Let's find the global Transform for the lowerarm bone:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:165
msgid ""
"As you can see, this transform is not zeroed. While being called global, it "
"is actually relative to the Skeleton origin. For a root bone, the origin is "
"always at 0 if not modified. Let's print the origin for our lowerarm bone:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:183
msgid ""
"You will see a number. What does this number mean? It is a rotation point of "
"the Transform. So it is base part of the bone. In Blender you can go to Pose "
"mode and try there to rotate bones. They will rotate around their origin."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:188
msgid ""
"But what about the bone tip? We can't know things like the bone length, "
"which we need for many things, without knowing the tip location. For all "
"bones in a chain, except for the last one, we can calculate the tip "
"location. It is simply a child bone's origin. There are situations when this "
"is not true, such as for non-connected bones, but that is OK for us for now, "
"as it is not important regarding Transforms."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:195
msgid ""
"Notice that the leaf bone tip is nowhere to be found. A leaf bone is a bone "
"without children, so you don't have any information about its tip. But this "
"is not a showstopper. You can overcome this by either adding an extra bone "
"to the chain or just calculating the length of the leaf bone in Blender and "
"storing the value in your script."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:202
msgid "Using 3D \"bones\" for mesh control"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:204
msgid ""
"Now as you know the basics we can apply these to make full FK-control of our "
"arm (FK is forward-kinematics)."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:207
msgid "To fully control our arm we need the following parameters:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:209
msgid "Upperarm angle x, y, z"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:210
msgid "Lowerarm angle x, y, z"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:212
msgid "All of these parameters can be set, incremented, and decremented."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:214
msgid "Create the following node tree:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:223
msgid ""
"Set up the Camera so that the arm is properly visible. Rotate DirectionLight "
"so that the arm is properly lit while in scene play mode."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:226
msgid "Now we need to create a new script under main:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:228
msgid "First we define the setup parameters:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:235
msgid "Now we need to setup a way to change them. Let us use keys for that."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:237
msgid "Please create 7 actions under project settings -> Input Map:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:239
msgid "**selext_x** - bind to X key"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:240
msgid "**selext_y** - bind to Y key"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:241
msgid "**selext_z** - bind to Z key"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:242
msgid "**select_upperarm** - bind to key 1"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:243
msgid "**select_lowerarm** - bind to key 2"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:244
msgid "**increment** - bind to key numpad +"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:245
msgid "**decrement** - bind to key numpad -"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:247
msgid ""
"So now we want to adjust the above parameters. Therefore we create code "
"which does that:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:275
msgid "The full code for arm control is this:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:327
msgid ""
"Pressing keys 1/2 selects upperarm/lowerarm, select the axis by pressing x, "
"y, z, rotate using numpad \"+\"/\"-\""
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:330
msgid ""
"This way you fully control your arm in FK mode using 2 bones. You can add "
"additional bones and/or improve the \"feel\" of the interface by using "
"coefficients for the change. I recommend you play with this example a lot "
"before going to next part."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:335
msgid "You can clone the demo code for this chapter using"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:342
msgid "Or you can browse it using the web-interface:"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:344
msgid "https://github.com/slapin/godot-skel3d"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:347
msgid "Using 3D \"bones\" to implement Inverse Kinematics"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:349
msgid "See :ref:`doc_inverse_kinematics`."
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:352
msgid "Using 3D \"bones\" to implement ragdoll-like physics"
msgstr ""

#: ../../docs/tutorials/3d/working_with_3d_skeletons.rst:354
msgid "TODO."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:4
msgid "Inverse kinematics"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:6
msgid "This tutorial is a follow-up of :ref:`doc_working_with_3d_skeletons`."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:8
msgid ""
"Previously, we were able to control the rotations of bones in order to "
"manipulate where our arm was (forward kinematics). But what if we wanted to "
"solve this problem in reverse? Inverse kinematics (IK) tells us *how* to "
"rotate our bones in order to reach a desired position."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:13
msgid ""
"A simple example of IK is the human arm: While we intuitively know the "
"target position of an object we want to reach for, our brains need to figure "
"out how much to move each joint in our arm to get to that target."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:18
msgid "Initial problem"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:20
msgid ""
"Talking in Godot terminology, the task we want to solve here is to position "
"the 2 angles on the joints of our upperarm and lowerarm so that the tip of "
"the lowerarm bone is as close to the target point (which is set by the "
"target Vector3) as possible using only rotations. This task is calculation-"
"intensive and never resolved by analytical equation solving, as it is an "
"under-constrained problem which means that there is more than one solution "
"to an IK problem."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:30
msgid ""
"For easy calculation in this chapter, we consider the target being a child "
"of Skeleton. If this is not the case for your setup you can always reparent "
"it in your script, as you will save on calculations if you do so."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:35
msgid ""
"In the picture, you see the angles alpha and beta. In this case, we don't "
"use poles and constraints, so we need to add our own. On the picture the "
"angles are 2D angles living in a plane which is defined by bone base, bone "
"tip, and target."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:40
msgid ""
"The rotation axis is easily calculated using the cross-product of the bone "
"vector and the target vector. The rotation in this case will be always in "
"positive direction. If ``t`` is the Transform which we get from the "
"get_bone_global_pose() function, the bone vector is"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:49
msgid "So we have all the information we need to execute our algorithm."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:51
msgid ""
"In game dev it is common to resolve this problem by iteratively closing to "
"the desired location, adding/subtracting small numbers to the angles until "
"the distance change achieved is less than some small error value. Sounds "
"easy enough, but there are still Godot problems we need to resolve to "
"achieve our goal."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:57
msgid "**How to find coordinates of the tip of the bone?**"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:58
msgid "**How to find the vector from the bone base to the target?**"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:60
msgid ""
"For our goal (tip of the bone moved within area of target), we need to know "
"where the tip of our IK bone is. As we don't use a leaf bone as IK bone, we "
"know the coordinate of the bone base is the tip of the parent bone. All "
"these calculations are quite dependent on the skeleton's structure. You "
"could use pre-calculated constants, or you could add an extra bone at the "
"tip of the IK bone and calculate using that."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:70
msgid "We will use an exported variable for the bone length to make it easy."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:78
msgid ""
"Now, we need to apply our transformations from the IK bone to the base of "
"the chain, so we apply a rotation to the IK bone, then move from our IK bone "
"up to its parent, apply rotation again, then move to the parent of the "
"current bone again, etc. So we need to limit our chain somewhat."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:87
msgid "For the ``_ready()`` function:"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:96
msgid "Now we can write our chain-passing function:"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:110
msgid "And for the ``_process()`` function:"
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:117
msgid ""
"Executing this script will pass through the bone chain, printing bone "
"transforms."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:147
msgid ""
"Now we need to actually work with the target. The target should be placed "
"somewhere accessible. Since \"arm\" is an imported scene, we better place "
"the target node within our top level scene. But for us to work with target "
"easily its Transform should be on the same level as the Skeleton."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:152
msgid ""
"To cope with this problem, we create a \"target\" node under our scene root "
"node and at runtime we will reparent it, copying the global transform which "
"will achieve the desired effect."
msgstr ""

#: ../../docs/tutorials/3d/inverse_kinematics.rst:156
msgid ""
"Create a new Spatial node under the root node and rename it to \"target\". "
"Then modify the ``_ready()`` function to look like this:"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:4
msgid "Mesh generation with heightmap and shaders"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:9
msgid ""
"This tutorial will help you to use Godot shaders to deform a plane mesh so "
"that it appears like a basic terrain. Remember that this solution has pros "
"and cons."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:13
msgid "Pros:"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:15
msgid "Pretty easy to do."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:16
msgid "This approach allows computation of LOD terrains."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:17
msgid "The heightmap can be used in Godot to create a normal map."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:19
msgid "Cons:"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:21
msgid ""
"The Vertex Shader can't re-compute normals of the faces. Thus, if your mesh "
"is not static, this method will **not** work with shaded materials."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:24
msgid ""
"This tutorial uses a plane mesh imported from Blender to Godot Engine. Godot "
"is able to create meshes as well."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:27
msgid ""
"See this tutorial as an introduction, not a method that you should employ in "
"your games, except if you intend to do LOD. Otherwise, this is probably not "
"the best way."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:31
msgid ""
"However, let's first create a heightmap, or a 2D representation of the "
"terrain. To do this, I'll use GIMP, but you can use any image editor you "
"like."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:35
msgid "The heightmap"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:37
msgid ""
"We will use a few functions of GIMP image editor to produce a simple "
"heightmap. Start GIMP and create a square image of 512x512 pixels."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:42
msgid "You are now in front of a new, blank, square image."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:46
msgid "Then, use a filter to render some clouds on this new image."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:50
msgid ""
"Parameter this filter to whatever you want. A white pixel corresponds to the "
"highest point of the heightmap, a black pixel corresponds to the lowest one. "
"So, darker regions are valleys and brighter are mountains. If you want, you "
"can check \"tileable\" to render a heightmap that can be cloned and tiled "
"close together with another one. X and Y size don't matter a lot as long as "
"they are big enough to provide a decent ground. A value of 4.0 or 5.0 for "
"both is nice. Click on the \"New Seed\" button to roll a dice and GIMP will "
"create a new random heightmap. Once you are happy with the result, click \"OK"
"\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:62
msgid ""
"You can continue to edit your image if you wish. For our example, let's keep "
"the heightmap as is, and let's export it to a PNG file, say \"heightmap.png"
"\". Save it in your Godot project folder."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:67
msgid "The plane mesh"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:69
msgid "Now, we will need a plane mesh to import in Godot. Let's run Blender."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:73
msgid "Remove the start cube mesh, then add a new plane to the scene."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:77
msgid ""
"Zoom a bit, then switch to Edit mode (Tab key) and in the Tools buttongroup "
"at the left, hit \"Subdivide\" 5 or 6 times."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:82
msgid ""
"Your mesh is now subdivided, which means we added vertices to the plane mesh "
"that we will later be able to move. Job's not finished yet: in order to "
"texture this mesh a proper UV map is necessary. Currently, the default UV "
"map contains only the 4 corner vertices we had at the beginning. However, we "
"now have more, and we want to be able to texture over the whole mesh "
"correctly."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:89
msgid ""
"If all the vertices of your mesh are not selected, select them all (hit \"A"
"\"). They must appear orange, not black. Then, in the Shading/UVs button "
"group to the left, click the \"Unwrap\" button (or simply hit \"U\") and "
"select \"Smart UV Project\". Keep the default options and hit \"Ok\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:97
msgid "Now, we need to switch our view to \"UV/Image editor\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:101
msgid ""
"Select all the vertices again (\"A\") then in the UV menu, select \"Export "
"UV Layout\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:106
msgid ""
"Export the layout as a PNG file. Name it \"plane.png\" and save it in your "
"Godot project folder. Now, let's export our mesh as an OBJ file. Top of the "
"screen, click \"File/Export/Wavefront (obj)\". Save your object as \"plane."
"obj\" in your Godot project folder."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:112
msgid "Shader magic"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:114
msgid "Let's now open Godot Editor."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:116
msgid ""
"Create a new project in the folder you previously created and name it what "
"you want."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:121
msgid "In our default scene (3D), create a root node \"Spatial\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:123
msgid ""
"Create a MeshInstance node as a child of the node we just created. Then, "
"load the Mesh selecting \"Load\" and then our \"plane.obj\" file."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:128
msgid "Great! Our plane is now rendered in the 3D view."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:132
msgid ""
"It is time to add some shader stuff. In the Inspector, in the \"Material\" "
"line, add a \"New ShaderMaterial\". Edit it by clicking it and then "
"selecting the \"Edit\" option."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:138
msgid ""
"We need now to create the actual shader. On the Inspector, select the "
"\"Shader\" line and click on \"New Shader\"."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:143
msgid ""
"Edit it by clicking the \"Edit\" option just like we did before. The Shader "
"editor opens."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:148
msgid ""
"Let's start writing our shader. If you don't know how to use shaders in "
"Godot you can check the :ref:`doc_shading_language` page."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:151
msgid ""
"Let's start with the Fragment part. This one is used to texture the plane "
"using an image. For this example, we will texture it with the heightmap "
"image itself, so we'll actually see mountains as brighter regions and "
"canyons as darker regions. Use this code:"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:168
msgid ""
"First, we set the shader type as ``spatial`` (for 3D). The ``render_mode "
"unshaded`` line makes our MeshInstance be unaffected by the lighting in our "
"world. It doesn't matter since it is a greyscale image. We take a parameter "
"(``uniform``) as a ``sampler2D``, which will be the texture of our heightmap."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:174
msgid ""
"Then, we set the color of every pixel of the image given by "
"``texture(source, UV).rgb`` setting it to the ALBEDO variable. Remember that "
"the ``UV`` variable is a shader variable that returns the 2D position of the "
"pixel in the texture image, according to the vertex we are currently dealing "
"with. That is the use of the UV Layout we made before."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:181
msgid ""
"However, the plane is displayed white! This is because we didn't set the "
"texture file and the color to use."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:186
msgid ""
"In the Inspector, click the back arrow to get back to the ShaderMaterial. "
"This is where you want to set the texture and the color. Click the \"Shader "
"Param\" line, in \"Source\", click \"Load\" and select the texture file "
"\"heightmap.png\". Now you will see our heightmap."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:194
msgid "Good. Now, the Vertex part."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:196
msgid ""
"The Vertex Shader is the first shader to be executed by the pipeline. It "
"deals with vertices."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:199
msgid ""
"Insert a new \"uniform\" variable right after the one that we introduced "
"before:"
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:206
msgid ""
"The ``height_range`` parameter is a parameter that we will use to increase "
"the height effect."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:209
msgid ""
"Then, insert the following function before the fragment function we wrote "
"before."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:220
msgid ""
"First, we save the x and z position of the VERTEX, because we do not want "
"them to change: the plane must remain square. Remember that Y axis "
"corresponds to the \"altitude\", which is the only one we want to change "
"with the heightmap."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:225
msgid ""
"Then, we compute an ``h`` variable by multiplying the pixel value at the UV "
"position and the ``height_range``. As the heightmap is a greyscale image, "
"all r, g and b channels contain the same value. We use ``g``, but any of r, "
"g and b have the same effect."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:230
msgid ""
"After that, we set the current vertex' position at (xz.x, h, xz.y) position. "
"Concerning xz.y remember that its type is \"vec2\". Thus, its components are "
"x and y."
msgstr ""

#: ../../docs/tutorials/3d/mesh_generation_with_heightmap_and_shaders.rst:234
msgid ""
"That's all good, but our plane remains flat. This is because the "
"``height_range`` value is 0. Increase this value to observe the mesh distort "
"and take to form of the terrain we set before:"
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 know have experience working with the Godot "
"editor, have basic programming experience in GDScript, and have 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:1010
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:1015
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, look around with a mouse based first "
"person camera, that can jump into the air, turn on and off a flash light, "
"and sprint."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:78
msgid "Getting everything ready"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:79
msgid "Launch Godot and open up the project included in the starter assets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:81
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:85
msgid ""
"First, go 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:91
msgid "Let's take a second to see what we have in the starter assets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:93
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:96
msgid "For now let's open up ``Player.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:98
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 of the models "
"used for each of the levels, as well as some textures and materials."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:103
msgid "Making the FPS movement logic"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:105
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:109
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:112
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:115
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:118
msgid ""
"Many times player will notice how 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:122
msgid ""
"Another thing to notice is how many nodes are children of "
"``Rotation_Helper``. This is because ``Rotation_Helper`` contains all of 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:127
msgid ""
"If we did not use ``Rotation_helper`` then we'd likely have cases where we "
"are rotating both the ``X`` and ``Y`` axes at the same time. This can lead "
"to undesirable results, as we then could rotate on all three axes in some "
"cases."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:131
msgid "See :ref:`using transforms <doc_using_transforms>` for more information"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:135
msgid "Attach a new script to the ``Player`` node and call it ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:137
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:242
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:244
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:247
msgid ""
"If you do this, all of the code copied will be using spaces instead of tabs."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:249
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 of the spaces "
"into tabs. You can select \"Convert Indent To Spaces\" to convert t back "
"into spaces."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:254
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:256
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:260
msgid "Let's go through each of the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:262
msgid "``GRAV``: How strong gravity pulls us down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:263
msgid "``vel``: Our :ref:`KinematicBody <class_KinematicBody>`'s velocity."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:264
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:265
msgid "``JUMP_SPEED``: How high we can jump."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:266
msgid ""
"``ACCEL``: How fast we accelerate. The higher the value, the faster we get "
"to max speed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:267
msgid ""
"``DEACCEL``: How fast we are going to decelerate. The higher the value, the "
"faster we will come to a complete stop."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:268
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:269
msgid "``camera``: The :ref:`Camera <class_Camera>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:270
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:271
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:273
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:277
msgid ""
"You may have noticed that ``MOUSE_SENSITIVITY`` is written in all caps like "
"the other constants, but is ``MOUSE_SENSITIVITY`` is not a constant."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:279
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:284
msgid "Now let's look at the ``_ready`` function:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:286
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:288
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:290
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 to the player to see "
"their mouse cursor as they play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:293
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 happen, we capture the mouse cursor."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:297
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:302
msgid "Next let's take a look at ``_physics_process``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:304
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:306
msgid ""
"``process_input`` will be where we store all of 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:309
msgid ""
"``process_movement`` is where we'll send all of the date necessary to the :"
"ref:`KinematicBody <class_KinematicBody>` so it can move through the game "
"world."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:314
msgid "Let's look is ``process_movement`` next:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:316
msgid "First we set ``dir`` to an empty :ref:`Vector3 <class_Vector3>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:318
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:321
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:323
msgid ""
"The reason we need the camera's global transform is so we can use it's "
"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:328
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:331
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:334
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:336
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:339
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:352
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:355
msgid "Here is what world space looks like in 2D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:357
msgid ""
"The following images are just examples. Each arrow/rectangle represents a "
"directional vector"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:361
#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:404
msgid "And here is what it looks like for 3D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:365
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:369
msgid ""
"Local space is different, because it takes the rotation of the object into "
"account."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:371
msgid ""
"Local space can be defined as follows: The space in which a 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:376
msgid ""
"This stack overflow question has a much better explanation of world space "
"and local space."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:378
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:381
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:384
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:387
msgid ""
"To use the a :ref:`Spatial <class_Spatial>` node's local directional "
"vectors, we use this code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:400
msgid "Here is what local space looks like in 2D:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:408
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:412
msgid ""
"You can change between local and world space modes by pressing the little "
"cube button when you have a :ref:`Spatial <class_Spatial>` based node "
"selected."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:417
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:423
msgid "Okay, back to ``process_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:425
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 so map the player's input to movement."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:428
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:430
msgid ""
"Based on which directional movement action is pressed, we add or remove from "
"``input_movement_vector``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:432
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:435
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:438
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:443
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:446
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:450
msgid ""
"Because we're setting the Y velocity, the player will jump into the air."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:452
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:456
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:458
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:462
msgid "Now let's look at ``process_movement``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:464
msgid ""
"First we assure that ``dir`` does not have any movement on the ``Y`` axis by "
"setting it's ``Y`` value to zero."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:466
msgid ""
"Next we normalize ``dir`` to assure 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 moving 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:469
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:471
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:473
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:476
msgid "After that we make a new variable for acceleration, named ``accel``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:478
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:482
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:485
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:488
msgid ""
"All of 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:492
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:494
msgid ""
"First we make sure that the event we are dealing with is a :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:497
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:500
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:503
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:506
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:508
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:512
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:516
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:519
msgid ""
"see :ref:`using transforms <doc_using_transforms>` for more information on "
"rotating transforms."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:523
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:526
msgid ""
"Go ahead and test your code either by pressing ``F4`` with ``Testing_Area."
"tscn`` as the open tab, by pressing the play button in the top right corner, "
"or by pressing ``F6``. 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:532
msgid "Giving the player a flash light and the option to sprint"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:534
msgid ""
"Before we get to making the weapons work, there is a couple more things we "
"should add."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:536
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:539
msgid "First we need a few more class variables in our player script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:549
msgid ""
"All of the sprinting variables work exactly the same as the non sprinting "
"variables with similar names."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:552
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:555
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:561
msgid ""
"This gets the flash light node and assigns it to the ``flashlight`` variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:565
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:586
msgid "Let's go over the additions:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:588
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:592
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:597
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:606
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:609
msgid ""
"Now all that's left is changing the acceleration when sprinting. Change "
"``accel = ACCEL`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:619
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:623
msgid ""
"You should now be able to sprint if you press the ``shift`` button, and can "
"toggle the flash light on and off by pressing the ``F`` button!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:625
msgid ""
"Go give it a whirl! 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:628
#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1245
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:666
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:724
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:952
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:977
msgid "Final notes"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:632
msgid ""
"Phew! That was a lot of work. Now you have a fully working first person "
"character!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:634
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:636
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:638
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:641
#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1256
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:681
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:733
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:961
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:985
msgid "If you ever get lost, be sure to read over the code again!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_one.rst:643
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."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:19
msgid ""
"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:21
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:19
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:17
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:17
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:20
msgid "Let's get started!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:24
msgid "Making a system to handle animations"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:26
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:29
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:31
msgid "Add the following code to ``AnimationPlayer_Manager.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:153
msgid "Lets go over what this script is doing:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:157
msgid "Lets start with this script's class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:159
msgid ""
"``states``: A dictionary for holding our animation states. (Further "
"explanation below)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:160
msgid ""
"``animation_speeds``: A dictionary for holding all of the speeds we want to "
"play our animations at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:161
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:162
msgid ""
"``callback_function``: A variable for holding the callback function. "
"(Further explanation below)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:164
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:167
msgid ""
"``states`` is a dictionary with the key being the name of the current state, "
"and the value being an array holding all of the animations (states) we can "
"transition to. For example, if we are in currently in state "
"``Idle_unarmed``, we can only transition to ``Knife_equip``, "
"``Pistol_equip``, ``Rifle_equip``, and ``Idle_unarmed``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:172
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:176
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:180
msgid ""
"(Python example) https://dev.to/karn/building-a-simple-state-machine-in-"
"python"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:181
msgid ""
"(C# example) https://www.codeproject.com/Articles/489136/"
"UnderstandingplusandplusImplementingplusStateplusP"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:182
msgid "(Wiki article) https://en.wikipedia.org/wiki/Finite-state_machine"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:184
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:187
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:189
msgid ""
"``current_state`` will hold the name of the animation state we are currently "
"in."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:191
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:197
msgid "Now lets look at ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:199
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:202
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:207
msgid "Lets look at ``set_animation`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:209
msgid ""
"``set_animation`` changes the animation to the 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:213
msgid ""
"To start we check if the passed in animation name is the same as 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:216
msgid ""
"Next we see if :ref:`AnimationPlayer <class_AnimationPlayer>` has the a "
"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:219
msgid ""
"Then we check if ``current_state`` is set or not. If ``current_state`` is "
"*not* currently set, we set ``current_state`` to the passed in animation "
"name and tell :ref:`AnimationPlayer <class_AnimationPlayer>` to start "
"playing the animation with a blend time of ``-1`` at the speed set in "
"``animation_speeds`` and then we return ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:223
msgid "Blend time is how long to blend/mix the two animations together."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:225
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:227
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 is looks great when you are changing "
"from a walking animation to a running animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:231
msgid ""
"We set the blend time to ``-1`` because we want to instantly change "
"animations."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:233
msgid ""
"If we have a state in ``current_state``, then we get all of the possible "
"states we can transition to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:235
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:241
msgid "Now lets look at ``animation_ended``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:243
msgid ""
"``animation_ended`` is the function that will be called by :ref:"
"`AnimationPlayer <class_AnimationPlayer>` when it's done playing a animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:246
msgid ""
"For certain animation states, we may need to transition into another state "
"when its 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:249
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:253
msgid ""
"the transitions in ``animation_ended`` ideally would 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:259
msgid ""
"Finally we have ``animation_callback``. This function will be called by a "
"function 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:263
msgid ""
"Try running ``Testing_Area.tscn`` to make sure there is 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:267
msgid "Getting the animations ready"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:269
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:272
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:275
msgid ""
"We need to attach a function 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:278
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 at "
"the bottom of the list, click the plus icon on the bottom bar of animation "
"window, right next to the loop button and the up arrow."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:284
msgid ""
"This will bring up a window with three choices. We're wanting to add a "
"function callback track, so click the option that reads \"Add Call Func 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:290
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:294
msgid ""
"The timeline is the window where all of 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:297
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 a point on the timeline."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:301
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:305
msgid ""
"For finer control when scrubbing the timeline, press ``control`` and scroll "
"forwards with the mouse wheel to zoom in. Scrolling backwards will zoom out."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:308
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:310
msgid ""
"Once you get to a point you like, press the little green plus symbol on the "
"far right side of the ``AnimationPlayer`` track. This will place a little "
"green point at the position you are currently at in the animation on your "
"``AnimationPlayer`` track."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:316
msgid ""
"Now we have one more step before we are done with the pistol. Select the "
"\"enable editing of individual keys\" button on the far right corner of the "
"animation window. It looks like a pencil with a little point beside it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:321
msgid ""
"Once you've click that, a new window will open on the right side. Now click "
"the green point on the ``AnimationPlayer`` track. This will bring up the "
"information associated with that point in the timeline. In the empty name "
"field, enter ``animation_callback`` and press ``enter``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:325
msgid ""
"Now when we are playing this animation the callback function will be "
"triggered at that specific point of the animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:327
msgid ""
"Be sure to press the \"enable editing of individual keys\" button again to "
"turn off the ability to edit individual keys so you cannot change one of the "
"transform tracks by accident!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:332
msgid "Let's repeat the process for the rifle and knife firing animations!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:334
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 in the above if you "
"get lost! It is exactly the same, just on a different animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:337
msgid ""
"Go to the \"Rifle_fire\" animation from the animation drop down. Add the "
"function callback track once you reach the bottom of the animation track "
"list by clicking the little plus icon at the bottom of the screen. Find the "
"point where the muzzle starts to flash and click the little green plus "
"symbol to add a function callback point at that position on the track."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:341
msgid ""
"Next, click the \"enable editing of individual keys\" button. Select the "
"newly created function callback point, put \"animation_callback\" into the "
"name field and press ``enter``. Click the \"enable editing of individual keys"
"\" button again to turn off individual key editing. so we cannot change one "
"of the transform tracks by accident."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:346
msgid ""
"Now we need to apply the callback function track to the knife animation. "
"Select the \"Knife_fire\" animation and scroll to the bottom of the "
"animation tracks. Click the plus symbol at the bottom of the animation "
"window and add a function callback track. Next find a point around the first "
"third of the animation to place the animation callback function point at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:350
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:354
msgid ""
"From there click the little green plus to add a function callback point at "
"the current position. Then click the \"enable editing of individual keys\" "
"button, the button with a plus at the bottom right side of the animation "
"window. Select the newly created function callback point, put "
"\"animation_callback\" into the name field and press ``enter``. Click the "
"\"enable editing of individual keys\" button again to turn off individual "
"key editing. so we cannot change one of the transform tracks by accident."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:360
msgid "Be sure to save your work!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:362
msgid ""
"With that done, we are almost ready to start adding the ability to fire to "
"our player script! We need to setup one last scene: The scene for our bullet "
"object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:366
msgid "Creating the bullet scene"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:368
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:373
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. This method we "
"create/spawn a bullet object in the direction our gun is facing, and then it "
"sends itself forward."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:377
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 with 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:380
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 a "
"object also makes the bullet take time to reach its target, it doesn't "
"instantly hit whatever its 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:384
msgid ""
"One of the huge disadvantages 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:388
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 object many times with grenades "
"because they generally bounce around the world before exploding."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:392
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:395
msgid ""
"Halo (Rocket launchers, fragment grenades, sniper rifles, brute shot, and "
"more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:396
msgid ""
"Destiny (Rocket launchers, grenades, fusion rifles, sniper rifles, super "
"moves, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:397
msgid ""
"Call of Duty (Rocket launchers, grenades, ballistic knives, crossbows, and "
"more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:398
msgid "Battlefield (Rocket launchers, grenades, claymores, mortars, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:400
msgid ""
"Another disadvantage with bullet objects is networking. Bullet objects have "
"to sync the positions (at least) with however many clients are connected to "
"the server."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:403
msgid ""
"While we are not implementing any form of networking (as that would be it's "
"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:408
msgid ""
"The other way of handling bullet collisions we will be looking at, is "
"raycasting."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:410
msgid ""
"This method is extremely common in guns that have fast moving bullets that "
"rarely change trajectory change over time."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:412
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:415
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:418
msgid ""
"Halo (Assault rifles, DMRs, battle rifles, covenant carbine, spartan laser, "
"and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:419
msgid ""
"Destiny (Auto rifles, pulse rifles, scout rifles, hand cannons, machine "
"guns, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:420
msgid ""
"Call of Duty (Assault rifles, light machine guns, sub machine guns, pistols, "
"and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:421
msgid "Battlefield (Assault rifles, SMGs, carbines, pistols, and more)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:423
msgid ""
"One huge advantage for this method is it's light on performance. Sending a "
"couple hundred rays through space is *way* easier for the computer to "
"calculate than sending a couple hundred bullet objects."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:427
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:430
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 is "
"heavier on performance."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:434
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:441
msgid ""
"Lets get the bullet object setup. 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:443
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>` childed to it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:446
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:448
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:450
msgid ""
"Why are we using a :ref:`Area <class_Area>` and not a :ref:`RigidBody "
"<class_RigidBody>`? The mean 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 assuring 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:454
msgid ""
"Another reason is simply because it is easier to detect collisions with a :"
"ref:`Area <class_Area>`!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:456
msgid "Here's the script that will control our bullet:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:492
msgid "Lets go through the script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:496
msgid "First we define a few class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:498
msgid "``BULLET_SPEED``: The speed the bullet travels at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:499
msgid ""
"``BULLET_DAMAGE``: The damage the bullet will cause to whatever it collides "
"with."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:500
msgid "``KILL_TIMER``: How long the bullet can last without hitting anything."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:501
msgid "``timer``: A float for tracking how long we've been alive."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:502
msgid ""
"``hit_something``: A boolean for tracking whether or not we've hit something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:504
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:507
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 assure that "
"no bullets will travel forever and consume resources."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:511
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:518
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:523
msgid ""
"``_physics_process`` gets the bullet's local ``Z`` axis. If you look in 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:526
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:528
msgid ""
"After that we add delta time to our timer and check if the timer has as long "
"or longer than our ``KILL_TIME`` constant. If it has, we use ``queue_free`` "
"to free ourselves."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:533
msgid "In ``collided`` we check if we've hit something yet or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:535
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:540
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:543
msgid ""
"We set the Bullet's ``hit_something`` variable to ``true`` because "
"regardless of whether or not the body 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:546
msgid "Then we free the bullet using ``queue_free``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:548
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:551
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 "
"if 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:559
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:562
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:565
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:570
msgid ""
"There is a invisible mesh instance for debugging purposes. The mesh is a "
"small sphere that visually shows where the bullets will be aiming at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:573
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:576
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 the bullets will travel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:580
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:584
msgid ""
"If you are wondering where the positions of the points came from, 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:590
msgid ""
"Open up ``Knife_Point`` and you'll find a :ref:`Area <class_Area>` node. We "
"are using a :ref:`Area <class_Area>` for the knife because we only care for "
"all of 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:595
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:599
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:602
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:608
msgid "Creating the first weapon"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:610
msgid "Lets write the code for each of our weapons, starting with the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:612
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:614
msgid "Add the following code to ``Weapon_Pistol.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:665
msgid "Let's go over how the script works."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:669
msgid "First we define some class variables we'll need in the script:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:671
msgid "``DAMAGE``: The amount of damage a single bullet does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:672
msgid "``IDLE_ANIM_NAME``: The name of the pistol's idle animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:673
msgid "``FIRE_ANIM_NAME``: The name of the pistol's fire animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:674
msgid ""
"``is_weapon_enabled``: A variable for checking whether this weapon is in use/"
"enabled."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:675
msgid "``bullet_scene``: The bullet scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:676
msgid "``player_node``: A variable to hold ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:678
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:680
msgid ""
"All of the weapons we'll make will have all of 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:685
msgid ""
"If we could write all of 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:690
msgid "In ``_ready`` we simply pass over it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:692
msgid ""
"There is one thing of note though, an assumption we're assuming we'll fill "
"in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:694
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:696
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:702
msgid "Next let's look at ``fire_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:704
msgid "The first thing we do is instance the bullet scene we made earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:706
msgid ""
"By instancing the scene, we are creating a new node holding all of the "
"node(s) in the scene we instanced, effectively cloning that scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:708
msgid ""
"Then we add ``clone`` to the first child node of the root of the scene we "
"are currently in. By doing this we're making it at a child of the root node "
"of the currently loaded scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:710
msgid ""
"In other words, we are adding ``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:713
msgid ""
"As mentioned later below in the section on adding sounds, this method makes "
"a 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:716
msgid ""
"Next we set the global transform of the clone to the ``Pistol_Aim_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:718
msgid ""
"You can see that ``Pistol_Aim_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 more or less is "
"at the end of the pistol when it fires."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:721
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:723
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:727
msgid "Now let's look at ``equip_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:729
msgid ""
"The first thing we do is check to see if 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:733
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 most have finished playing the equip animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:736
msgid ""
"We know these animations will transition because we wrote to the code to "
"make them transition in ``Animation_Manager.gd``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:738
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:741
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:746
msgid "Finally, let's look at ``unequip_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:748
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:750
msgid ""
"First we check to see if 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 "
"``pistol_unequip`` animation."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:753
msgid ""
"You may be wondering why we are checking to see if 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:757
msgid ""
"Next we check to see if the player is in ``Idle_unarmed``, which is the "
"animation state we will transition into from ``Pistol_unequip``. If the "
"player is are, 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:760
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:763
msgid "Creating the other two weapons"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:765
msgid ""
"Now that we all of 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:767
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:820
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:822
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:824
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:827
msgid ""
"Then we check to see if the :ref:`Raycast <class_Raycast>` collided with "
"something."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:829
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:832
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:834
msgid ""
"If the body is not the player, we then check to see if they have a function/"
"method called ``bullet_hit``. If they do, 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 which direction the bullet came "
"from."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:839
msgid "Now all we need to do is write the code for the knife."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:841
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:892
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:894
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:896
msgid ""
"Next we want to get all of 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:899
msgid "We next want to go through each of those bodies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:901
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 to looking at the next body in "
"``bodies``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:904
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:907
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:912
msgid "Making the weapons work"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:914
msgid "Lets start making the weapons work in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:916
msgid ""
"First lets start by adding some class variables we'll need for the weapons:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:934
msgid "Lets go over what these new variables will do:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:936
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:937
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:938
msgid "``weapons``: A dictionary that will hold all of the weapon nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:939
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:940
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:941
msgid ""
"``changing_weapon``: A boolean to track whether or not we are changing guns/"
"weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:942
msgid "``changing_weapon_name``: The name of the weapon we want to change to."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:943
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:944
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 reserves."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:948
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:980
msgid "Let's go over what's changed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:982
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:986
msgid ""
"Next we get all of 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:989
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:991
msgid "Then we go through each weapon in ``weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:993
msgid ""
"We first get the weapon node. If the weapon node is not ``null``, we then "
"set it's ``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:996
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:999
msgid ""
"Then we set ``current_weapon_name`` and ``changing_weapon_name`` to "
"``UNARMED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1001
msgid "Finally, we get the UI :ref:`Label <class_Label>` from our HUD."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1005
msgid ""
"Lets 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:1015
msgid "Now we will call ``process_changing_weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1019
msgid ""
"Now lets add all of the player input code for the weapons in "
"``process_input``. Add the following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1059
msgid "Lets go over the additions, starting with how we're changing weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1061
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:1063
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:1066
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:1069
msgid ""
"Next we check to see if ``shift_weapon_positive`` or "
"``shift_weapon_negative`` is pressed. If one of them are, we add/subtract "
"``1`` from ``weapon_change_number``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1072
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:1075
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:1079
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:1083
msgid ""
"If the current weapon node does not equal null, and the player is in it's "
"``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:1088
msgid "Lets add ``process_changing_weapons`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1090
msgid "Add the following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1126
msgid "Lets go over what's happening here:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1128
msgid ""
"The first thing we do is make sure we've revived input to change weapons. We "
"do this by making sure ``changing_weapons`` is ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1130
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:1132
msgid "Then we get the current weapon from ``weapons``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1134
msgid ""
"If the current weapon is not ``null``, then we have need to check to see if "
"the weapon is enabled or not. If the weapon is enabled, we call it's "
"``unequip_weapon`` function so it will start the unequip animation. If the "
"weapon is not enabled, we set ``weapon_unequippped`` to ``true`` because the "
"weapon has successfully been unequipped."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1137
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:1140
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:1142
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:1144
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 or "
"not it's enabled. If it is not enabled, we call it's ``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:1147
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:1150
msgid ""
"Finally, we check to see if the player has successfully equipped the new "
"weapon. If the player has, 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 a empty "
"string."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1156
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:1158
msgid ""
"We need to add ``fire_bullet``, which will be called when 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:1170
msgid "Lets go over what this function is doing:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1172
msgid ""
"First we check if to see if the player is changing weapons or not. If the "
"player is changing weapons, we do not want shoot so we ``return``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1174
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:1178
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:1180
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:1186
msgid ""
"Before we are ready to test our new weapons, we still have a little bit of "
"work to do."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1189
msgid "Creating some test subjects"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1191
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:1194
msgid "Now we need to add this code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1211
msgid "Lets go over how ``bullet_hit`` works:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1214
msgid ""
"First we get the bullet's forward directional vector. This is so we can tell "
"which direction the bullet will hit the :ref:`RigidBody <class_RigidBody>` "
"at. 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:1217
msgid ""
"We need to boost the directional vector by ``BASE_BULLET_BOOST`` so the "
"bullet's back a bit more of a punch and move the :ref:`RigidBody "
"<class_RigidBody>` nodes in a visible way. You can just "
"``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:1221
msgid "Then we apply a impulse using ``apply_impulse``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1223
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:1229
msgid ""
"Finally, we need to calculate the force for the impulse. For this we use 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:1234
msgid ""
"Now we need to attach this script to all of the :ref:`RigidBody "
"<class_RigidBody>` nodes we want to effect."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1236
msgid ""
"Open up ``Testing_Area.tscn`` and select all of the cubes parented to the "
"``Cubes`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1238
msgid ""
"If you select the top cube, and then hold down ``shift`` and select the last "
"cube, Godot will select all of the cubes in between!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1241
msgid ""
"Once you have all of the cubes selected, scroll down in the inspector until "
"you get to the 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:1249
msgid ""
"That was a lot of code! But now with all that done you can go give your "
"weapons a test!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1251
msgid ""
"You should now be able to fire as many bullets as you want on the cubes and "
"they will move in response to the bullets colliding into them."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_two.rst:1254
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:1258
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."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:17
msgid ""
"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:23
msgid "Changing levels"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:25
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:27
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 ``F6`` to play the open "
"scene, or press the ``play current scene button``, and give it them a whirl."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:32
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:35
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:38
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:74
msgid ""
"Now you can fire at all of the rigid bodies in either level and they will "
"react to bullets hitting them!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:77
msgid "Adding ammo"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:79
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:81
msgid "First we need to define a few variables in each of our weapon scripts."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:83
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:192
msgid "Open up ``Weapon_Pistol.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:91
msgid "``ammo_in_weapon``: The amount of ammo currently in the pistol"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:92
msgid ""
"``spare_ammo``: The amount of ammo we have left in reserve for the pistol"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:93
msgid "``AMMO_IN_MAG``: The amount of ammo in a fully reload weapon/magazine"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:95
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:97
msgid ""
"Add the following right under ``Clone.BULLET_DAMAGE = DAMAGE``: "
"``ammo_in_weapon -= 1``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:99
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:104
msgid "Now we need to add ammo for both the rifle and the knife."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:106
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 of our weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:109
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 all our weapons have the same variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:112
msgid "Add the following class variables to ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:120
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:123
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:131
msgid ""
"And because the knife does not consume ammo, that is all we need to add."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:135
msgid "Now all we need to do is change a one thing in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:137
msgid ""
"All we need to change 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:152
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:156
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:158
msgid "First, add ``process_UI(delta)`` to ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:160
msgid "Now add the following to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:172
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:234
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:162
msgid "Let's go over what's happening:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:174
msgid ""
"First 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:177
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:179
msgid ""
"Then change ``UI_status_label``'s text to show the player's health, along "
"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:183
msgid "Now we can see how much ammo the player has through the HUD."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:186
msgid "Adding reloading to the weapons"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:188
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:190
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:201
msgid ""
"``CAN_RELOAD``: A boolean to track whether this weapon has the ability to "
"reload"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:202
msgid ""
"``CAN_REFIL``: A boolean to track whether we can refill this weapon's spare "
"ammo. We will not be using ``CAN_REFIL`` in this part, but we will in the "
"next part!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:203
msgid ""
"``RELOADING_ANIM_NAME``: The name of the reloading animation for this weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:205
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:236
msgid ""
"First we define a variable to see whether or not this weapon can reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:238
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:241
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 assure "
"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:244
msgid ""
"If we still can reload, then we calculate the amount of ammo needed to "
"reload the weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:246
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:248
msgid ""
"If the player does not have enough ammo, we add all of the ammo left in "
"``spare_ammo``, and then set ``spare_ammo`` to ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:250
msgid ""
"Next we play the reloading animation for this weapon, and then return "
"``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:252
msgid "If the player could not reload, we return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:256
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:265
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:267
msgid "Now we need to add ``reload_weapon`` to ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:296
msgid "This code is exactly the same as the pistol."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:300
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:309
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:312
msgid "Now we need to add ``reloading_weapon``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:319
msgid "Since we cannot reload a knife, we always return ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:322
msgid "Adding reloading to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:324
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:330
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:333
msgid "Next we need to add another function call to ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:335
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:346
msgid ""
"Now we need to add ``process_reloading``. Add the following function to "
"``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:357
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:408
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:363
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:423
msgid "Let's go over what's happening here."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:359
msgid "First we check to make sure the player is trying to reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:361
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:363
msgid ""
"If the current weapon is equal to ``null``, then the current weapon is "
"``UNARMED``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:365
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:370
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:372
msgid ""
"The first thing we need to change is in the code for changing weapons. We "
"need to add a additional check (``if reloading_weapon == false:``) to see if "
"the player is reloading:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:383
msgid ""
"This makes it where the player cannot change weapons if the player is "
"reloading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:385
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:410
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:412
msgid "Then we check to see if the ``reload`` action has been pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:414
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 if the weapon "
"can reload or not using its ``CAN_RELOAD`` constant."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:417
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:419
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:421
msgid ""
"If the player is not reloading with any weapon, we set ``reloading_weapon`` "
"to ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:425
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:427
msgid ""
"We also need to add a 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:430
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:448
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:451
msgid ""
"This will make it where the player will try to reload when the player tries "
"to fire a empty weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:455
msgid ""
"With that done, the player can now reload! Give it a try! Now you can fire "
"all of the spare ammo for each weapon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:458
msgid "Adding sounds"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:460
msgid ""
"Finally, let's add some sounds that play when the player is reloading, "
"changing weapons, and when the player is firing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:462
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:466
msgid ""
"Open up ``SimpleAudioPlayer.tscn``. It is simply a :ref:`Spatial "
"<class_Spatial>` with a :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` "
"as it's child."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:468
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:471
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:474
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:479
msgid ""
"Create a new script and call it ``SimpleAudioPlayer.gd``. Attach it to the :"
"ref:`Spatial <class_Spatial>` in ``SimpleAudioPlayer.tscn`` and insert the "
"following code:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:530
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 the ``play_sound``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:533
#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:236
msgid "Let's go over what's happening here:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:537
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 a :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:541
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:544
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:548
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:550
msgid ""
"If you are using a :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:553
msgid ""
"Finally, we tell the :ref:`AudioStreamPlayer <class_AudioStreamPlayer>` to "
"play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:555
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:559
msgid "This system is extremely simple and has some major flaws:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:561
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:566
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:571
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:576
msgid ""
"With that done, let's open up ``Player.gd`` again. First we need to load the "
"``SimpleAudioPlayer.tscn``. Place the following code in the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:583
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:595
msgid "Lets walk through what this function does:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:599
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:602
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:604
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:610
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 to 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:614
msgid ""
"The third line adds our newly created ``SimpleAudioPlayer`` 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:617
msgid ""
"Finally, we call the ``play_sound`` function and pass in the arguments "
"passed in to ``create_sound``. This will call ``SimpleAudioPlayer.gd``'s "
"``play_sound`` function with the passed in arguments."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:622
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:624
msgid "Open up ``Weapon_Pistol.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:626
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:632
msgid ""
"Now when the player fires the pistol, we'll play the ``pistol_shot`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:634
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:656
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:641
#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:663
msgid "Now when the player reloads, we'll play the ``gun_cock`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:645
msgid "Now let's add sounds to the rifle. Open up ``Weapon_Rifle.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:648
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:654
msgid ""
"Now when the player fires the rifle, we'll play the ``rifle_shot`` sound."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:670
msgid ""
"Now you have weapons with limited ammo that play sounds when you fire them!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_three.rst:672
msgid ""
"At this point we have all of the basics of a FPS working. There's 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:675
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:678
msgid ""
"In 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:683
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 pick ups, ammo pick ups, 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."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:15
msgid ""
"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:20
msgid "Adding joypad input"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:22
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:25
msgid ""
"First 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:27
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:31
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:33
msgid "movement_sprint: ``Device 0, Button 4 (L, L1)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:34
msgid "fire: ``Device 0, Button 0 (PS Cross, XBox A, Nintendo B)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:35
msgid "reload: ``Device 0, Button 0 (PS Square, XBox X, Nintendo Y)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:36
msgid "flashlight: ``Device 0, Button 12 (D-Pad Up)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:37
msgid "shift_weapon_positive: ``Device 0, Button 15 (D-Pad Right)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:38
msgid "shift_weapon_negative: ``Device 0, Button 14 (D-Pad Right)``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:39
msgid "fire_grenade: ``Device 0, Button 1 (PS Circle, XBox B, Nintendo A).``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:41
msgid "These are already set up for you if you downloaded the starter assets"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:43
msgid "Once you are happy with the input, close the project settings and save."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:47
msgid "Now let's open up ``Player.gd`` and add joypad input."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:49
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:57
msgid "Let's go over what each of these do:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:59
msgid ""
"``JOYPAD_SENSITIVITY``: This is how fast the joypad's joysticks will move "
"the camera."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:60
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:62
msgid ""
"Many joypads jitter around a certain point. To counter this, we ignore any "
"movement in a with 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:65
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:67
msgid "Now we are ready to start handling joypad input!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:71
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:94
msgid "Let's go over what we're doing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:96
msgid "First we check to see if there is a connected joypad."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:98
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:102
msgid ""
"This tutorial assumes you are using a XBox 360 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:106
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 calculating."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:109
msgid ""
"You can find a great article explaining all about how to handle joypad/"
"controller dead zones here: http://www.third-helix.com/2013/04/12/doing-"
"thumbstick-dead-zones-right.html"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:112
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:115
msgid "Finally, we add ``joypad_vec`` to ``input_movement_vector``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:117
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 the "
"player pushes in the same direction with both the keyboard and the joypad!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:122
msgid ""
"Make a new function called ``process_view_input`` and add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:164
msgid ""
"First 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:166
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:169
msgid ""
"As stated above, I do not (currently) has 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:172
msgid ""
"We then account for the joypad's dead zone, exactly like in "
"``process_input``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:174
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:176
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:179
msgid ""
"Due to 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:182
msgid ""
"Finally, we clamp the camera's rotation so the player cannot look upside "
"down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:186
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:188
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:190
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:192
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:196
msgid "Adding mouse scroll wheel input"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:198
msgid ""
"Let's add one more input related feature before we start working on the pick "
"ups 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:200
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:458
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:511
msgid "Open up ``Player.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:207
msgid "Let's go over what each of these new variables will be doing:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:209
msgid "``mouse_scroll_value``: The value of the mouse scroll wheel."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:210
msgid ""
"``MOUSE_SENSITIVITY_SCROLL_WHEEL``: How much a single scroll action "
"increases mouse_scroll_value"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:214
msgid "Now let's add the following to ``_input``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:238
msgid ""
"First we check if the event is a ``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:241
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 remove ``MOUSE_SENSITIVITY_SCROLL_WHEEL`` to/from "
"``mouse_scroll_value``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:244
msgid ""
"Next we clamp mouse scroll value to assure it is inside the range of "
"selectable weapons."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:246
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 a "
"``int``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:248
msgid ""
"We are casting ``mouse_scroll_value`` to a ``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 "
"try to run the project."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:251
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 than 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:255
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 "
"assure that each weapon takes exactly the same amount of scrolling to change."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:261
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:267
msgid ""
"Now the scroll value will be changed with the keyboard input. If we did not "
"change this, the scroll value will be out of sync. If the scroll wheel is "
"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:272
msgid "Now you can change weapons using the scroll wheel! Go give it a whirl!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:275
msgid "Adding the health pick ups"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:277
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:279
msgid "Open up ``Health_Pickup.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:281
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:283
msgid ""
"This is because we're actually going to be making two sizes of health pick "
"ups, 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:286
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 pick up, so the smaller health pick up has a "
"trigger collision shape closer to it's size."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:290
msgid ""
"The last thing to note is how we have a :ref:`AnimationPlayer "
"<class_AnimationPlayer>` node so the health kit spins around slowly and bobs "
"up and down."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:292
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:351
msgid ""
"Let's go over what this script is doing, starting with its class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:353
msgid ""
"``kit_size``: The size of the health pick up. Notice how we're using a "
"``setget`` function to tell if it's changed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:354
msgid ""
"``HEALTH_AMMOUNTS``: The amount of health each pick up in each size contains."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:355
msgid ""
"``RESPAWN_TIME``: The amount of time, in seconds, it takes for the health "
"pick up to respawn"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:356
msgid ""
"``respawn_timer``: A variable used to track how long the health pick up has "
"been waiting to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:357
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:359
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:363
msgid ""
"Also, notice how we are using a exported variable. This is so we can change "
"the size of the health pick ups in the editor. This makes it where 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:366
msgid ""
"See :ref:`doc_GDScript` and scroll down to the Exports section for a list of "
"of export hints you can use."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:370
msgid "Let's look at ``_ready``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:372
msgid ""
"First we connect the ``body_entered`` signal from the "
"``Health_Pickup_Trigger`` to the ``trigger_body_entered`` function. This "
"makes is where any body that enters the :ref:`Area <class_Area>` triggers "
"the ``trigger_body_entered`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:375
msgid ""
"Next we set ``is_ready`` to ``true`` so we can use the ``setget`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:377
msgid ""
"Then we hide all of 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:380
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:384
msgid "Next let's look at ``kit_size_changed``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:386
msgid "The first thing we do is check to see if ``is_ready`` is ``true``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:388
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:390
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:393
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:397
msgid "Now let's look at ``kit_size_change_values``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:399
msgid ""
"The first thing we do is check to see which size was passed in. Based on "
"which size we're wanting to enable/disable, we want to get different nodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:401
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:403
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:407
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:409
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:414
msgid "Finally, let's look at ``trigger_body_entered``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:416
msgid ""
"The first thing we do is see whether or not the body that 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:419
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:424
msgid ""
"The last thing we need to do before the player can use this health pick up "
"is add a few things to ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:426
msgid "Open up ``Player.gd`` and add the following class variable:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:432
msgid "``MAX_HEALTH``: The maximum amount of health a player can have."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:434
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:442
msgid "Let's quickly go over what this does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:444
msgid ""
"We first add ``additional_health`` to the player's current health. We then "
"clamp the health so that it cannot exceed a value higher than "
"``MAX_HEALTH``, nor a value lower than ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:449
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 pick up 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:453
msgid "Adding the ammo pick ups"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:455
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 pick ups "
"next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:458
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 adjust for the difference in mesh sizes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:461
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:522
msgid ""
"You may have noticed this code looks almost exactly the same as the health "
"pick up. 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:525
msgid ""
"First, notice how there is ``AMMO_AMOUNTS`` instead of ``HEALTH_AMMOUNTS``. "
"``AMMO_AMOUNTS`` will be how many ammo clips/magazines the pick up add to "
"the current weapon. (Unlike ``HEALTH_AMMOUNTS`` which was how many health "
"points, we instead add an entire clip for the current weapon, instead of the "
"raw ammo amount)"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:528
msgid ""
"The only other thing to notice is in ``trigger_body_entered``. We're "
"checking and calling a function called ``add_ammo`` instead of "
"``add_health``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:530
msgid ""
"Other than those two small changes, everything else is exactly the same as "
"the health pick up!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:534
msgid ""
"All we need to do make the ammo pick ups 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:543
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:739
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:924
msgid "Let's go over what this function does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:545
msgid ""
"The first thing we check is to see whether the player is using ``UNARMED`` "
"or not. Because ``UNARMED`` does not have a node/script, we want to make "
"sure the player is not using ``UNARMED`` before trying to get the node/"
"script attached to ``current_weapon_name``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:548
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`` variable times however much "
"ammo clips we're adding (``additional_ammo``)."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:553
msgid ""
"With that done, you should now be able to get additional ammo! Go place some "
"ammo pick ups in one/both/all of the scenes and give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:555
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 a 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:559
msgid "Adding breakable targets"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:561
msgid "Before we end this part, let's add some targets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:563
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:565
msgid ""
"First, notice how we're not using a :ref:`RigidBody <class_RigidBody>` node, "
"but rather a :ref:`StaticBody <class_StaticBody>` node instead. The reason "
"behind this is our non-broken targets will not be moving anywhere, using a :"
"ref:`RigidBody <class_RigidBody>` would be more hassle then its worth, since "
"all it has to do is stay still."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:569
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:571
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:574
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:578
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 where the player can shoot at the broken pieces and "
"they will react to the bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:581
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:583
msgid "Add the following code to ``Target.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:641
msgid "Let's go over what this script does, starting with the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:643
msgid ""
"``TARGET_HEALTH``: The amount of damage needed to break a fully healed "
"target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:644
msgid "``current_health``: The amount of health this target currently has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:645
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:646
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:647
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:648
msgid ""
"``target_respawn_timer``: A variable to track how long a target has been "
"broken."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:649
msgid ""
"``destroyed_target``: A :ref:`PackedScene <class_PackedScene>` to hold the "
"broken target scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:651
msgid ""
"Notice how we're using a exported variable (a :ref:`PackedScene "
"<class_PackedScene>`) to get the broken target scene instead of using "
"``preload``. By using an exported variable, we can chose 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:657
msgid "Let's look at ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:659
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 want 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:662
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:665
msgid ""
"Next we get the collision shape and assign it to ``target_collision_shape``. "
"The reason we need to collision shape is because even when the mesh is "
"invisible, the collision shape will still exist in the physics world. This "
"makes it where the player can 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:671
msgid "Next let's look at ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:673
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 more than "
"``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:675
msgid "If it is, we then remove ``delta`` from it."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:677
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:680
msgid "In this case, we want to respawn the target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:682
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:684
msgid ""
"Next we enable the collision shape by setting its ``disabled`` boolean to "
"``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:686
msgid "Then we make the target, and all of it's children nodes, visible again."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:688
msgid ""
"Finally, we reset the target's health (``current_health``) to "
"``TARGET_HEALTH``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:692
#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:904
msgid "Finally, let's look at ``bullet_hit``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:694
msgid ""
"The first the we do is remove however much damage the bullet does from the "
"target's health."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:696
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:698
msgid ""
"We first instance a new destroyed target scene, and assign it to a new "
"variable, ``clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:700
msgid "Next we add ``clone`` as a child of the broken target holder."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:702
msgid ""
"For bonus effect, we want to make all of the target pieces explode outwards. "
"To do this, we iterate over all of the children in ``clone``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:704
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:708
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 explosive you want "
"your targets to shatter."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:711
msgid ""
"Next we set the target's respawn timer. We set the timer to "
"``TARGET_RESPAWN_TIME``, so it takes ``TARGET_RESPAWN_TIME`` many seconds "
"for the target to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_four.rst:713
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:717
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:720
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:728
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:730
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:735
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."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:15
msgid ""
"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:20
msgid "Adding grenades"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:22
msgid ""
"First, let's give the player some grenades to play with. Open up ``Grenade."
"tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:24
msgid ""
"There's 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:27
msgid ""
"The second thing to note is ``Blast_Area``. This is a :ref:`Area "
"<class_Area>` node that will represent the blast radius of the grenade."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:29
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 of the particles at once. The particles are "
"also emitting using world coordinates instead of local coordinates, so we "
"have ``Local Coords`` unchecked as well."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:33
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:35
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:91
msgid "Let's go over what's happening, starting with the class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:93
msgid ""
"``GRENADE_DAMAGE``: The amount of damage the grenade causes when it explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:94
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:95
msgid ""
"``grenade_timer``: A variable for tracking how long the grenade has been "
"created/thrown."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:96
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:97
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:98
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:99
msgid ""
"``grenade_mesh``: The :ref:`MeshInstance <class_MeshInstance>` for the "
"grenade."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:100
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:101
msgid ""
"``explosion_particles``: The :ref:`Particles <class_Particles>` that play "
"when the grenade explodes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:103
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:109
msgid "Now let's turn our attention to ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:111
msgid ""
"First we get all of the nodes we'll need and assign them to the proper class "
"variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:113
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:116
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:119
msgid ""
"After we get all of 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:124
msgid "Now let's look at ``_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:126
msgid ""
"First we check to see if the ``grenade_timer`` is less than "
"``GRENADE_TIMER``. 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:129
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:133
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:136
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:138
msgid ""
"Then we get all of 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:141
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_time``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:143
msgid ""
"Next we check to see if ``explosion_wait_timer`` is more than or equal to "
"``EXPLOSTION_WAIT_TIME``. Because we added ``delta``, this will only be "
"called once. If ``explosion_wait_timer`` is more 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:149
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:151
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:155
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:245
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:247
msgid "First, we have a few more class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:249
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:250
msgid ""
"``attach_point``: A variable to hold a :ref:`Spatial <class_Spatial>` that "
"will be at the position the sticky grenade collided at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:251
msgid ""
"``player_body``: The player's :ref:`KinematicBody <class_KinematicBody>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:253
msgid ""
"These additions are so the sticky grenade can stick to any :ref:`PhysicsBody "
"<class_PhysicsBody>` it happens to 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:258
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:263
msgid "Next let's take a look at ``collided_with_body``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:265
msgid ""
"First 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:270
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:273
msgid ""
"Next we check if the sticky grenade has attached to something already or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:275
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:277
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:280
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:283
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:288
msgid "Finally, lets go over the few changes in ``_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:290
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:292
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:296
msgid ""
"The only other change is now before we free/destroy the sticky grenade is to "
"check to see if the sticky grenade has a 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:300
msgid "Adding grenades to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:302
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:304
msgid ""
"First, 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:307
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 the grenades are tossed at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:310
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:320
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:321
msgid ""
"``current_grenade``: The name of the grenade the player is currently using."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:322
msgid "``grenade_scene``: The grenade scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:323
msgid ""
"``sticky_grenade_scene``: The sticky grenade scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:324
msgid ""
"``GRENADE_THROW_FORCE``: The force at which the player will throw the "
"grenades at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:326
msgid "Most of these variables are similar to how we have out weapons set up."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:328
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:333
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:365
msgid ""
"First, 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:368
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:371
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:374
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:380
msgid ""
"Now the player can use both types of grenades, but there is 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:382
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:384
msgid ""
"First, 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:400
msgid "Now we'll show how many grenades the player has left in the UI."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:402
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:410
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:412
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:415
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:417
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:419
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:434
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:436
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:443
msgid "``GRENADE_AMOUNTS``: The amount of grenades each pick up contains."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:445
msgid ""
"Notice how the second element in ``GRENADE_AMOUNTS`` is ``0``. This is so "
"the small ammo pick up does not give the player any additional grenades."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:450
msgid "Now you should be able to throw grenades now! Go give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:454
msgid "Adding the ability to grab and throw RigidBody nodes to the player"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:456
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:467
msgid ""
"``grabbed_object``: A variable to hold the grabbed :ref:`RigidBody "
"<class_RigidBody>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:468
msgid ""
"``OBJECT_THROW_FORCE``: The force the player throws the grabbed object at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:469
msgid ""
"``OBJECT_GRAB_DISTANCE``: The distance away from the camera the player holds "
"the grabbed object at."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:470
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:472
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:510
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:353
msgid "Let's go over what's happening."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:512
msgid ""
"First 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:516
msgid "Next we check to see whether or not ``grabbed_object`` is ``null``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:520
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:522
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:525
msgid ""
"see :ref:`Ray-casting <doc_ray-casting>` for more information on raycasting "
"in Godot."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:527
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:530
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:533
msgid ""
"Then we check to see if we got a result back from the ray. If we have, 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:535
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 does not move."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:538
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 will "
"means it will not be able to collide with anything."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:543
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:545
msgid ""
"We first set the :ref:`RigidBody <class_RigidBody>` we holding mode to "
"``MODE_RIGID``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:547
msgid ""
"This is making a rather large assumption that the all 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:550
msgid ""
"If you have :ref:`RigidBody <class_RigidBody>`'s 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:553
msgid ""
"Then we apply an impulse to send it flying forward. We send it flying in the "
"direction the camera is facing, at ``OBJECT_THROW_FORCE`` force."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:555
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:557
msgid ""
"This is, once again, making a rather large assumption that all 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>` "
"before you change them to ``0``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:560
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:564
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:566
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:569
msgid ""
"If the player is holding a 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:573
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:590
msgid "Now the player cannot change weapons or reload while holding an object."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:592
msgid ""
"Now you can grab and throw RigidBody nodes while in a ``UNARMED`` state! Go "
"give it a try!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:595
msgid "Adding a turret"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:597
msgid "Next, let's make a turret to shoot the player!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:599
msgid ""
"Open up ``Turret.tscn``. Expand ``Turret`` if it's not already expanded."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:601
msgid ""
"Notice how the turret is broken up into several parts. We have a ``Base``, "
"``Head``, ``Vision_Area``, and a ``Smoke`` :ref:`Particles "
"<class_Particles>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:603
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's several meshes, a :ref:"
"`StaticBody <class_StaticBody>` and a :ref:`Raycast <class_Raycast>` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:606
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:609
msgid ""
"``Vision_Area`` is a :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:611
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:615
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:781
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:783
msgid ""
"``use_raycast``: A exported boolean so we can change whether the turret uses "
"objects or raycasting for bullets."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:784
msgid ""
"``TURRET_DAMAGE_BULLET``: The amount of damage a single bullet scene does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:785
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:786
msgid ""
"``FLASH_TIME``: The amount of time (in seconds) the muzzle flash meshes are "
"visible."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:787
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:788
msgid "``FIRE_TIME``: The amount of time (in seconds) needed to fire a bullet."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:789
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:790
msgid "``node_turret_head``: A variable to hold the ``Head`` node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:791
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:792
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:793
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:794
msgid "``ammo_in_turret``: The amount of ammo currently in the turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:795
msgid "``AMMO_IN_FULL_TURRET``: The amount of ammo in a full turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:796
msgid "``AMMO_RELOAD_TIME``: The amount of time it takes the turret to reload."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:797
msgid ""
"``ammo_reload_timer``: A variable for tracking how long the turret has been "
"reloading."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:798
msgid "``current_target``: The turret's current target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:799
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:800
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:801
msgid "``smoke_particles``: A variable to hold the smoke particles node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:802
msgid "``turret_health``: The amount of health the turret currently has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:803
msgid "``MAX_TURRET_HEALTH``: The amount of health a fully healed turret has."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:804
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:805
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:806
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:808
msgid "Phew, that's quite a few class variables!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:812
msgid "Let's go through ``_ready`` next."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:814
msgid ""
"First 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:816
msgid ""
"We then get all of the nodes and assign them to their respective variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:818
msgid ""
"Next add some exceptions to the :ref:`Raycast <class_Raycast>` so the turret "
"cannot hurt itself."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:820
msgid ""
"Then we make both flash meshes invisible to start, since we are not going to "
"be firing during ``_ready``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:822
msgid ""
"We then get the smoke particles node and assign it to the "
"``smoke_particles`` node. We also set ``emitting`` to ``false`` to assure "
"the particles are not emitting until the turret is broken."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:825
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:829
msgid "Now let's go through ``_physics_process``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:831
msgid ""
"First we check to see if 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:833
msgid ""
"Next we check to see if ``flash_timer`` is more 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:837
msgid ""
"Next we check to see if the turret has a target or not. 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:840
msgid ""
"We then check to see if the turret's health is more than zero. If it is, we "
"then check to see if there is ammo in the turret."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:842
msgid ""
"If there is ammo in the turret, we then check to see if ``fire_timer`` is "
"more than zero. If ``fire_timer`` is more than zero, the turret cannot fire "
"and we need to remove ``delta`` from ``fire_timer``. If ``fire_timer`` is "
"equal to or less than zero, the turret can fire a bullet, so we call the "
"``fire_bullet`` function."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:845
msgid ""
"If there is not any ammo in the turret, we check to see if "
"``ammo_reload_timer`` is more than zero. If ``ammo_reload_timer`` is more "
"than zero, we subtract ``delta`` from ``ammo_reload_timer``. If "
"``ammo_reload_timer`` is equal to or less than 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:849
msgid ""
"Next we check to see if 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 to see if ``destroyed_timer`` is more than zero. If "
"destroyed timer is more than zero, we subtract ``delta`` from "
"``destroyed_timer``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:852
msgid ""
"If ``destyored_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:857
msgid "Next let's go through ``fire_bullet``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:859
msgid "First we check to see whether the turret is using a raycast or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:861
msgid ""
"The code for the 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:864
msgid ""
"We first make the raycast look at the target, assuring 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 if the raycast "
"collided with anything. If the raycast has collided with something, we then "
"check to see if the collided body has the ``bullet_hit`` function. If it "
"does, we call it and pass in the damage a single raycast bullet does along "
"with the raycast's transform. We then remove ``1`` from ``ammo_in_turret``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:869
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:872
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 it's damage and speed using "
"the turret's constant class variables. We then remove ``1`` from "
"``ammo_in_turret``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:876
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 to "
"``FLASH_TIME`` and ``FIRE_TIME`` respectively. We then check to see if the "
"turret used the last bullet in its ammo. If the turret has used the last "
"bullet, we set ``ammo_reload_timer`` to ``AMMO_RELOAD_TIME`` so the turret "
"reloads."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:882
msgid ""
"Let's look at ``body_entered_vision`` next, and thankfully it is rather "
"short."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:884
msgid ""
"We first check to see if the turret currently has a target by checking to "
"see if ``current_target`` is equal to ``null``. If the turret does not have "
"a target, we then check to see if the body that just entered the vision :ref:"
"`Area <class_Area>` is a :ref:`KinematicBody <class_KinematicBody>`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:887
msgid ""
"..note:: We're assuming the turret should only should fire at :ref:"
"`KinematicBody <class_KinematicBody>` nodes, since that is what the player "
"is using."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:889
msgid ""
"If the body that just 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:894
msgid "Now let's look at ``body_exited_vision``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:896
msgid ""
"First we check to see if the turret has a target. If the turret has a "
"target, we then check to see if the body that has just left the turret's "
"vision area is the turret's target."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:899
msgid ""
"If the body that just left the area is the turret's current target, we set "
"``current_target`` to ``null``, set ``is_active`` to ``false``, and reset "
"all of 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:906
msgid ""
"We first remove however much damage the bullet causes from the turret's "
"health."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:908
msgid ""
"Then we check to see if the turret has been destroyed (health being zero or "
"less). If the turret is destroyed, we start the smoke particles emitting 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:913
msgid ""
"Phew, 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:917
msgid "Add the following code to ``TurretBodies.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:932
msgid ""
"All this code does is call ``bullet_hit`` on whatever node "
"``path_to_turret_root`` leads to. 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:935
msgid ""
"Now select the other :ref:`StaticBody <class_StaticBody>` node (either in "
"``Body`` or ``Head``) and assign ``TurretBodies.gd`` to it. Once the script "
"is attached, assign the :ref:`NodePath <class_NodePath>` to the ``Turret`` "
"node."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:940
msgid ""
"The last thing we need to do is add a way for the player to be hurt. Since "
"all of 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:942
msgid "Open ``Player.gd`` and add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_five.rst:949
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:956
msgid ""
"Now you the player 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:958
msgid ""
"In :ref:`doc_fps_tutorial_part_six`, 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_five.rst:963
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."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:18
msgid ""
"The finished project from :ref:`doc_fps_tutorial_part_four` will be the "
"starting project for part 6"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:23
msgid "Adding the main menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:25
msgid ""
"First, 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:27
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:30
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:33
msgid ""
"Feel free to expand all of the nodes and see how their 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:36
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:123
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:126
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:128
msgid "Let's look at the class variables first."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:130
msgid ""
"``start_menu``: A variable to hold the ``Start_Menu`` :ref:`Panel "
"<class_Panel>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:131
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:132
msgid ""
"``options_menu``: A variable to hold the ``Options_Menu`` :ref:`Panel "
"<class_Panel>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:133
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:134
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:135
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:137
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:141
msgid "Now let's go over ``_ready``"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:143
msgid ""
"First we get all of the :ref:`Panel <class_Panel>` nodes and assign them to "
"the proper variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:145
msgid ""
"Next we connect all of the buttons ``pressed`` signals to their respective "
"``[panel_name_here]_button_pressed`` functions."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:147
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:149
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:152
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:156
msgid "In ``start_menu_pressed``, we check to see which button is pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:158
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:162
msgid ""
"In ``level_select_menu_button_pressed``, we check to see which button is "
"pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:164
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:176
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:166
msgid ""
"If one of the scene changing buttons are 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 it's ``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:170
msgid "Don't worry about the singleton, we'll get there soon!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:174
msgid ""
"In ``options_menu_button_pressed``, we check to see which button is pressed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:178
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 it's current value."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:180
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:184
msgid "Finally, lets take a look at ``set_mouse_and_joypad_sensitivity``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:186
msgid ""
"First we get the ``Globals`` singleton and assign it to a local variable."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:188
msgid ""
"We then set the ``mouse_sensitivity`` and ``joypad_sensitvity`` variables to "
"the values in their respective :ref:`HSlider <class_HSlider>` node "
"counterparts."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:191
msgid "Making the ``Globals`` singleton"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:193
msgid ""
"Now, for this all 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:195
msgid "Add the following to ``Globals.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:210
msgid ""
"As you can see, it's quite small and simple. As this part progresses we will "
"keeping adding complexities to ``Global.gd``, but for now all it is doing is "
"holding two class variables, and abstracting how we change scenes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:213
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:214
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:216
msgid ""
"Right now all we will be using ``Globals.gd`` for is a way to carry "
"variables across scenes. Because the sensitivity for our mouse and joypad "
"are stored in ``Globals.gd``, any changes we make in one scene (like "
"``Main_Menu``) will effect the sensitivity for the player."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:219
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:221
msgid ""
"That's all of 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:223
msgid "Open up the project settings and click the ``AutoLoad`` tab."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:227
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 the picture above, then press "
"``Add``!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:230
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:232
msgid ""
"For more information on singleton/autoload scripts, see :ref:"
"`doc_singletons_autoload`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:234
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:236
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:240
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:244
msgid "Adding the debug menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:246
msgid ""
"Now let's add a simple debugging scene so the 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:248
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 the game is running at, one for showing what OS the game "
"is running on, and a label for showing the Godot version the game is running "
"with."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:251
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:264
msgid "Let's go over what this script does."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:268
msgid ""
"In ``_ready`` we set the ``OS_Label``'s text to the name provided in :ref:"
"`OS <class_OS>` using the ``get_name`` function. This will return the name "
"of the OS (or Operating System) that Godot was compiled for. 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:272
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 Godot is currently "
"running with. We only care for 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:276
msgid ""
"In ``_process`` we set the text of the ``FPS_Label`` to ``Engine."
"get_frames_per_second``, but because ``get_frames_per_second`` returns a "
"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:281
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:288
msgid "to this instead:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:295
msgid ""
"This will call a new function in our singleton called ``set_debug_display``, "
"so let's add that next!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:299
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:390
msgid "Open up ``Globals.gd`` and add the following class variables:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:313
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:314
msgid "``DEBUG_DISPLAY``: The debug display scene we worked on earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:315
msgid ""
"``debug_display``: A variable to hold the debug display when/if there is one."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:317
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:326
msgid ""
"Now in ``_ready``, we creating a new canvas layer, assign it to "
"``canvas_layer`` and add it as a child. Because ``Globals.gd`` is a 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:330
msgid ""
"The reason we're adding a :ref:`CanvasLayer <class_CanvasLayer>` is so all "
"of 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:333
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 scene, meaning you can run into memory "
"problems if you are instancing/spawning lots of nodes and are not freeing "
"them."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:339
msgid "Now we need to add ``set_debug_display`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:355
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:357
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:360
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:366
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:368
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:373
msgid "Adding a pause menu"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:375
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:377
msgid "Open up ``Pause_Popup.tscn``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:379
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:382
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 where 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:386
msgid ""
"Now that we've looked at how ``Pause_Popup.tscn`` is set up, lets 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 of the code for the pop "
"up there."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:398
msgid "``MAIN_MENU_PATH``: The path to the main menu scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:399
msgid "``POPUP_SCENE``: The pop up scene we looked at earlier."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:400
msgid "``popup``: A variable to hold the pop up scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:402
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:427
msgid ""
"First 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:430
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:432
msgid ""
"We then get the quit button and assign it's ``pressed`` signal to "
"``popup_quit``, which we will be adding shortly."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:434
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:437
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:439
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:442
msgid "Finally, get pause the entire :ref:`SceneTree <class_SceneTree>`."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:444
msgid "For more information on pausing in Godot, see :ref:`doc_pausing_games`"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:448
msgid ""
"Now we need to add the functions we've connected the signals to. Let's add "
"``popup_closed`` first."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:450
#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:465
msgid "Add the following to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:461
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:463
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:480
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:485
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:487
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:494
msgid ""
"Now instead of capturing/freeing the mouse, we check to see if 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:497
msgid ""
"Because the pop up makes the mouse mode ``MOUSE_MODE_VISIBLE`` whenever you "
"pause, we no longer have to worry about freeing the cursor in ``Player.gd``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:501
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:504
msgid "Starting the respawn system"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:506
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:508
msgid ""
"First, 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:521
msgid "``RESPAWN_TIME``: The amount of time (in seconds) it takes to respawn."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:522
msgid "``dead_time``: A variable to track how long the player has been dead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:523
msgid ""
"``is_dead``: A variable to track whether or not the player is currently dead."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:524
msgid "``globals``: A variable to hold the ``Globals.gd`` singleton."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:528
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:536
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:539
msgid "Don't worry, we will be adding ``get_respawn_position`` further below!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:543
msgid ""
"Next we need to make a few changes to ``physics_process``. Change "
"``physics_processing`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:561
msgid ""
"Now the player will not be processing input or movement input when the "
"player is dead. We are also now calling ``process_respawn``. We have not "
"made ``process_respawn`` yet, so let's change that."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:566
msgid "Let's add ``process_respawn``. Add the following to ``Player.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:625
msgid "Let's go through what this function is doing."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:629
msgid ""
"First we check to see if the player has just died by checking to see if "
"``health`` is equal or less than ``0`` and ``is_dead`` is ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:631
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:633
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 the player dies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:636
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:639
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:641
msgid ""
"If the player is holding an object when they died, we need to throw it. We "
"first check to see if 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:646
msgid ""
"Then we check to see if the player is dead. If the player is dead, we then "
"remove ``delta`` from ``dead_time``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:648
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:651
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:653
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:655
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:657
msgid ""
"We then enable both of the player's collision shapes so the player can "
"collide with the environment."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:659
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:661
msgid ""
"We then go through each weapon and call it's ``reset_weapon`` function, "
"which we will add soon."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:663
msgid ""
"Then we reset ``health`` to ``100``, ``grenade_amounts`` to it's 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:666
msgid "Finally, we set ``is_dead`` to ``false``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:670
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:677
msgid ""
"Now when the player is dead, the player cannot look around with the mouse."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:680
msgid "Finishing the respawn system"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:682
msgid ""
"First let's open ``Weapon_Pistol.gd`` and add the ``reset_weapon`` function. "
"Add the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:690
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:692
msgid "Now let's add ``reset_weapon`` in ``Weapon_Rifle.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:700
msgid "And add the following to ``Weapon_Knife.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:708
msgid "Now all of the weapons will reset when the player dies."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:712
msgid ""
"Now we need to add a few things to ``Globals.gd``. First, add the following "
"class variable:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:718
msgid ""
"``respawn_points``: A variable to hold all of the respawn points in a level"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:720
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:726
msgid ""
"``randomize`` will get us a new random seed so we get a (relatively) random "
"string of numbers when we using any of the random functions."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:728
msgid "Now let's add ``get_respawn_position`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:743
msgid ""
"First we check to see if ``Globals.gd`` has any ``respawn_points`` by "
"checking to see if ``respawn_points`` is ``null`` or not."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:745
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:747
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:750
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:754
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:760
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:765
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:776
msgid ""
"Now when a node with ``Respawn_Point_Setter.gd`` has it's ``_ready`` "
"function called, all of 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:780
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:785
msgid ""
"Now when the player dies, they will respawn after waiting ``4`` seconds!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:787
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:791
msgid "Writing a sound system we can use anywhere"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:793
msgid ""
"Finally, lets 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:795
msgid "First, open up ``SimpleAudioPlayer.gd`` and change it to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:838
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 a audio stream to be "
"passed in to ``play_sound``."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:842
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 check to 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:846
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:849
msgid "Let's go over the changes."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:853
msgid ""
"For the class variables we removed all of the ``audio_[insert name here]`` "
"variables since we will instead have these passed in."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:855
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:858
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:860
msgid ""
"``play_sound`` now expects a 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 a audio stream is 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:864
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:870
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:888
msgid "Lets go over these global variables."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:890
msgid ""
"``audio_clips``: A dictionary holding all of the audio clips ``Globals.gd`` "
"can play."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:891
msgid "``SIMPLE_AUDIO_PLAYER_SCENE``: The simple audio player scene."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:892
msgid ""
"``created_audio``: A list to hold all of the simple audio players ``Globals."
"gd`` has created"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:894
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:897
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:901
msgid "gun_revolver_pistol_shot_04,"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:902
msgid "gun_semi_auto_rifle_cock_02,"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:903
msgid "gun_submachine_auto_shot_00_automatic_preview_01"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:907
msgid ""
"Now we need to add a new function called ``play_sound`` to ``Globals.gd``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:926
msgid ""
"First we check to see if ``Globals.gd`` has a 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:928
msgid ""
"If ``Globals.gd`` has a 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:930
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:932
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:934
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:938
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 of the audio is "
"destroyed."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:940
msgid "Add the following to ``load_new_scene``:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:949
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 of the sounds in ``created_audio``, we clear "
"``created_audio`` so it no longer holds any references to any (noew freed/"
"destroyed) simple audio players."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:954
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:957
msgid "Now, change ``create_sound`` to the following:"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:964
msgid ""
"Now whenever ``create_sound`` is called, we simply call ``play_sound`` in "
"``Globals.gd``, passing in all of the arguments revived."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:968
msgid ""
"Now all of 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 to play the sound from."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:971
msgid ""
"For example, if you want to play an explosion sound when the grenades "
"explode 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 "
"of the bodies within its blast radius."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:981
msgid "Now you have a fully working single player FPS!"
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:983
msgid "At this point you have a good base to build more complicated FPS games."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:987
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:989
msgid ""
"The finished project source files contain the same exact 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:992
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:995
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:998
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:1000
msgid ""
"**Please note that the code in Github may or may not be in sync with the "
"tutorial on the documentation**."
msgstr ""

#: ../../docs/tutorials/3d/fps_tutorial/part_six.rst:1002
msgid ""
"The code in the documentation is likely better managed and/or more up to "
"date. If you are unsure on 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:1005
msgid ""
"You can download all of 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:1007
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:1012
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:1017
msgid ""
"The skybox was convert 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:1019
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:1021
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/audio/index.rst:2
msgid "Audio"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:4
#: ../../docs/tutorials/audio/audio_buses.rst:45
msgid "Audio Buses"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:9
msgid ""
"Beginning with Godot 3.0, the audio engine has been rewritten from scratch. "
"The aim now is to present an interface much friendlier to sound design "
"professionals. To achieve this, the audio engine contains a virtual rack "
"where unlimited audio buses can be created and, on each of it, unlimited "
"amount of effect processors can be added (or more like, as long as your CPU "
"holds up!)"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:16
msgid ""
"The implementation in Godot is pretty efficient and has been written "
"entirely from the ground up, without relying on any existing audio libraries."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:19
msgid ""
"Even the effect processors were written exclusively for Godot (save for the "
"pitch shifting library), with games in mind. This allows a efficient "
"tradeoff between performance and sound quality."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:23
msgid "See also: the :ref:`doc_audio-buses` tutorial."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:26
msgid "Decibel Scale"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:28
msgid ""
"The new audio engine works primarily using the decibel scale. We have chosen "
"this over linear representation of amplitude because it's more intuitive for "
"audio professionals."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:32
msgid "For those unfamiliar with it, it can be explained with a few facts:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:34
msgid ""
"The decibel (dB) scale is a relative scale. It represents the ratio of sound "
"power by using 10 times the base 10 logarithm of the ratio (10×log\\ :sub:"
"`10`\\ (P/P\\ :sub:`0`\\ ))."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:35
msgid ""
"For every 3dB, sound doubles or halves. 6dB represents a factor 4, 9dB a "
"factor 8, 10dB a factor 10, 20dB a factor 100, etc."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:36
msgid ""
"Since the scale is logarithmic, true zero (no audio) can't be represented."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:37
msgid ""
"0dB is considered the maximum audible volume without *clipping*. This limit "
"is not the human limit but a limit from the sound hardware. Your sound "
"output simply can't output any sound louder than 0dB without distorting it "
"(clipping it)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:38
msgid ""
"Because of the above, your sound mix should work in a way where the sound "
"output of the *Master Bus* (more on that later), should never be above 0dB."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:39
msgid ""
"Every 3dB below the 0dB limit, sound energy is *halved*. It means the sound "
"volume at -3dB is half as loud as 0dB. -6dB is half as loud as -3dB and so "
"on."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:40
msgid ""
"When working with decibels, sound is considered no longer audible between "
"-60dB and -80dB. This makes your working range generally between -60dB and "
"0dB."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:42
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:47
msgid "Audio buses can be found in the bottom panel of Godot Editor:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:51
msgid ""
"An *Audio Bus* bus (often called \"Audio Channels\" too) is a device where "
"audio is channeled. Audio data passes through it and can be *modified* and "
"*re-routed*. A VU-Meter (the bars that go up and down when sound is played) "
"can measure the loudness of the sound in Decibel scale."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:53
msgid ""
"The leftmost bus is the *Master Bus*. This bus outputs the mix to your "
"speakers so, as mentioned in the item above (Decibel Scale), make sure that "
"your mix rarely or never goes above 0dB in this bus. The rest of the audio "
"buses are used for *routing*. This means that, after modifying the sound, "
"they must send it to another bus to the left. Routing is always from right "
"to left without exception as this avoids creating infinite routing loops!"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:59
msgid "In the above image, *Bus 2* is routing its output to *Master* bus."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:62
msgid "Playback of Audio to a Bus"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:64
msgid ""
"To test playback to a bus, create an AudioStreamPlayer node, load an "
"AudioStream and select a target bus for playback:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:68
msgid "Finally toggle the \"playing\" property to on and sound will flow."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:70
msgid "You may also be interested in reading about :ref:`doc_audio-buses` now."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:73
msgid "Adding Effects"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:75
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:79
msgid "Following is a short description of available effects:"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:82
msgid "Amplify"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:84
msgid ""
"It's the most basic effect. It changes the sound volume. Amplifying too much "
"can make the sound clip, so be wary of that."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:87
msgid "BandLimit and BandPass"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:89
msgid ""
"These are resonant filters which block frequencies around the *Cutoff* "
"point. BandPass is resonant, while BandLimit stretches to the sides."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:92
msgid "Chorus"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:94
msgid ""
"This effect adds extra voices, detuned by LFO and with a small delay, to add "
"more richness to the sound harmonics and stereo width."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:97
msgid "Compressor"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:99
msgid ""
"The aim of a dynamic range compressor is to reduce the level of the sound "
"when the amplitude goes over a certain threshold in Decibels. One of the "
"main uses of a compressor is to increase the dynamic range while clipping "
"the least possible (when sound goes over 0dB)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:102
msgid ""
"Compressor has may uses in the mix, for example: * It can be used in the "
"Master bus to compress the whole output (Although a Limiter is probably "
"better) * It can be used in voice channels to ensure they sound as even as "
"possible. * It can be *Sidechained*. This means, it can reduce the sound "
"level using another audio bus for threshold detection. This technique is "
"very common in video game mixing to download the level of Music/SFX while "
"voices are being heard. * It can accentuate transients by using a bit wider "
"attack, meaning it can make sound effects sound more punchy."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:109
msgid ""
"There is a lot of bibliography written about compressors, and Godot "
"implementation is rather standard."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:112
msgid "Delay"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:114
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:117
msgid "Distortion"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:119
msgid ""
"Adds classical effects to modify the sound and make it dirty. Godot supports "
"effects like overdrive, tan, or bit crushing. For games, it can simulate "
"sound coming from some saturated device or speaker efficiently."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:123
msgid "EQ6, EQ10, EQ21"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:125
msgid ""
"Godot provides three model of equalizers with different band counts. "
"Equalizers are useful on the Master Bus to completely master a mix and give "
"it character. They are also useful when a game is run on a mobile device, to "
"adjust the mix to that kind of speakers (it can be added but disabled when "
"headphones are plugged)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:129
msgid "HighPassFilter, HighShelfFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:131
msgid ""
"These are filters that cut frequencies below a specific *Cutoff*. A common "
"use of high pass filters is to add it to effects (or voice) that were "
"recorded too close too a mic and need to sound more realistic. It is "
"commonly used for some types of environment like space."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:135
msgid "Limiter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:137
msgid ""
"A limiter is similar to a compressor, but it's less flexible and designed to "
"disallow sound going over a given dB threshold. Adding one in the *Master "
"Bus* is always recommended to reduce the effects of clipping."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:141
msgid "LowPassFilter, LowShelfFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:143
msgid ""
"These are the most common filters, they cut frequencies above a specific "
"*Cutoff* and can also resonate. They can be used for a wide amount of "
"effects, from underwater sound to simulating a sound coming from far away."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:147
msgid "NotchFilter"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:149
msgid ""
"The opposite to the BandPassFilter, it removes a band of sound from the "
"frequency spectrum at a given *Cutoff*."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:152
msgid "Panner"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:154
msgid "This is a simple helper to pan sound left or right."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:157
msgid "Phaser"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:159
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. It will be "
"sufficient to note that you can make a Darth Vader voice with it, or jet-"
"like sounds."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:163
msgid "PitchShift"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:165
msgid ""
"This effect allows for modulating pitch independently of tempo. All "
"frequencies can be increased/decreased with minimal effect on transients. "
"Can be used for effects such as voice modulation."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:168
msgid "Reverb"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:170
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 Areas (see :ref:`doc_audio-buses` tutorial, look for the "
"section on Areas), or to apply chamber feel to all sounds."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:174
msgid "StereoEnhance"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:176
msgid ""
"This effect has a few algorithms available to enhance the stereo spectrum, "
"in case this is needed."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:179
msgid "Automatic Bus Disabling"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:181
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 disable it (including all "
"effects)."
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:186
msgid "Bus Rearrangement"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:188
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. If a "
"bus is renamed, however, 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:192
msgid "Default Bus Layout"
msgstr ""

#: ../../docs/tutorials/audio/audio_buses.rst:194
msgid ""
"The default bus layout is automatically saved to the \"res://"
"default_bus_layout.res\" file. Other bus layouts can be saved/retrieved from "
"files in case of having to change snapshots, but in most cases this is not "
"necessary."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:4
msgid "Audio Streams"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:9
msgid ""
"As you might have read already in the :ref:`Audio Buses Tutorial<doc_audio-"
"buses>` , sound is sent to each bus via an AudioStreamPlayer."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:12
msgid ""
"There are many types of AudioStreamPlayers which will be explained in "
"detail. Each of it loads an AudioStream and plays it back."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:16
msgid "AudioStream"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:18
msgid ""
"An audio stream is an abstract object that emits sound. It can come from "
"many places, but most commonly from the filesystem. Audio files such as .wav "
"or .ogg can be loaded as AudioStreams and placed inside an AudioStreamPlayer."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:22
msgid ""
"When using these kind of files, you should choose which one is best for your "
"specific use case:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:24
msgid ""
"Audio files of type *.wav* are considerably big, but use little amount of "
"your CPU to play. Hundreds of them can be played simultaneously with little "
"impact to performance. This format is usually best for short sound effects, "
"as the importer will trim them and convert them to IMA-ADPCM."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:25
msgid ""
"Audio files of type *.ogg* are much smaller, but use considerably more "
"amount of CPU power to play back, so only a few can be played back "
"(especially on mobile!). This format is usually best for music or long sound "
"effect sequences. It also works well for voice at relatively low bitrates."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:27
msgid ""
"Keep in mind both .wav and .ogg generally don't contain looping information, "
"so this information must be set on the import options of each:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:31
msgid ""
"There are other types of AudioStreams, such as AudioStreamRandomPitch, which "
"takes an existing AudioStream and modulates the pitch every time it's played "
"back randomly (great for some sound effects), and more will keep appearing "
"in the future."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:35
msgid "AudioStreamPlayer"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:37
msgid ""
"This is the standard stream player, it can play to any given bus. In 5.1 "
"sound, it can send to stereo mix or front speakers."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:40
msgid "AudioStreamPlayer2D"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:42
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:44
msgid ""
"While it's possible to send these effects to specific audio buses, one of "
"the best strategies is to use an Area2D to divert sound to a specific bus. "
"This allows to create buses with different reverb or sound qualities and "
"make the emitter will automatically send to them when entering the Area2D "
"shapes."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:50
msgid "AudioStreamPlayer3D"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:52
msgid ""
"This is a variant of AudioStreamPlayer but emits sound in a 3D positional "
"environment. Depending on the location of the player relative of 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:55
msgid ""
"Similar to AudioStreamPlayer2D, an Area can divert the sound to an audio bus."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:59
msgid ""
"Unlike for 2D, the 3D version of AudioStreamPlayer has a few more advanced "
"options:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:62
msgid "Reverb Buses"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:64
msgid ""
"Godot allows 3D Audio Streams that enter a specific *Area* 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 *Area* properties:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:69
msgid ""
"At the same time, a special bus layout is created where each area receives "
"the reverb info from each area. Of course, an actual Reverb effect must be "
"created in that bus for anything to happen:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:73
msgid ""
"The Area Reverb Bus section has also a specific parameter named \"Uniformity"
"\". Some types of rooms bounce sounds more than others (like for example, a "
"typical warehouse), so reverberation can be heard almost uniformly across "
"the room even though the source is far away. Playing around with this "
"parameter can simulate that effect."
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:77
msgid "Doppler"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:79
msgid ""
"When the relative velocity between an emitter and listener changes, this is "
"perceived as an increase or decrease of the pitch shift. Godot can track "
"changes in velocities of *AudioStreamPlayer3D* or *Camera*. Both have this "
"property, which must be enabled manually:"
msgstr ""

#: ../../docs/tutorials/audio/audio_streams.rst:84
msgid ""
"Simply enable it by setting it depending on how objects will be moved "
"(whether on regular *process* or *physics_process* step) and the tracking "
"will happen automatically!"
msgstr ""

#: ../../docs/tutorials/physics/index.rst:2
msgid "Physics"
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:16
msgid "In this guide you will learn:"
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 from :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 sizing 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__physics_process>` callback, which is called before each physics "
"step at a constant frame rate (60 times per second by default)."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:90
msgid "Collision Layers and Masks"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:92
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:98
msgid "Let's look at each of the properties in turn:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:102
msgid "collision_layer"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:101
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:107
msgid "collision_mask"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:105
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:109
msgid ""
"These properties can be configured via code, or by editing them in the "
"Inspector."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:111
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:117
msgid "**Example:**"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:119
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:124
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:133
msgid "Area2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:135
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:140
msgid "There are three main uses for :ref:`Area2D <class_Area2D>`:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:142
msgid "Overriding physics parameters such as gravity in a given region."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:144
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:146
msgid "Checking other areas for overlap."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:148
msgid "By default, areas also receive mouse and touchscreen input."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:151
msgid "StaticBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:153
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:158
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:161
msgid "Example uses for ``StaticBody2D``:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:163
msgid "Platforms (including moving platforms)"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:164
msgid "Conveyor belts"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:165
msgid "Walls and other obstacles"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:168
msgid "RigidBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:170
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:176
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:179
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:183
msgid ""
"When a rigid body is at rest and hasn't moved for a time, 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:189
msgid "Rigid body modes"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:191
msgid "A rigid body can be set to one of four modes:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:193
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:194
msgid ""
"**Static** - The body behaves like a :ref:`StaticBody2D "
"<class_StaticBody2D>` and does not move."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:195
msgid "**Character** - Similar to \"Rigid\" mode, but the body can not rotate."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:196
msgid ""
"**Kinematic** - The body behaves like a :ref:`KinematicBody2D "
"<class_KinematicBody2D>` and must be moved by code."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:199
msgid "Using RigidBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:201
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:207
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__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:216
msgid "For example, here is the code for an \"Asteroids\" style spaceship:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:261
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:265
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_can_sleep>` property. Be aware that this "
"can have a negative effect on performance."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:272
msgid "Contact reporting"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:274
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_contacts_reported>` property to a non-zero value. The "
"contacts can then be obtained via :ref:`Physics2DDirectBodyState."
"get_contact_count() <class_Physics2DDirectBodyState_get_contact_count>` and "
"related functions."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:281
msgid ""
"Contact monitoring via signals can be enabled via the :ref:`contact_monitor "
"<class_RigidBody2D_contact_monitor>` property. See :ref:`RigidBody2D "
"<class_RigidBody2D>` for the list of available signals."
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:286
msgid "KinematicBody2D"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:288
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:293
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:300
msgid "Kinematic collision response"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:302
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:307
msgid ":ref:`move_and_collide <class_KinematicBody2D_move_and_collide>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:309
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:314
msgid ""
"For example, if you want to find the point in space where the collision "
"occurred:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:345
msgid "Or to bounce off of the colliding object:"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:374
msgid ":ref:`move_and_slide <class_KinematicBody2D_move_and_slide>`"
msgstr ""

#: ../../docs/tutorials/physics/physics_introduction.rst:376
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:382
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:386
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:451
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 "Rigid Body"
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 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 functions can not 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 function, 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 "Look at function"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:27
msgid ""
"As described above, using the Spatial node's ``look_at()`` function can't be "
"used each frame to follow a target. Here is a custom ``look_at()`` function "
"that will work reliably with rigid bodies:"
msgstr ""

#: ../../docs/tutorials/physics/rigid_body.rst:69
msgid ""
"This function 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 in "
"this mode the body's rotation is locked. In this case, you would have to "
"rotate the attached mesh node instead using the standard Spatial methods."
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 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:`KinematicBody2D <class_KinematicBody2D>` "
"node and show some examples of how it can be used."
msgstr ""

#: ../../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_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 to be controlled via "
"code. They 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 will 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 ""
"Kinematic body movement should only be done 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. This 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 "``floor_normal`` - *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 "
"to be 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 "``slope_stop_min_velocity`` - *default value:* ``5``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:82
msgid ""
"This is the minimum velocity when standing on a slope. This prevents a body "
"from sliding down a slope when standing still."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:85
msgid "``max_bounces`` - *default value:* ``4``"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:87
msgid ""
"This is the maximum number of collisions before the body stops moving. "
"Setting this too low may prevent movement entirely."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:90
msgid ""
"``floor_max_angle`` - *default value:* ``0.785398`` (in radians, equivalent "
"to ``45`` degrees)"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:92
msgid ""
"This is the maximum angle before a surface is no longer considered a \"floor"
"\"."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:95
msgid "Which movement method to use?"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:97
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:128
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:133
#: ../../docs/development/compiling/compiling_with_mono.rst:52
msgid "Examples"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:135
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:139
msgid "Movement and walls"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:141
msgid ""
"If you've downloaded the sample project, this example is in the "
"\"BasicMovement.tscn\" scene."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:143
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:149
msgid ""
"See :ref:`doc_2d_movement` for examples of implementing 2D movement schemes."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:151
msgid "Attach a script to the KinematicBody2D and add the following code:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:218
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:224
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:228
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:232
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:235
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:240
msgid "Bouncing/reflecting"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:242
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:246
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:249
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:336
msgid "And the code for the Bullet:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:398
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:402
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:405
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:412
msgid "Platformer movement"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:414
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:418
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:422
msgid "Here's the code for the player body:"
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:508
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 smoothly move up and "
"down slopes. Try removing ``velocity =`` and see what happens if you don't "
"do this."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:513
msgid ""
"Also note that we've added ``Vector2(0, -1)`` as the floor normal. This is a "
"vector pointing straight upward. This means that 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:517
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 (this can be adjusted by setting "
"``floor_max_angle``)."
msgstr ""

#: ../../docs/tutorials/physics/using_kinematic_body_2d.rst:522
msgid ""
"This 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_get_world_2d>`. For 3D, it's :ref:`Spatial.get_world()."
"space <class_Spatial_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__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_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 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 of a 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/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 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 seems. 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 alternative, 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 infinite inertial "
"tensor. Basically, it's a rigid body that can't rotate. Physics engines "
"always let objects 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 also 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 oldschool 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:82
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:88
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:95
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 affect the shape scale.**"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:102
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:105
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:111
msgid "Moving the Kinematic character"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:113
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_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:121
msgid "So, let's move our sprite downwards until it hits the floor:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:146
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:149
msgid ""
"The next step will be adding gravity to the mix, this way it behaves a "
"little more like an actual game character:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:185
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) is pixels/second."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:189
msgid "This adds simple walking support by pressing left and right:"
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:254
msgid "And give it a try."
msgstr ""

#: ../../docs/tutorials/physics/kinematic_character_2d.rst:256
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/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 for both types."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:80
msgid "Member access"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:82
msgid ""
"The individual components of the vector can be accessed directly by name."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:103
msgid "Adding vectors"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:105
msgid ""
"When adding or subtracting two vectors, the corresponding components are "
"added:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:116
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:121
msgid "Note that adding ``a + b`` gives the same result as ``b + a``."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:123
msgid "Scalar multiplication"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:125
msgid ""
"Vectors represent both direction and magnitude. A value representing only "
"magnitude is called a **scalar**."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:128
msgid "A vector can be multiplied by a **scalar**:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:143
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:147
msgid "Practical applications"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:149
msgid "Let's look at two common uses for vector addition and subtraction."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:151
msgid "Movement"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:153
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:161
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:164
msgid "Pointing toward a target"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:166
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:172
msgid "To find a vector pointing from ``A`` to ``B`` use ``B - A``."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:175
msgid "Unit vectors"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:177
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:182
msgid "Normalization"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:184
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:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:203
msgid ""
"Because this is such a common operation, ``Vector2`` and ``Vector3`` provide "
"a method for normalizing:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:216
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:221
msgid "Reflection"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:223
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:228
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:233
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:263
msgid "Dot product"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:265
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:270
msgid "The formula for dot product takes two common forms:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:282
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:296
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:302
msgid ""
"When using unit vectors, the result will always be between ``-1`` (180°) and "
"``1`` (0°)."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:306
msgid "Facing"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:308
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:314
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. 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:321
msgid "In code it would look like this:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:339
msgid "Cross product"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:341
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 null "
"vector."
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:352
msgid "The cross product is calculated like this:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:371
msgid "With Godot, you can use the built-in method:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:382
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:387
msgid "Calculating Normals"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:389
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:394
msgid "Here is a function to calculate a triangle's normal:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:418
msgid "Pointing to a Target"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:420
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:429
msgid "More Information"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:431
msgid ""
"For more information on using vector math in Godot, see the following "
"articles:"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:433
msgid ":ref:`doc_vectors_advanced`"
msgstr ""

#: ../../docs/tutorials/math/vector_math.rst:434
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:201
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:219
msgid ""
"Doing the same in 3D is a little more complex and will be explained further "
"down."
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:223
msgid "Some examples of planes"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:225
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:230
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:234
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:240
#: ../../docs/tutorials/math/vectors_advanced.rst:279
msgid "Code should be something like this:"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:265
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:270
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:370
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:377
msgid "Collision detection in 3D"
msgstr ""

#: ../../docs/tutorials/math/vectors_advanced.rst:379
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:385
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:389
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:393
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:398
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:404
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:410
msgid "So the final algorithm is something like:"
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, it is advised to read the previous one about :"
"ref:`doc_vector_math` as this one is a direct continuation."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:12
msgid ""
"This tutorial will be about *transformations* and will cover a little about "
"matrices (but not in-depth)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:15
msgid ""
"Transformations are most of the time applied as translation, rotation and "
"scale so they will be considered as priority here."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:19
msgid "Oriented coordinate system (OCS)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:21
msgid ""
"Imagine we have a spaceship somewhere in space. In Godot this is easy, just "
"move the ship somewhere and rotate it:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:26
msgid ""
"Ok, so in 2D this looks simple, a position and an angle for a rotation. But "
"remember, we are grown ups here and don't use angles (plus, angles are not "
"even that useful when working in 3D)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:30
msgid ""
"We should realize that at some point, someone *designed* this spaceship. Be "
"it for 2D in a drawing such as Paint.net, Gimp, Photoshop, etc. or in 3D "
"through a 3D DCC tool such as Blender, Max, Maya, etc."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:35
msgid ""
"When it was designed, it was not rotated. It was designed in its own "
"*coordinate system*."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:40
msgid ""
"This means that the tip of the ship has a coordinate, the fin has another, "
"etc. Be it in pixels (2D) or vertices (3D)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:43
msgid "So, let's recall again that the ship was somewhere in space:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:47
msgid ""
"How did it get there? What moved it and rotated it from the place it was "
"designed to its current position? The answer is... a **transform**, the ship "
"was *transformed* from their original position to the new one. This allows "
"the ship to be displayed where it is."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:52
msgid ""
"But transform is too generic of a term to describe this process. To solve "
"this puzzle, we will superimpose the ship's original design position at "
"their current position:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:58
msgid ""
"So, we can see that the \"design space\" has been transformed too. How can "
"we best represent this transformation? Let's use 3 vectors for this (in 2D), "
"a unit vector pointing towards X positive, a unit vector pointing towards Y "
"positive and a translation."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:65
msgid ""
"Let's call the 3 vectors \"X\", \"Y\" and \"Origin\", and let's also "
"superimpose them over the ship so it makes more sense:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:70
msgid ""
"Ok, this is nicer, but it still does not make sense. What do X,Y and Origin "
"have to do with how the ship got there?"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:73
msgid "Well, let's take the point from top tip of the ship as reference:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:77
msgid ""
"And let's apply the following operation to it (and to all the points in the "
"ship too, but we'll track the top tip as our reference point):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:89
msgid "Doing this to the selected point will move it back to the center:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:93
msgid ""
"This was expected, but then let's do something more interesting. Use the dot "
"product of X and the point, and add it to the dot product of Y and the point:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:106
msgid ""
"Then what we have is.. wait a minute, it's the ship in its design position!"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:111
msgid ""
"How did this black magic happen? The ship was lost in space, and now it's "
"back home!"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:114
msgid ""
"It might seem strange, but it does have plenty of logic. Remember, as we "
"have seen in the :ref:`doc_vector_math`, what happened is that the distance "
"to X axis, and the distance to Y axis were computed. Calculating distance in "
"a direction or plane was one of the uses for the dot product. This was "
"enough to obtain back the design coordinates for every point in the ship."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:121
msgid ""
"So, what we have been working with so far (with X, Y and Origin) is an "
"*Oriented Coordinate System*. X an Y are the **Basis**, and *Origin* is the "
"offset."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:128
msgid ""
"We know what the Origin is. It's where the 0,0 (origin) of the design "
"coordinate system ended up after being transformed to a new position. This "
"is why it's called *Origin*, But in practice, it's just an offset to the new "
"position."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:133
msgid ""
"The Basis is more interesting. The basis is the direction of X and Y in the "
"OCS from the new, transformed location. It tells what has changed, in either "
"2D or 3D. The Origin (offset) and Basis (direction) communicate \"Hey, the "
"original X and Y axes of your design are *right here*, pointing towards "
"*these directions*.\""
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:139
msgid ""
"So, let's change the representation of the basis. Instead of 2 vectors, "
"let's use a *matrix*."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:144
msgid ""
"The vectors are up there in the matrix, horizontally. The next problem now "
"is that.. what is this matrix thing? Well, we'll assume you've never heard "
"of a matrix."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:149
msgid "Transforms in Godot"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:151
msgid ""
"This tutorial will not explain matrix math (and their operations) in depth, "
"only its practical use. There is plenty of material for that, which should "
"be a lot simpler to understand after completing this tutorial. We'll just "
"explain how to use transforms."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:159
msgid ""
":ref:`class_Transform2D` is a 3x2 matrix. It has 3 Vector2 elements and it's "
"used for 2D. The \"X\" axis is the element 0, \"Y\" axis is the element 1 "
"and \"Origin\" is element 2. It's not divided in basis/origin for "
"convenience, due to its simplicity."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:179
msgid ""
"Most operations will be explained with this datatype (Transform2D), but the "
"same logic applies to 3D."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:183
msgid "Identity"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:185
msgid "An important transform is the \"identity\" matrix. This means:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:187
msgid "'X' Points right: Vector2(1,0)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:188
msgid "'Y' Points up (or down in pixels): Vector2(0,1)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:189
msgid "'Origin' is the origin Vector2(0,0)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:193
msgid ""
"It's easy to guess that an *identity* matrix is just a matrix that aligns "
"the transform to its parent coordinate system. It's an *OCS* that hasn't "
"been translated, rotated or scaled."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:220
msgid "Operations"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:225
msgid "Rotating Transform2D is done by using the \"rotated\" function:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:241
msgid "Translation"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:243
msgid ""
"There are two ways to translate a Transform2D, the first one is moving the "
"origin:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:263
msgid "This will always work in global coordinates."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:265
msgid ""
"If instead, translation is desired in *local* coordinates of the matrix "
"(towards where the *basis* is oriented), there is the :ref:`Transform2D."
"translated() <class_Transform2D_translated>` method:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:287
msgid ""
"You could also transform the global coordinates to local coordinates "
"manually:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:298
msgid ""
"But even better, there are helper functions for this as you can read in the "
"next sections."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:301
msgid "Local to global coordinates and vice versa"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:303
msgid ""
"There are helper methods for converting between local and global coordinates."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:305
msgid ""
"There are :ref:`Node2D.to_local() <class_Node2D_to_local>` and :ref:`Node2D."
"to_global() <class_Node2D_to_global>` for 2D as well as :ref:`Spatial."
"to_local() <class_Spatial_to_local>` and :ref:`Spatial.to_global() "
"<class_Spatial_to_global>` for 3D."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:311
msgid ""
"A matrix can be scaled too. Scaling will multiply the basis vectors by a "
"vector (X vector by x component of the scale, Y vector by y component of the "
"scale). It will leave the origin alone:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:330
msgid ""
"These kind of operations in matrices are accumulative. It means every one "
"starts relative to the previous one. For those who have been living on this "
"planet long enough, a good reference of how transform works is this:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:337
msgid ""
"A matrix is used similarly to a turtle. The turtle most likely had a matrix "
"inside (and you are likely learning this many years *after* discovering "
"Santa is not real)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:344
msgid ""
"Transform is the act of switching between coordinate systems. To convert a "
"position (either 2D or 3D) from \"designer\" coordinate system to the OCS, "
"the \"xform\" method is used."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:357
msgid "And only for basis (no translation):"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:369
msgid "Inverse transform"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:371
msgid ""
"To do the opposite operation (what we did up there with the rocket), the "
"\"xform_inv\" method is used:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:383
msgid "Only for Basis:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:395
msgid "Orthonormal matrices"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:397
msgid ""
"However, if the matrix has been scaled (vectors are not unit length), or the "
"basis vectors are not orthogonal (90°), the inverse transform will not work."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:401
msgid ""
"In other words, inverse transform is only valid in *orthonormal* matrices. "
"For this, these cases an affine inverse must be computed."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:404
msgid ""
"The transform, or inverse transform of an identity matrix will return the "
"position unchanged:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:419
msgid "Affine inverse"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:421
msgid ""
"The affine inverse is a matrix that does the inverse operation of another "
"matrix, no matter if the matrix has scale or the axis vectors are not "
"orthogonal. The affine inverse is calculated with the affine_inverse() "
"method:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:441
msgid "If the matrix is orthonormal, then:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:459
msgid "Matrix multiplication"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:461
msgid ""
"Matrices can be multiplied. Multiplication of two matrices \"chains"
"\" (concatenates) their transforms."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:464
msgid ""
"However, as per convention, multiplication takes place in reverse order."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:467
#: ../../docs/tutorials/io/background_loading.rst:268
#: ../../docs/tutorials/shading/shading_language.rst:107
#: ../../docs/tutorials/platform/services_for_ios.rst:183
#: ../../docs/tutorials/platform/services_for_ios.rst:230
msgid "Example:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:478
msgid "To make it a little clearer, this:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:491
msgid "Is the same as:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:504
msgid "However, this is not the same:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:517
msgid "Because in matrix math, A * B is not the same as B * A."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:520
msgid "Multiplication by inverse"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:522
msgid "Multiplying a matrix by its inverse, results in identity:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:536
msgid "Multiplication by identity"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:538
msgid "Multiplying a matrix by identity, will result in the unchanged matrix:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:552
msgid "Matrix tips"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:554
msgid ""
"When using a transform hierarchy, remember that matrix multiplication is "
"reversed! To obtain the global transform for a hierarchy, do:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:566
msgid "For 3 levels:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:577
msgid ""
"To make a matrix relative to the parent, use the affine inverse (or regular "
"inverse for orthonormal matrices)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:591
msgid "Revert it just like the example above:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:604
msgid ""
"OK, hopefully this should be enough! Let's complete the tutorial by moving "
"to 3D matrices."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:608
msgid "Matrices & transforms in 3D"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:610
msgid ""
"As mentioned before, for 3D, we deal with 3 :ref:`Vector3 <class_Vector3>` "
"vectors for the rotation matrix, and an extra one for the origin."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:616
msgid ""
"Godot has a special type for a 3x3 matrix, named :ref:`Basis <class_basis>`. "
"It can be used to represent a 3D rotation and scale. Sub vectors can be "
"accessed as:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:635
msgid "Or, alternatively as:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:652
msgid "The Identity Basis has the following values:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:656
msgid "And can be accessed like this:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:682
msgid "Rotation in 3D"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:684
msgid ""
"Rotation in 3D is more complex than in 2D (translation and scale are the "
"same), because rotation is an implicit 2D operation. To rotate in 3D, an "
"*axis*, must be picked. Rotation, then, happens around this axis."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:688
msgid ""
"The axis for the rotation must be a *normal vector*. As in, a vector that "
"can point to any direction, but length must be one (1.0)."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:707
msgid ""
"To add the final component to the mix, Godot provides the :ref:`Transform "
"<class_Transform>` type. Transform has two members:"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:710
msgid "*basis* (of type :ref:`Basis <class_Basis>`)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:711
msgid "*origin* (of type :ref:`Vector3 <class_Vector3>`)"
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:713
msgid ""
"Any 3D transform can be represented with Transform, and the separation of "
"basis and origin makes it easier to work translation and rotation separately."
msgstr ""

#: ../../docs/tutorials/math/matrices_and_transforms.rst:717
msgid "An example:"
msgstr ""

#: ../../docs/tutorials/animation/index.rst:2
#: ../../docs/tutorials/animation/cutout_animation.rst:279
#: ../../docs/development/file_formats/tscn.rst:365
msgid "Animation"
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 you find in the Inspector. Animations are "
"changes to properties over time. This means you can animate anything visual "
"in nature: sprites, UI elements, particles, the visibility, and color of "
"textures. But not only. You can also control gameplay related values and "
"call any function."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:26
msgid "Create an AnimationPlayer node"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:28
msgid ""
"To use the animation tools we first have to create an :ref:"
"`class_AnimationPlayer` node."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:31
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:38
msgid "The AnimationPlayer node"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:40
msgid ""
"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:46
msgid "The animation panel position"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:48
msgid "It consists of five parts:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:53
msgid "The animation panel"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:55
msgid "Animation controls (i.e. add, load, save, and delete animations)"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:56
msgid "The tracks listing"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:57
msgid "The timeline with keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:58
msgid "The keyframe editor (when enabled)"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:59
msgid ""
"The timeline and track controls, where you can zoom the timeline and edit "
"tracks for example."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:62
msgid ""
"See the `animation panel reference <#animation-panel-reference>`__ below for "
"details."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:66
msgid "Computer animation relies on keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:68
msgid "A keyframe defines the value of a property at a certain point in time."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:70
msgid "White and blue diamond shapes represent keyframes in the timeline."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:75
msgid "Keyframes in Godot"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:77
msgid ""
"The engine interpolates values between keyframes, resulting in a gradual "
"change in values over time."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:83
msgid "Two keyframes are all it takes to obtain a smooth motion"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:85
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:91
msgid "The timeline in the animation panel"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:93
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:100
msgid "Example of Normal animation tracks"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:104
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| (Default shortcut: Shift"
"+D) to see the changes instantly."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:110
msgid "Tutorial: Creating a simple animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:115
msgid ""
"For this tutorial, we'll going to create an AnimationPlayer node and a "
"sprite node as an AnimationPlayer node child."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:121
msgid "Our scene setup"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:123
msgid ""
"The sprite holds an image texture and we animate that sprite to move between "
"two points on the screen. As a starting point, move the sprite to a left "
"position on the screen."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:129
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:133
msgid ""
"Select the AnimationPlayer node and click on \"Add animation\" (|Add "
"Animation|) in the animation tab to add a new animation."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:136
msgid "Enter a name for the animation in the dialog box."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:141
msgid "Add a new animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:144
msgid "Adding a track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:146
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:152
msgid "Convenience buttons"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:154
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:157
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:160
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 on \"Create\"."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:164
msgid ""
"This creates a new track and our first keyframe at the beginning of the "
"timeline:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:170
msgid "The sprite track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:172
msgid ""
"The track name consists of a Node Path, followed by a colon, followed by a "
"reference to its property, that we would like to modify."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:175
msgid ""
"In our example, the path is ``AnimationPlayer/Sprite`` and the property is "
"``position``."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:178
msgid ""
"The path always starts at the AnimationPlayer node's parent (so paths always "
"have to include the AnimationPlayer node itself)."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:183
msgid ""
"Don't worry if you change the names of nodes in the Scene Tree, that you "
"already have tracks for. Godot automatically updates the paths in the tracks."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:188
msgid "The second keyframe"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:190
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:193
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:200
msgid "Animation length"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:202
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:205
msgid ""
"Again, click the key button in the toolbar. This creates our second keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:209
msgid "Run the animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:211
msgid "Click on the \"Play from beginning\" (|Play from beginning|) button."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:213
msgid "Yay! Our animation runs:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:218
msgid "The animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:221
msgid "Back and forth"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:223
msgid ""
"As you can see, the \"loop\" button is enabled by default and our animation "
"loops. 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:232
msgid "Animation loop"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:234
msgid ""
"If you set the animation length to 4 seconds now, the animation moves back "
"and forth. You can change this behaviour if you change the track's loop "
"mode. This is covered in the next chapter."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:239
#: ../../docs/tutorials/animation/introduction_2d.rst:247
msgid "Track settings"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:241
msgid ""
"Each track has a settings panel at the end, where you can set the update "
"rate, the track interpolation, and the loop mode."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:249
msgid ""
"The update rate of a track tells Godot when to update the property values. "
"This can be:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:252
msgid "Continuous: Update the property on each frame"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:253
msgid "Discrete: Only update the property on keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:254
msgid "Trigger: Only update the property on keyframes or triggers"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:259
msgid "Track rate"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:261
msgid ""
"In normal animations, you usually use \"Continuous\". The other types are "
"used to script complex animations."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:264
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:267
msgid "Nearest: Set the nearest keyframe value"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:268
msgid ""
"Linear: Set the value based on a linear function calculation between the two "
"keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:270
msgid ""
"Cubic: Set the value based on a cubic function calculation between the two "
"keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:276
msgid "Track interpolation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:278
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:283
msgid ""
"Godot supports two loop modes, which affect the animation if it's set to "
"loop:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:289
msgid "Loop modes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:291
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:294
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:299
#: ../../docs/tutorials/animation/introduction_2d.rst:312
msgid "Keyframes for other properties"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:301
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:304
msgid ""
"If you select your sprite while the animation panel is visible, you get a "
"small keyframe button for all of 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:315
msgid "Edit keyframes"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:317
msgid ""
"For advanced use and to edit keyframe in detail, enable the keyframe editor "
"(|Keyframe editor|)."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:320
msgid ""
"This adds an editor pane on the right side of the track settings. When you "
"select a keyframe, you can directly edit its values in this editor:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:326
msgid "Keyframe editor editing a key"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:328
msgid "Additionally, you can also edit the transition value for this keyframe:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:333
msgid "Keyframe editor editing a transition"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:335
msgid ""
"This tells Godot, how to change the property values when it reaches this "
"keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:338
msgid ""
"You usually tweak your animations this way, when the movement doesn't \"look "
"right\"."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:342
msgid "Advanced: Call Func tracks"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:344
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 "
"functions."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:350
msgid ""
"For example, the :ref:`class_AudioStreamPlayer` node type has a function to "
"play an audio stream."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:353
msgid ""
"Wouldn't it be great to play a stream at a specific keyframe in an "
"animation? This is where \"Call Func 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 function, that Godot "
"should call when it reaches this keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:359
msgid ""
"To let Godot play a sample when it reaches a keyframe, follow this list:"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:361
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:367
msgid "Add AudioStreamPlayer"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:369
msgid ""
"Click on \"Add track\" (|Add track|) on the animation panel's track controls."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:372
msgid "Select \"Add Call Func Track\" from the list of possible track types."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:377
msgid "Add Call Func Track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:379
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:385
msgid "Select AudioStreamPlayer"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:387
msgid ""
"Select the timeline position, where Godot should play the sample by clicking "
"on the timeline header."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:390
msgid "Enable the Keyframe Editor by clicking on |Keyframe editor|."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:392
msgid ""
"Click on \"Add keyframe\" near the settings of our func track (|Add "
"keyframe|) and select the keyframe."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:398
msgid "Add a keyframe to the call func track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:400
msgid "Enter \"play\" as the function name."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:405
msgid "Keyframe settings of a call func track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:407
msgid ""
"When Godot reaches the keyframe, Godot calls the :ref:"
"`class_AnimationPlayer` node's \"play\" function and the stream plays."
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:412
#: ../../docs/development/cpp/object_class.rst:233
msgid "References"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:415
msgid "Animation panel reference"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:420
msgid "The animation panel reference"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:422
msgid "The animation panel has the following parts (from left to right):"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:425
#: ../../docs/tutorials/animation/introduction_2d.rst:430
msgid "Animation controls"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:432
msgid "Play animation backwards from current position"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:433
msgid "Play animation backwards from the animation end"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:434
msgid "Stop animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:435
msgid "Play animation forwards from the animation beginning"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:436
msgid "Play animation forwards from the current position"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:437
msgid "Direct time selection"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:440
#: ../../docs/tutorials/animation/introduction_2d.rst:445
msgid "Animation management"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:447
msgid "Create a new animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:448
msgid "Load animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:449
msgid "Save animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:450
msgid "Duplicate animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:451
msgid "Rename animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:452
msgid "Delete animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:453
msgid "Animation selection"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:454
msgid "Automatically play selected animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:455
msgid "Edit animation blend times"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:456
msgid "Extended animation Tools"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:459
msgid "Timeline zoom level control"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:464
msgid "Timeline zoom level contro"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:467
#: ../../docs/tutorials/animation/introduction_2d.rst:472
msgid "Timeline control"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:474
msgid "Length of animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:475
msgid "Steps of animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:476
msgid "Toggle loop animation"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:479
#: ../../docs/tutorials/animation/introduction_2d.rst:484
msgid "Track control"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:486
msgid "Add track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:487
msgid "Move track up"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:488
msgid "Move track down"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:489
msgid "Delete track"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:490
msgid "Extended track tools"
msgstr ""

#: ../../docs/tutorials/animation/introduction_2d.rst:491
msgid "Toggle keyframe editor"
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 ""
"Cut-out is a technique of animating in 2D where pieces of paper (or similar "
"material) are cut in special shapes and laid one over the other. The papers "
"are animated and photographed, frame by frame using a stop motion technique "
"(more info `here <https://en.wikipedia.org/wiki/Cutout_animation>`__)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:15
msgid ""
"With the advent of the digital age, this technique became possible using "
"computers, which resulted in an increased amount of animation TV shows using "
"digital Cut-out. Notable examples are `South Park <https://en.wikipedia.org/"
"wiki/South_Park>`__ or `Jake and the Never Land Pirates <https://en."
"wikipedia.org/wiki/Jake_and_the_Never_Land_Pirates>`__ ."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:23
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:29
msgid "Cutout in Godot"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:31
msgid ""
"Godot provides a few tools for working with these kind of assets, but its "
"overall design makes it ideal for the workflow. The reason is that, unlike "
"other tools meant for this, Godot has the following advantages:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:35
msgid ""
"**The animation system is fully integrated with the engine**: This means, "
"animations can control much more than just motion of objects, such as "
"textures, sprite sizes, pivots, opacity, color modulation, etc. Everything "
"can be animated and blended."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:39
msgid ""
"**Mix with Traditional**: AnimatedSprite allows traditional animation to be "
"mixed, useful for complex objects, such as shape of hands and foot, changing "
"facial expression, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:42
msgid ""
"**Custom Shaped Elements**: Can be created with :ref:`Polygon2D "
"<class_Polygon2D>` allowing the mixing of UV animation, deformations, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:45
msgid ""
"**Particle Systems**: Can also be mixed with the traditional animation "
"hierarchy, useful for magic effects, jetpacks, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:47
msgid ""
"**Custom Colliders**: Set colliders and influence areas in different parts "
"of the skeletons, great for bosses, fighting games, etc."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:49
msgid ""
"**Animation Tree**: Allows complex combinations and blendings of several "
"animations, the same way it works in 3D."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:52
#: ../../docs/tutorials/shading/shader_materials.rst:24
msgid "And much more!"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:55
msgid "Making of GBot!"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:57
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:63
msgid ""
"Get your assets: :download:`gbot_resources.zip <files/gbot_resources.zip>`."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:66
msgid "Setting up the rig"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:68
msgid "Create an empty Node2D as root of the scene, we will work under it:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:72
msgid ""
"OK, the first node of the model that we will create will be 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:78
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, later accommodate it properly:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:83
msgid ""
"This looks good. Let's see if our hierarchy works as a skeleton by rotating "
"the torso. We can do this be pressing ``E`` to enter rotate mode, and "
"dragging with the left mouse button. To exit rotate mode hit ``ESC``."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:89
msgid ""
"Ouch, that doesn't look good! The rotation pivot is wrong, this means it "
"needs to be adjusted."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:92
msgid ""
"This small little cross in the middle of the :ref:`Sprite <class_Sprite>` is "
"the rotation pivot:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:99
msgid "Adjusting the pivot"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:101
msgid ""
"The pivot can be adjusted by changing the *offset* property in the Sprite:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:106
msgid ""
"However, there is a way to do it more *visually*. While hovering over the "
"desired pivot point, simply press the \"v\" key to move the pivot there for "
"the selected Sprite. Alternately, there is a tool in the tool bar that has a "
"similar function."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:113
msgid ""
"Now it looks good! Let's continue adding body pieces, starting by the right "
"arm. Make sure to put the sprites in hierarchy, so their rotations and "
"translations are relative to the parent:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:119
msgid ""
"This seems easy, so continue with the left arm. The rest should be simple! "
"Or maybe not:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:124
msgid ""
"Right. In 2D, parent nodes appear below children nodes. Well, this sucks. "
"But how can this problem be solved? We want the left arm to appear behind "
"the hip and the torso. For this, we can move the nodes behind the hip (note "
"that you can bypass this by setting the Node2D Z property, but then you "
"won't learn about all this!):"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:132
msgid ""
"But then, we lose the hierarchy layout, which allows to control the skeleton "
"like.. a skeleton. Is there any hope?.. Of Course!"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:136
msgid "RemoteTransform2D node"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:138
msgid ""
"Godot provides a special node, :ref:`RemoteTransform2D "
"<class_RemoteTransform2D>`. This node will transform nodes that are sitting "
"somewhere else in the hierarchy, by applying the transform to the remote "
"nodes."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:142
msgid "This enables to have a visibility order independent from the hierarchy."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:145
msgid ""
"Simply create two more nodes as children from torso, remote_arm_l and "
"remote_hand_l and link them to the actual sprites:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:150
msgid ""
"Moving the remote transform nodes will move the sprites, allowing you to "
"easily animate and pose the character:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:156
msgid "Completing the skeleton"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:158
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:163
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:166
msgid ""
"For simple objects and rigs this is fine, however the following problems are "
"common:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:169
msgid ""
"Selecting sprites can become difficult for complex rigs, and the scene tree "
"ends being used due to the difficulty of clicking over the proper sprite."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:172
msgid "Inverse Kinematics is often desired for extremities."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:174
msgid "To solve these problems, Godot supports a simple method of skeletons."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:177
msgid "Skeletons"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:179
msgid ""
"Godot doesn't actually support *true* Skeketons, but it does feature a "
"helper to create \"bones\" between nodes. This is enough for most cases, but "
"the way it works is not completely obvious."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:185
msgid ""
"As an example, let's turn the right arm into a skeleton. To create "
"skeletons, a chain of nodes must be selected from top to bottom:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:190
msgid "Then, click on the Skeleton menu and select ``Make Bones``."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:194
msgid ""
"This will add bones covering the arm, but the result is not quite what is "
"expected."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:199
msgid ""
"It looks like the bones are shifted up in the hierarchy. The hand connects "
"to the arm, and the arm to the body. So the question is:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:202
msgid "Why does the hand lack a bone?"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:203
msgid "Why does the arm connect to the body?"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:205
msgid ""
"This might seem strange at first, but will make sense later on. In "
"traditional skeleton systems, bones have a position, an orientation and a "
"length. In Godot, bones are mostly helpers so they connect the current node "
"with the parent. Because of this, **toggling a node as a bone will just "
"connect it to the parent**."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:211
msgid ""
"So, with this knowledge. Let's do the same again so we have an actual, "
"useful skeleton."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:214
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:221
msgid ""
"Now select the whole chain, from the endpoint to the arm and create bones:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:226
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:229
msgid ""
"Finally, create endpoints in all meaningful extremities and connect the "
"whole skeleton with bones up to the hip."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:232
msgid ""
"You may notice when connecting the hip and torso, that an extra bone is "
"created. To fix this, select the root and hip node, open the Skeleton menu, "
"click ``clear bones``."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:238
msgid "After fixing that your final skeleton should look something like this:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:242
msgid ""
"Finally! the whole skeleton is rigged! On close look, it is noticeable that "
"there is a second set of endpoints in the hands. This will make sense soon."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:246
msgid ""
"Now that a whole skeleton 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:250
msgid "IK chains"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:252
msgid ""
"IK chains are a powerful animation tool. 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. This would be quite complex and lead to imprecise results."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:254
msgid "What if we could move the foot and let the rest of the leg self-adjust?"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:256
msgid "This type of posing is called IK (Inverse Kinematic)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:258
msgid ""
"To create an IK chain, simply 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:264
msgid "Then enable this chain for IK. Go to Edit > Make IK Chain."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:268
msgid "As a result, the base of the chain will turn *Yellow*."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:272
msgid ""
"Once the IK chain is set-up, simply grab any of the bones in the extremity, "
"any child or grand-child of the base of the chain and try to grab it and "
"move it. Result will be pleasant, satisfaction warranted!"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:281
msgid ""
"The following section will be a collection of tips for creating animation "
"for your rigs. If unsure about how the animation system in Godot works, "
"refresh it by checking again the :ref:`doc_animations`."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:286
msgid "2D animation"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:288
msgid ""
"When doing animation in 2D, a helper will be present in the top menu. This "
"helper only appears when the animation editor window is opened:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:293
msgid ""
"The key button will insert location/rotation/scale keyframes to the selected "
"objects or bones. This depends on the mask enabled. Green items will insert "
"keys while red ones will not, so modify the key insertion mask to your "
"preference."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:299
msgid "Rest pose"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:301
msgid ""
"These kind of rigs do not have a \"rest\" pose, so it's recommended to "
"create a reference rest pose in one of the animations."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:304
msgid "Simply do the following steps:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:306
msgid "Make sure the rig is in \"rest\" (not doing any specific pose)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:308
msgid "Create a new animation, rename it to \"rest\"."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:310
msgid "Select all nodes (box selection should work fine)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:312
msgid "Select \"loc\" and \"rot\" on the top menu."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:314
msgid ""
"Push the key button. Keys will be inserted for everything, creating a "
"default pose."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:322
msgid ""
"Animating these models means only modifying the rotation of the nodes. "
"Location and scale are rarely used, with the only exception of moving the "
"entire rig from the hip (which is the root node)."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:326
msgid ""
"As a result, when inserting keys, only the \"rot\" button needs to be "
"pressed most of the time:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:331
msgid ""
"This will avoid the creation of extra animation tracks for the position that "
"will remain unused."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:335
msgid "Keyframing IK"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:337
msgid ""
"When editing IK chains, it is not necessary to select the whole chain to add "
"keyframes. Selecting the endpoint of the chain and inserting a keyframe will "
"automatically insert keyframes until the chain base too. This makes the task "
"of animating extremities much simpler."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:343
msgid "Moving sprites above and behind others."
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:345
msgid ""
"RemoteTransform2D works in most cases, but sometimes it is necessary to have "
"a node above and below others during an animation. To aid on this the "
"\"Behind Parent\" property exists on any Node2D:"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:352
msgid "Batch setting transition curves"
msgstr ""

#: ../../docs/tutorials/animation/cutout_animation.rst:354
msgid ""
"When creating complex animations and inserting many keyframes, editing the "
"individual keyframe curves for each can become an endless task. For this, "
"the Animation Editor has a small menu where changing animation curves is "
"easy. First select the appropriate keys. Next click on the pencil icon in "
"the bottom right of the animation panel, this will open the transition "
"editor. Now click on one of the curve options most appropriate for your "
"animation."
msgstr ""

#: ../../docs/tutorials/inputs/index.rst:2
msgid "Inputs"
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 setup 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__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_set_process_input>`). If any function consumes the event, it can "
"call :ref:`SceneTree.set_input_as_handled() "
"<class_SceneTree_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__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__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_accept_event>` and the event will not spread any more. Events "
"that are not consumed will propagate  **up**, to :ref:`Control "
"<class_Control>`'s ancestors. Use :ref:`Control.mouse_filter "
"<class_Control_mouse_filter>` property to control whether a :ref:`Control "
"<class_Control>` is notified of mouse events via :ref:`Control._gui_input() "
"<class_Control__gui_input>` callback, and whether these events are "
"propagated further."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:93
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_set_process_unhandled_input>`). If "
"any function consumes the event, it can call :ref:`SceneTree."
"set_input_as_handled() <class_SceneTree_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:98
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__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:104
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:108
msgid "Anatomy of an InputEvent"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:110
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:114
msgid ""
"There are several specialised types of InputEvent, described in the table "
"below:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:117
msgid "Event"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:117
msgid "Type Index"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:119
msgid ":ref:`InputEvent <class_InputEvent>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:119
msgid "NONE"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:119
msgid "Empty Input Event."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:121
msgid ":ref:`InputEventKey <class_InputEventKey>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:121
msgid "KEY"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:121
msgid "Contains a scancode and unicode value, as well as modifiers."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:124
msgid ":ref:`InputEventMouseButton <class_InputEventMouseButton>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:124
msgid "MOUSE_BUTTON"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:124
msgid "Contains click information, such as button, modifiers, etc."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:127
msgid ":ref:`InputEventMouseMotion <class_InputEventMouseMotion>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:127
msgid "MOUSE_MOTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:127
msgid ""
"Contains motion information, such as relative, absolute positions and speed."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:130
msgid ":ref:`InputEventJoypadMotion <class_InputEventJoypadMotion>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:130
msgid "JOYSTICK_MOTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:130
msgid "Contains Joystick/Joypad analog axis information."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:133
msgid ":ref:`InputEventJoypadButton <class_InputEventJoypadButton>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:133
msgid "JOYSTICK_BUTTON"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:133
msgid "Contains Joystick/Joypad button information."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:136
msgid ":ref:`InputEventScreenTouch <class_InputEventScreenTouch>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:136
msgid "SCREEN_TOUCH"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:136
msgid ""
"Contains multi-touch press/release information. (only available on mobile "
"devices)"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid ":ref:`InputEventScreenDrag <class_InputEventScreenDrag>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid "SCREEN_DRAG"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:140
msgid ""
"Contains multi-touch drag information. (only available on mobile devices)"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
msgid ":ref:`InputEventAction <class_InputEventAction>`"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
msgid "SCREEN_ACTION"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:143
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:149
msgid "Actions"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:151
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:155
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:157
msgid "Input to be reconfigured at run-time."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:159
msgid ""
"Actions can be created from the Project Settings menu in the Actions tab."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:162
msgid ""
"Any event has the methods :ref:`InputEvent.is_action() "
"<class_InputEvent_is_action>`, :ref:`InputEvent.is_pressed() "
"<class_InputEvent_is_pressed>` and :ref:`InputEvent <class_InputEvent>`."
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:165
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_parse_input_event>`. You would normally use it like this:"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:189
msgid "InputMap"
msgstr ""

#: ../../docs/tutorials/inputs/inputevent.rst:191
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/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. Yet, 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/custom_mouse_cursor.rst:4
msgid "Customizing 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:14
msgid "Using project settings"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:9
#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:26
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:16
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:20
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:23
msgid "The custom image **must** be less than 256x256."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:28
msgid "Create a Node and attach the following script."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:64
msgid ""
"Check :ref:`Input.set_custom_mouse_cursor() "
"<class_Input_set_custom_mouse_cursor>`."
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:68
msgid "Demo project"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:70
msgid ""
"Find out more by studying this demo project: https://github.com/"
"guilhermefelipecgs/custom_hardware_cursor"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:74
msgid "Cursor list"
msgstr ""

#: ../../docs/tutorials/inputs/custom_mouse_cursor.rst:76
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 while the resource is being loaded, so "
"it's not good. This document discusses 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/community/contributing/updating_the_class_reference.rst:227
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 demostrates 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 setup 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 can show a progress "
"bar or loading screen, etc."
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 load 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
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 it while you call ``poll`` on the loader. When a resource "
"is finished 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 parameter \"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 done loading and ready to be retrieved."
msgstr ""

#: ../../docs/tutorials/io/background_loading.rst:252
msgid ""
"Get the progress of a resource. Returns -1 on error (for example if the "
"resource is not on 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 "
"done loading (``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. Ask punto on IRC (#godotengine on irc.freenode.net) for help."
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 everywhere, 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 before. Godot considers that a project exists at any given "
"folder that contains an \"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://sometexture.png``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:27
msgid "Userdata 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://gamesave.txt``."
msgstr ""

#: ../../docs/tutorials/io/data_paths.rst:36
msgid ""
"In some devices (for example, mobile ad consoles) this path is unique for "
"the app. Under desktop operating systems, the engine uses the typical ``~/."
"local/share/godot/app_userdata/Name`` (check the project name under the "
"settings) in macOS and Linux, and ``APPDATA/Name`` for Windows."
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. It can be desired to store more information "
"than the current level or number of stars earned on a level. More advanced "
"save games may need to store 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:16
msgid "Identify persistent objects"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:18
msgid ""
"First 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:23
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 the "
"GUI or through script. Let's add the relevant nodes using the GUI:"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:29
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:49
msgid "Serializing"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:51
msgid ""
"The next step is to serialize the data. This makes it much easier to read "
"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_to_json>` and :ref:"
"`parse_json() <class_@GDScript_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:114
msgid ""
"This gives us a dictionary with the style ``{ \"variable_name\":"
"that_variables_value }`` which will be useful when loading."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:119
msgid "Saving and reading data"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:121
msgid ""
"As covered in the :ref:`doc_filesystem` tutorial, we'll need to open a file "
"and write to it and then later read from it. Now that we have a way to call "
"our groups and get their relevant data, let's use 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:162
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:242
msgid ""
"And 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:247
msgid "Some notes"
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:249
msgid ""
"We may have glossed over a step, but setting the game state to one fit to "
"start loading data can be complicated. This step will need to be heavily "
"customized based on the needs of an individual project."
msgstr ""

#: ../../docs/tutorials/io/saving_games.rst:253
msgid ""
"This implementation assumes no Persist objects are children of other Persist "
"objects. Doing so would create invalid paths. If this is one of the needs of "
"a project this needs to be considered. Saving objects in stages (parent "
"objects first) so they are available when child objects are loaded will make "
"sure they're available for the add_child() call. There will also need to be "
"some way to link children to parents as the 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:9
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 "
"every day 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 produce them a 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:22
msgid ""
"But, imagine if someone was to find a way to edit the saved games and assign "
"the items and currency without effort? This would be terrible, because it "
"would help players consume the content much faster, and as such run out of "
"it sooner than expected. If this 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:29
msgid ""
"No, we definitely do not want this to happen, so let's see how to encrypt "
"savegames and protect the world order."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:33
msgid "How?"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:35
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:55
msgid ""
"This will make the file unreadable to users, but will still not prevent them "
"sharing save files. To solve this, use the device unique id or some unique "
"user identifier, for example:"
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:74
msgid "Note that ``OS.get_unique_id()`` only works on iOS and Android."
msgstr ""

#: ../../docs/tutorials/io/encrypting_save_games.rst:76
msgid "This is all! Thanks for your cooperation, citizen."
msgstr ""

#: ../../docs/tutorials/i18n/index.rst:2
msgid "Internationalization"
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. Unfortunately for us "
"developers, that is not the case. While not generally a big requirement when "
"developing indie or niche games, it is also common that games going into a "
"more massive market require localization."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:14
msgid ""
"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 would be using the offical demo as an example, you can download it in the "
"AssetLib: https://godotengine.org/asset-library/asset/134 or find it in the "
"demo_projects/gui/translation"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:28
msgid "Configuring the imported translation"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:30
msgid ""
"The 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:36
msgid "This dialog allows to add or remove translations project-wide."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:39
msgid "Localizing resources"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:41
msgid ""
"It is also possible to instruct Godot to open alternative versions of assets "
"(resources) depending on the current language. For this the \"Remaps\" tab "
"exists:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:47
msgid ""
"Select the resource to be remapped, and the alternatives for each locale."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:51
msgid "Converting keys to text"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:53
msgid ""
"Some controls such as :ref:`Button <class_Button>`, :ref:`Label "
"<class_Label>`, etc. will automatically fetch a translation each time they "
"are set a key instead of a text. For example, if a label is assigned "
"\"MAIN_SCREEN_GREETING1\" and a key to different languages exists in the "
"translations, this will be automatically converted."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:59
msgid ""
"For code, the :ref:`Object.tr() <class_Object_tr>` function can be used. "
"This will just look-up the text into 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 having "
"dynamically adjusted control sizes may help. :ref:`Container "
"<class_Container>` can be useful, as well as the multiple options in :ref:"
"`Label <class_Label>` for text wrapping."
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:78
msgid "TranslationServer"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:80
msgid ""
"Godot has a server for handling the low level translation management called "
"the :ref:`TranslationServer <class_TranslationServer>`. Translations can be "
"added or removed during run-time, and the current language be changed too."
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 command line. For example, to "
"test a game in french, the following arguments 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 "
"dialog and append the locale identifier to it. For example:"
msgstr ""

#: ../../docs/tutorials/i18n/internationalizing_games.rst:106
msgid ""
"As always, If you don't know the code of a language or zone, :ref:`check the "
"list <doc_locales>`."
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 "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/index.rst:2
msgid "GUI"
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 an 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 kind of interfaces 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 user interface uses these kind of controls 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 "
"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 to:"
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 grand children 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_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 overrideable, 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 see 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. Following "
"to this, save it (to, as example, mytheme.thm):"
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 ""
"Take some assets (:download:`skin_assets.zip <files/skin_assets.zip>`), go "
"to the \"theme\" menu and select \"Add Class Item\":"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:142
msgid ""
"A menu will appear prompting the type of control to create. Select \"Button"
"\":"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:147
msgid ""
"Immediately, all button theme options will appear in the property editor, "
"where they can be edited:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:152
msgid ""
"Select the \"normal\" stylebox 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:159
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:166
msgid ""
"Save this theme to the .thm file. Go to the 2D editor and create a few "
"buttons:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:171
msgid ""
"Now, go to the root node of the scene and locate the \"theme\" property, "
"replace it by the theme that was just created. It should look like this:"
msgstr ""

#: ../../docs/tutorials/gui/gui_skinning.rst:176
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 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:17
msgid "Drawing"
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_rect_size>` member variable 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_focus_mode>` member variable. 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_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 to 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_get_minimum_size>`, for example:"
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:96
msgid "Or alternatively, set it via 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:118
msgid "Input events"
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_focus_mode>`."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:130
msgid ""
"This function is :ref:`Control._gui_input() <class_Control__gui_input>`. "
"Simply override it in your control. No processing needs to be set."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:167
msgid ""
"For more information about events themselves, check the :ref:"
"`doc_inputevent` tutorial."
msgstr ""

#: ../../docs/tutorials/gui/custom_gui_controls.rst:173
msgid ""
"Controls also have many useful notifications for which no callback exists, "
"but 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 END, 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/bbcode_in_richtextlabel.rst:4
msgid "BBCode in RichTextLabel"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:9
msgid ""
":ref:`class_RichTextLabel` allows to display 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:12
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:18
msgid ""
"For RichTextLabel to work properly, it must be set up. This means loading "
"the intended fonts in the relevant properties:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:24
#: ../../docs/development/cpp/inheritance_class_tree.rst:10
msgid "Reference"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:27
msgid "Command"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:27
#: ../../docs/community/contributing/updating_the_class_reference.rst:227
msgid "Tag"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:29
msgid "**bold**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:29
msgid "``[b]{text}[/b]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:29
msgid "Makes {text} bold."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:31
msgid "**italics**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:31
msgid "``[i]{text}[/i]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:31
msgid "Makes {text} italics."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:33
msgid "**underline**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:33
msgid "``[u]{text}[/u]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:33
msgid "Makes {text} underline."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:35
msgid "**code**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:35
msgid "``[code]{text}[/code]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:35
msgid "Makes {text} monospace."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:37
msgid "**center**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:37
msgid "``[center]{text}[/center]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:37
msgid "Makes {text} centered."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:39
msgid "**right**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:39
msgid "``[right]{text}[/right]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:39
msgid "Makes {text} right-aligned."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:41
msgid "**fill**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:41
msgid "``[fill]{text}[/fill]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:41
msgid "Makes {text} fill width."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:43
msgid "**indent**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:43
msgid "``[indent]{text}[/indent]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:43
msgid "Increase indent level of {text}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:45
msgid "**url**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:45
msgid "``[url]{url}[/url]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:45
msgid "Show {url} as such."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:47
msgid "**url (ref)**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:47
msgid "``[url=<url>]{text}[/url]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:47
msgid "Makes {text} reference <url>."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:49
msgid "**image**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:49
msgid "``[img]{path}[/img]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:49
msgid "Insert image at resource {path}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
msgid "**font**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
msgid "``[font=<path>]{text}[/font]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:51
msgid "Use custom font at <path> for {text}."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "**color**"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "``[color=<code/name>]{text}[/color]``"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:53
msgid "Change {text} color, use # format such as #ff00ff or name."
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:57
msgid "Built-in color names"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:59
msgid "List of valid color names for the [color=<name>] tag:"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:61
msgid "aqua"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:62
msgid "black"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:63
msgid "blue"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:64
msgid "fuchsia"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:65
msgid "gray"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:66
msgid "green"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:67
msgid "lime"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:68
msgid "maroon"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:69
msgid "navy"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:70
msgid "purple"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:71
msgid "red"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:72
msgid "silver"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:73
msgid "teal"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:74
msgid "white"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:75
msgid "yellow"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:78
msgid "Hexadecimal color codes"
msgstr ""

#: ../../docs/tutorials/gui/bbcode_in_richtextlabel.rst:80
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:82
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/viewports/index.rst:2
#: ../../docs/tutorials/viewports/viewports.rst:4
msgid "Viewports"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:9
msgid ""
"Think of :ref:`Viewports <class_Viewport>` as a screen that the game is "
"projected onto. In order to see the game we need to have a surface to draw "
"it on, this 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 then you can "
"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>` to not "
"recieve 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 "
"heirarchy, 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 becuase :ref:`Viewport <class_Viewport>` "
"nodes only capture nodes below them in the heirarchy."
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:84
msgid "Scale & stretching"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:86
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:90
msgid ""
"It is also possible to scale the 2D content and make the :ref:`Viewport "
"<class_Viewport>` resolution different than the one specified in size, by "
"calling:"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:98
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:102
msgid "Worlds"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:104
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-base 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>` (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:116
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:121
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:125
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:128
msgid "Capture"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:130
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:147
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 "
"cause there is nothing to get as texture. You can deal with it using (for "
"example):"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:158
msgid ""
"If the returned image is empty, capture still didn't happen, wait a little "
"more, as Godot's rendering API is asynchronous. For a working example of "
"this check out the `Screen Capture example <https://github.com/godotengine/"
"godot-demo-projects/tree/master/viewport/screen_capture>`_ in the demo "
"projects"
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:170
msgid ""
"The :ref:`Viewport <class_Viewport>` will cover the area of its parent :ref:"
"`ViewportContainer <class_viewportcontainer>` completely if 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:177
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:183
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."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:186
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:192
msgid "*A scene drawn with Debug Draw disabled*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:194
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:200
msgid "*The same scene with Debug Draw set to Unshaded*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:202
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:206
msgid "*The same scene with Debug Draw set to Overdraw*"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:208
msgid ""
"Lastly, Wireframe draws the scene using only the edges of triangles in the "
"meshes. NOTE: as of the writting of this (v3.0.2) wireframe is broken and "
"currently just renders the scene normally."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:212
msgid "Render target"
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:214
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:224
msgid ""
"Or it can be assigned in the editor by selecting \"New ViewportTexture\""
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:228
msgid ""
"and then selecting the :ref:`Viewport <class_Viewport>` you want to use."
msgstr ""

#: ../../docs/tutorials/viewports/viewports.rst:232
msgid ""
"Every frame the :ref:`Viewport <class_Viewport>`'s texture is cleared away "
"with the default clear color (or a transparent color if Transparent BG is "
"set to true). This can be changed by setting 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:237
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:245
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 "Base resolution"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:9
msgid ""
"A base screen resolution for the project can be specified in the project "
"settings under ``display``, ``window``"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:14
msgid ""
"However, what it does is not completely obvious. When running on PC, the "
"engine will attempt to set this resolution (or use something smaller if it "
"fails). On mobile, consoles or devices with a fixed resolution or full "
"screen rendering, this resolution will be ignored and the native resolution "
"will be used instead. To compensate for this, Godot offers many ways to "
"control how the screen will resize and stretch to different screen sizes."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:23
msgid "Resizing"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:25
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:34
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:40
msgid "Stretch settings"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:42
msgid ""
"Stretch settings are located in the project settings, it's just a bunch of "
"configuration variables that provide several options:"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:48
msgid "Stretch mode"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:50
msgid ""
"**Disabled**: The first is the stretch mode. By default this is disabled, "
"which means no stretching happens (the bigger the screen or window, the "
"bigger the resolution, always matching pixels 1:1)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:53
msgid ""
"**2D**: In this mode, the resolution specified in display/width and display/"
"height in the project settings will be stretched to cover the whole screen. "
"This means that 3D will be unaffected (will just render to higher-res) and "
"2D will also be rendered at higher-res, just enlarged."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:58
msgid ""
"**Viewport**: Viewport scaling is different, the root :ref:`Viewport "
"<class_Viewport>` is set as a render target, and still renders precisely to "
"the resolution specified in the ``display/`` section of the project "
"settings. Finally, this viewport is copied and scaled to fit the screen. "
"This mode is useful when working with pixel-precise games, or for the sake "
"of rendering to a lower resolution for improving performance."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:70
msgid "Stretch aspect"
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:72
msgid ""
"**Ignore**: Ignore the aspect ratio when stretching the screen. This means "
"that the original resolution will be stretched to fit the new one, even if "
"it's wider or narrower."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:75
msgid ""
"**Keep**: Keep aspect ratio when stretching the screen. This means that the "
"original resolution will be kept when fitting the new one, and black bars "
"will be added to the sides or the top/bottom of the screen."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:79
msgid ""
"**Keep Width**: Keep aspect ratio when stretching the screen, but if the "
"resulting screen is taller than the specified resolution, it will be "
"stretched vertically (and more vertical resolution will be reported in the "
"viewport, proportionally). 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:85
msgid ""
"**Keep Height**: Keep aspect ratio when stretching the screen, but if the "
"resulting screen is wider than the specified resolution, it will be "
"stretched horizontally (and more horizontal resolution will be reported in "
"the viewport, proportionally). This is usually the best option for 2D games "
"that scroll horizontally (like runners or platformers)."
msgstr ""

#: ../../docs/tutorials/viewports/multiple_resolutions.rst:91
msgid ""
"**Expand**: Keep aspect ratio when stretching the screen, but keep neither "
"width nor height. Depending on the screen aspect ratio, the viewport will "
"either report more horizontal resolution (if the screen is wider than the "
"original resolution) or more vertical resolution (if the screen is taller "
"than the original resolution)."
msgstr ""

#: ../../docs/tutorials/shading/index.rst:2
msgid "Shading"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:4
msgid "Shading language"
msgstr ""

#: ../../docs/tutorials/shading/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_language.rst:12
msgid ""
"Unlike the shader language in Godot 2.x, this implementation is much closer "
"to the original."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:15
msgid "Shader Types"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:17
msgid ""
"Instead of supplying a general purpose configuration, Godot Shading Language "
"must specify what a shader is intended for. Depending on the type, different "
"render modes, built-in variables and processing functions are supported."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:21
msgid ""
"Any shader needs a first line specifying this type, in the following format:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:27
msgid "Valid types are:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:29
msgid "\"spatial\": For 3D rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:30
msgid "\"canvas_item\": For 2D rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:31
msgid "\"particles\": For particle systems."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:34
#: ../../docs/tutorials/shading/shading_language.rst:650
#: ../../docs/tutorials/shading/shading_language.rst:922
#: ../../docs/tutorials/shading/shading_language.rst:1082
msgid "Render Modes"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:36
msgid ""
"Different shader types support different render modes. They are optional "
"but, if specified, must be after the *shader_type*. Example syntax is:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:45
msgid "Data types"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:47
msgid "Most GLSL ES 3.0 datatypes are supported:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:52
msgid "**void**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:52
msgid "Void datatype, useful only for functions that return nothing."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:54
msgid "**bool**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:54
msgid "Boolean datatype, can only contain \"true\" or \"false\""
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:56
msgid "**bvec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:56
msgid "Two component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:58
msgid "**bvec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:58
msgid "Three component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:60
msgid "**bvec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:60
msgid "Four component vector of booleans."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:62
msgid "**int**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:62
msgid "Signed scalar integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:64
msgid "**ivec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:64
msgid "Two component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:66
msgid "**ivec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:66
msgid "Three component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:68
msgid "**ivec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:68
msgid "Four component vector of signed integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:70
msgid "**uint**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:70
msgid "Unsigned scalar integer, can't contain negative numbers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:72
msgid "**uvec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:72
msgid "Two component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:74
msgid "**uvec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:74
msgid "Three component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:76
msgid "**uvec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:76
msgid "Four component vector of unsigned integers."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:78
msgid "**float**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:78
msgid "Floating point scalar."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:80
msgid "**vec2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:80
msgid "Two component vector of floating point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:82
msgid "**vec3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:82
msgid "Three component vector of floating point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:84
#: ../../docs/tutorials/shading/shading_language.rst:422
msgid "**vec4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:84
msgid "Four component vector of floating point values."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:86
msgid "**mat2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:86
msgid "2x2 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:88
msgid "**mat3**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:88
msgid "3x3 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:90
msgid "**mat4**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:90
msgid "4x4 matrix, in column major order."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:92
#: ../../docs/tutorials/shading/shading_language.rst:426
#: ../../docs/tutorials/shading/shading_language.rst:428
#: ../../docs/tutorials/shading/shading_language.rst:430
#: ../../docs/tutorials/shading/shading_language.rst:432
#: ../../docs/tutorials/shading/shading_language.rst:434
#: ../../docs/tutorials/shading/shading_language.rst:436
msgid "**sampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:92
msgid "Sampler type, for binding 2D textures, which are read as float."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:94
msgid "**isampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:94
msgid "Sampler type for binding 2D textures, which are read as signed integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:96
msgid "**usampler2D**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:96
msgid ""
"Sampler type for binding 2D textures, which are read as unsigned integer."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:98
msgid "**samplerCube**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:98
msgid "Sampler type for binding Cubemaps, which are read as floats."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:102
msgid "Casting"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:104
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_language.rst:115
msgid ""
"Default integer constants are signed, so casting is always needed to convert "
"to unsigned:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:124
msgid "Members"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:126
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 use case."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:129
msgid ""
"For matrices, use m[row][column] indexing syntax to access each scalar, or "
"m[idx] for access a vector by row index. For example, for accessing y "
"position of object in mat4 you must use m[3][1] syntax."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:132
msgid "Constructing"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:134
msgid "Construction of vector types must always pass:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:146
msgid ""
"Construction of matrix types requires pass vectors of same dimension as "
"matrix. You could also build a diagonal matrix using matx(float) syntax. So "
"the mat4(1.0) is an identity matrix."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:155
msgid "Swizzling"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:157
msgid ""
"It is possible to obtain any combination of them 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_language.rst:170
msgid "Precision"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:172
msgid ""
"It is possible to add precision modifiers to datatypes, use them for "
"uniforms, variables, arguments and varyings:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:181
msgid ""
"Using lower precision for some operations can speed up the math involved (at "
"the cost of, of course, less precision). This is rarely needed in the vertex "
"shader (where full precision is needed most of the time), but often needed "
"in the fragment one."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:184
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_language.rst:189
msgid "Operators:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:191
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_language.rst:194
msgid "Precedence"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:194
msgid "Class"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:194
msgid "Operator"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:196
msgid "1 (highest)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:196
msgid "parenthetical grouping"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:196
msgid "**()**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:198
#: ../../docs/tutorials/misc/binary_serialization_api.rst:29
msgid "2"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:198
msgid "unary"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:198
msgid "**+, -, !, ~**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:200
#: ../../docs/tutorials/misc/binary_serialization_api.rst:31
msgid "3"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:200
msgid "multiplicative"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:200
msgid "**/, \\*, %**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:202
#: ../../docs/tutorials/misc/binary_serialization_api.rst:33
#: ../../docs/tutorials/misc/binary_serialization_api.rst:94
#: ../../docs/tutorials/misc/binary_serialization_api.rst:103
#: ../../docs/tutorials/misc/binary_serialization_api.rst:112
#: ../../docs/tutorials/misc/binary_serialization_api.rst:121
#: ../../docs/tutorials/misc/binary_serialization_api.rst:134
#: ../../docs/tutorials/misc/binary_serialization_api.rst:136
#: ../../docs/tutorials/misc/binary_serialization_api.rst:145
#: ../../docs/tutorials/misc/binary_serialization_api.rst:147
#: ../../docs/tutorials/misc/binary_serialization_api.rst:149
#: ../../docs/tutorials/misc/binary_serialization_api.rst:151
#: ../../docs/tutorials/misc/binary_serialization_api.rst:160
#: ../../docs/tutorials/misc/binary_serialization_api.rst:162
#: ../../docs/tutorials/misc/binary_serialization_api.rst:164
#: ../../docs/tutorials/misc/binary_serialization_api.rst:173
#: ../../docs/tutorials/misc/binary_serialization_api.rst:175
#: ../../docs/tutorials/misc/binary_serialization_api.rst:177
#: ../../docs/tutorials/misc/binary_serialization_api.rst:179
#: ../../docs/tutorials/misc/binary_serialization_api.rst:181
#: ../../docs/tutorials/misc/binary_serialization_api.rst:183
#: ../../docs/tutorials/misc/binary_serialization_api.rst:192
#: ../../docs/tutorials/misc/binary_serialization_api.rst:194
#: ../../docs/tutorials/misc/binary_serialization_api.rst:196
#: ../../docs/tutorials/misc/binary_serialization_api.rst:198
#: ../../docs/tutorials/misc/binary_serialization_api.rst:207
#: ../../docs/tutorials/misc/binary_serialization_api.rst:209
#: ../../docs/tutorials/misc/binary_serialization_api.rst:211
#: ../../docs/tutorials/misc/binary_serialization_api.rst:213
#: ../../docs/tutorials/misc/binary_serialization_api.rst:222
#: ../../docs/tutorials/misc/binary_serialization_api.rst:224
#: ../../docs/tutorials/misc/binary_serialization_api.rst:226
#: ../../docs/tutorials/misc/binary_serialization_api.rst:228
#: ../../docs/tutorials/misc/binary_serialization_api.rst:230
#: ../../docs/tutorials/misc/binary_serialization_api.rst:232
#: ../../docs/tutorials/misc/binary_serialization_api.rst:241
#: ../../docs/tutorials/misc/binary_serialization_api.rst:243
#: ../../docs/tutorials/misc/binary_serialization_api.rst:245
#: ../../docs/tutorials/misc/binary_serialization_api.rst:247
#: ../../docs/tutorials/misc/binary_serialization_api.rst:249
#: ../../docs/tutorials/misc/binary_serialization_api.rst:251
#: ../../docs/tutorials/misc/binary_serialization_api.rst:253
#: ../../docs/tutorials/misc/binary_serialization_api.rst:255
#: ../../docs/tutorials/misc/binary_serialization_api.rst:257
#: ../../docs/tutorials/misc/binary_serialization_api.rst:266
#: ../../docs/tutorials/misc/binary_serialization_api.rst:268
#: ../../docs/tutorials/misc/binary_serialization_api.rst:270
#: ../../docs/tutorials/misc/binary_serialization_api.rst:272
#: ../../docs/tutorials/misc/binary_serialization_api.rst:274
#: ../../docs/tutorials/misc/binary_serialization_api.rst:276
#: ../../docs/tutorials/misc/binary_serialization_api.rst:278
#: ../../docs/tutorials/misc/binary_serialization_api.rst:280
#: ../../docs/tutorials/misc/binary_serialization_api.rst:282
#: ../../docs/tutorials/misc/binary_serialization_api.rst:284
#: ../../docs/tutorials/misc/binary_serialization_api.rst:286
#: ../../docs/tutorials/misc/binary_serialization_api.rst:288
#: ../../docs/tutorials/misc/binary_serialization_api.rst:297
#: ../../docs/tutorials/misc/binary_serialization_api.rst:299
#: ../../docs/tutorials/misc/binary_serialization_api.rst:301
#: ../../docs/tutorials/misc/binary_serialization_api.rst:303
#: ../../docs/tutorials/misc/binary_serialization_api.rst:312
#: ../../docs/tutorials/misc/binary_serialization_api.rst:332
#: ../../docs/tutorials/misc/binary_serialization_api.rst:334
#: ../../docs/tutorials/misc/binary_serialization_api.rst:342
#: ../../docs/tutorials/misc/binary_serialization_api.rst:361
#: ../../docs/tutorials/misc/binary_serialization_api.rst:373
#: ../../docs/tutorials/misc/binary_serialization_api.rst:385
#: ../../docs/tutorials/misc/binary_serialization_api.rst:398
#: ../../docs/tutorials/misc/binary_serialization_api.rst:400
#: ../../docs/tutorials/misc/binary_serialization_api.rst:409
#: ../../docs/tutorials/misc/binary_serialization_api.rst:411
#: ../../docs/tutorials/misc/binary_serialization_api.rst:420
#: ../../docs/tutorials/misc/binary_serialization_api.rst:428
#: ../../docs/tutorials/misc/binary_serialization_api.rst:441
#: ../../docs/tutorials/misc/binary_serialization_api.rst:443
#: ../../docs/tutorials/misc/binary_serialization_api.rst:445
#: ../../docs/tutorials/misc/binary_serialization_api.rst:454
#: ../../docs/tutorials/misc/binary_serialization_api.rst:456
#: ../../docs/tutorials/misc/binary_serialization_api.rst:458
#: ../../docs/tutorials/misc/binary_serialization_api.rst:460
#: ../../docs/tutorials/misc/binary_serialization_api.rst:469
#: ../../docs/tutorials/misc/binary_serialization_api.rst:471
#: ../../docs/tutorials/misc/binary_serialization_api.rst:473
#: ../../docs/tutorials/misc/binary_serialization_api.rst:475
#: ../../docs/tutorials/misc/binary_serialization_api.rst:477
msgid "4"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:202
msgid "additive"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:202
msgid "**+, -**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:204
#: ../../docs/tutorials/misc/binary_serialization_api.rst:35
msgid "5"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:204
msgid "bit-wise shift"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:204
msgid "**<<, >>**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:206
#: ../../docs/tutorials/misc/binary_serialization_api.rst:37
msgid "6"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:206
msgid "relational"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:206
msgid "**<, >, <=, >=**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:208
#: ../../docs/tutorials/misc/binary_serialization_api.rst:39
msgid "7"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:208
msgid "equality"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:208
msgid "**==, !=**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:210
#: ../../docs/tutorials/misc/binary_serialization_api.rst:41
#: ../../docs/tutorials/misc/binary_serialization_api.rst:123
#: ../../docs/tutorials/misc/binary_serialization_api.rst:136
#: ../../docs/tutorials/misc/binary_serialization_api.rst:147
#: ../../docs/tutorials/misc/binary_serialization_api.rst:162
#: ../../docs/tutorials/misc/binary_serialization_api.rst:175
#: ../../docs/tutorials/misc/binary_serialization_api.rst:194
#: ../../docs/tutorials/misc/binary_serialization_api.rst:209
#: ../../docs/tutorials/misc/binary_serialization_api.rst:224
#: ../../docs/tutorials/misc/binary_serialization_api.rst:243
#: ../../docs/tutorials/misc/binary_serialization_api.rst:268
#: ../../docs/tutorials/misc/binary_serialization_api.rst:299
#: ../../docs/tutorials/misc/binary_serialization_api.rst:321
#: ../../docs/tutorials/misc/binary_serialization_api.rst:334
msgid "8"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:210
msgid "bit-wise and"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:210
msgid "**&**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:212
#: ../../docs/tutorials/misc/binary_serialization_api.rst:43
msgid "9"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:212
msgid "bit-wise exclusive or"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:212
msgid "**^**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:214
#: ../../docs/tutorials/misc/binary_serialization_api.rst:45
msgid "10"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:214
msgid "bit-wise inclusive or"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:214
msgid "**|**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:216
#: ../../docs/tutorials/misc/binary_serialization_api.rst:47
msgid "11"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:216
msgid "logical and"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:216
msgid "**&&**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:218
msgid "12 (lowest)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:218
msgid "logical inclusive or"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:218
msgid "**||**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:224
msgid "Godot Shading language supports the most common types of flow control:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:246
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 to not make this mistake!"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:250
msgid "Discarding"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:252
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_language.rst:257
msgid ""
"It's possible to define any function in a Godot shader. They take the "
"following syntax:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:272
msgid "Functions can be used from any other function that is below it."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:274
msgid "Function argument can have special qualifiers:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:276
msgid "**in**: Means the argument is only for reading (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:277
msgid "**out**: Means the argument is only for writing."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:278
msgid "**inout**: Means the argument is fully passed via reference."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:280
msgid "Example below:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:289
msgid "Processor Functions"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:291
msgid ""
"Depending on shader type, processor functions may be available to optionally "
"override. 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_language.rst:296
msgid "Vertex Processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:298
msgid ""
"The \"vertex\" processing function is called for every vertex, 2D or 3D. For "
"particles, it's called for every particle."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:301
msgid ""
"Depending on shader type, a different set of built-in inputs and outputs are "
"provided. In general, vertex functions are not that commonly used."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:313
msgid "Fragment Processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:315
msgid ""
"The \"fragment\" processor is used to set up the Godot material parameters "
"per pixel. This code runs on every visible pixel the object or primitive is "
"drawn to."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:327
msgid "Light Processor"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:329
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)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:341
msgid "Varyings"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:343
msgid ""
"To send data from vertex to fragment shader, *varyings* are used. They are "
"set for every primitive vertex in the *vertex processor*, and the value is "
"interpolated (and perspective corrected) when reaching every pixel in the "
"fragment processor."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:361
msgid "Interpolation qualifiers"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:363
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_language.rst:380
msgid "There are three possible interpolation qualifiers:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:383
msgid "Qualifier"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:385
msgid "**flat**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:385
msgid "The value is not interpolated"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:387
msgid "**noperspective**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:387
msgid "The value is linearly interpolated in window-space"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:389
msgid "**smooth**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:389
msgid ""
"The value is interpolated in a perspective-correct fashion. This is the "
"default"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:394
msgid "Uniforms"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:396
msgid ""
"Passing values to shaders is possible. These are global to the whole shader "
"and called *uniforms*. When a shader is later assigned to a material, the "
"uniforms will appear as editable parameters on it. Uniforms can't be written "
"from within the shader."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:406
msgid ""
"Any type except for *void* can be a uniform. Additionally, Godot provides "
"optional shader hints to make the compiler understand what the uniform is "
"used for."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:417
msgid "Full list of hints below:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:420
msgid "Hint"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:422
msgid "hint_color"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:422
msgid "Used as color"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:424
msgid "**int, float**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:424
msgid "hint_range(min,max [,step] )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:424
msgid "Used as range (with min/max/step)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:426
msgid "hint_albedo"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:426
msgid "Used as albedo color, default white"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:428
msgid "hint_black_albedo"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:428
msgid "Used as albedo color, default black"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:430
msgid "hint_normal"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:430
msgid "Used as normalmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:432
msgid "hint_white"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:432
msgid "As value, default to white."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:434
msgid "hint_black"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:434
msgid "As value, default to black"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:436
msgid "hint_aniso"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:436
msgid "As flowmap, default to right."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:440
msgid ""
"As Godot 3D engine renders in linear color space, it's important to "
"understand that textures that are supplied as color (ie, albedo) need to be "
"specified as such for proper SRGB->linear conversion."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:444
msgid "Uniforms can also be assigned default values:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:454
msgid "Built-in Functions"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:456
msgid ""
"A large number of built-in functions are supported, conforming mostly 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_language.rst:460
msgid "Function"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:462
msgid "vec_type **radians** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:462
msgid "Convert degrees to radians"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:464
msgid "vec_type **degrees** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:464
msgid "Convert radians to degrees"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:466
msgid "vec_type **sin** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:466
msgid "Sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:468
msgid "vec_type **cos** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:468
msgid "Cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:470
msgid "vec_type **tan** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:470
msgid "Tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:472
msgid "vec_type **asin** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:472
msgid "Arc-Sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:474
msgid "vec_type **acos** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:474
msgid "Arc-Cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:476
msgid "vec_type **atan** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:476
msgid "Arc-Tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:478
msgid "vec_type **atan** ( vec_type x, vec_type y )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:478
msgid "Arc-Tangent to convert vector to angle"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:480
msgid "vec_type **sinh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:480
msgid "Hyperbolic-Sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:482
msgid "vec_type **cosh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:482
msgid "Hyperbolic-Cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:484
msgid "vec_type **tanh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:484
msgid "Hyperbolic-Tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:486
msgid "vec_type **asinh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:486
msgid "Inverse-Hyperbolic-Sine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:488
msgid "vec_type **acosh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:488
msgid "Inverse-Hyperbolic-Cosine"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:490
msgid "vec_type **atanh** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:490
msgid "Inverse-Hyperbolic-Tangent"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:492
msgid "vec_type **pow** ( vec_type, vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:492
msgid "Power"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:494
msgid "vec_type **exp** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:494
msgid "Base-e Exponential"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:496
msgid "vec_type **exp2** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:496
msgid "Base-2 Exponential"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:498
msgid "vec_type **log** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:498
msgid "Natural Logarithm"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:500
msgid "vec_type **log2** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:500
msgid "Base-2 Logarithm"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:502
msgid "vec_type **sqrt** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:502
msgid "Square Root"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:504
msgid "vec_type **inversesqrt** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:504
msgid "Inverse Square Root"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:506
msgid "vec_type **abs** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:506
#: ../../docs/tutorials/shading/shading_language.rst:508
msgid "Absolute"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:508
msgid "vec_int_type **abs** ( vec_int_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:510
msgid "vec_type **sign** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:510
#: ../../docs/tutorials/shading/shading_language.rst:512
msgid "Sign"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:512
msgid "vec_int_type **sign** ( vec_int_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:514
msgid "vec_type **floor** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:514
msgid "Floor"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:516
msgid "vec_type **round** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:516
msgid "Round"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:518
msgid "vec_type **roundEven** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:518
msgid "Round nearest even"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:520
msgid "vec_type **trunc** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:520
msgid "Truncation"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:522
msgid "vec_type **ceil** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:522
msgid "Ceiling"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:524
msgid "vec_type **fract** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:524
msgid "Fractional"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:526
msgid "vec_type **mod** ( vec_type, vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:526
#: ../../docs/tutorials/shading/shading_language.rst:528
msgid "Remainder"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:528
msgid "vec_type **mod** ( vec_type, float )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:530
msgid "vec_type **modf** ( vec_type x, out vec_type i )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:530
msgid "Fractional of x, with i has integer part"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:532
msgid "vec_scalar_type **min** ( vec_scalar_type a, vec_scalar_type b )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:532
msgid "Minimum"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:534
msgid "vec_scalar_type **max** ( vec_scalar_type a, vec_scalar_type b )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:534
msgid "Maximum"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:536
msgid ""
"vec_scalar_type **clamp** ( vec_scalar_type value, vec_scalar_type min, "
"vec_scalar_type max )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:536
msgid "Clamp to Min-Max"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:538
msgid "vec_type **mix** ( vec_type a, vec_type b, float c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:538
msgid "Linear Interpolate (Scalar Coef.)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:540
msgid "vec_type **mix** ( vec_type a, vec_type b, vec_type c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:540
msgid "Linear Interpolate (Vector Coef.)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:542
msgid "vec_type **mix** ( vec_type a, vec_type b, bool c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:542
msgid "Linear Interpolate (Bool Selection)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:544
msgid "vec_type **mix** ( vec_type a, vec_type b, vec_bool_type c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:544
msgid "Linear Interpolate (Bool-Vector Selection)"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:546
msgid "vec_type **step** ( vec_type a, vec_type b )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:546
msgid "\\` b[i] < a[i] ? 0.0 : 1.0 \\`"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:548
msgid "vec_type **step** ( float a, vec_type b )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:548
msgid "\\` b[i] < a ? 0.0 : 1.0 \\`"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:550
msgid "vec_type **smoothstep** ( vec_type a, vec_type b, vec_type c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:550
#: ../../docs/tutorials/shading/shading_language.rst:552
msgid "Hermite Interpolate"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:552
msgid "vec_type **smoothstep** ( float a, float b, vec_type c )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:554
msgid "vec_bool_type **isnan** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:554
msgid "Scalar, or vector component being nan"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:556
msgid "vec_bool_type **isinf** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:556
msgid "Scalar, or vector component being inf"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:558
msgid "vec_int_type **floatBitsToInt** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:558
msgid "Float->Int bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:560
msgid "vec_uint_type **floatBitsToUint** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:560
msgid "Float->UInt bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:562
msgid "vec_type **intBitsToFloat** ( vec_int_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:562
msgid "Int->Float bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:564
msgid "vec_type **uintBitsToFloat** ( vec_uint_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:564
msgid "UInt->Float bit copying, no conversion"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:566
msgid "float **length** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:566
msgid "Vector Length"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:568
msgid "float **distance** ( vec_type, vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:568
msgid "Distance between vector"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:570
msgid "float **dot** ( vec_type, vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:570
msgid "Dot Product"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:572
msgid "vec3 **cross** ( vec3, vec3 )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:572
msgid "Cross Product"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:574
msgid "vec_type **normalize** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:574
msgid "Normalize to unit length"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:576
msgid "vec3 **reflect** ( vec3 I, vec3 N )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:576
msgid "Reflect"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:578
msgid "vec3 **refract** ( vec3 I, vec3 N, float eta )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:578
msgid "Refract"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:580
msgid "vec_type **faceforward** ( vec_type N, vec_type I, vec_type Nref )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:580
msgid "If dot(Nref, I) < 0 return N, otherwise –N"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:582
msgid "mat_type **matrixCompMult** ( mat_type, mat_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:582
msgid "Matrix Component Multiplication"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:584
msgid "mat_type **outerProduct** ( vec_type, vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:584
msgid "Matrix Outer Product"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:586
msgid "mat_type **transpose** ( mat_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:586
msgid "Transpose Matrix"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:588
msgid "float **determinant** ( mat_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:588
msgid "Matrix Determinant"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:590
msgid "mat_type **inverse** ( mat_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:590
msgid "Inverse Matrix"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:592
msgid "vec_bool_type **lessThan** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:592
msgid "Bool vector cmp on < int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:594
msgid "vec_bool_type **greaterThan** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:594
msgid "Bool vector cmp on > int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:596
msgid "vec_bool_type **lessThanEqual** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:596
msgid "Bool vector cmp on <= int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:598
msgid "vec_bool_type **greaterThanEqual** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:598
msgid "Bool vector cmp on >= int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:600
msgid "vec_bool_type **equal** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:600
msgid "Bool vector cmp on == int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:602
msgid "vec_bool_type **notEqual** ( vec_scalar_type, vec_scalar_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:602
msgid "Bool vector cmp on != int/uint/float vectors"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:604
msgid "bool **any** ( vec_bool_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:604
msgid "Any component is true"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:606
msgid "bool **all** ( vec_bool_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:606
msgid "All components are true"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:608
msgid "bool **not** ( vec_bool_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:608
msgid "No components are true"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:610
msgid "ivec2 **textureSize** ( sampler2D_type s, int lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:610
msgid "Get the size of a texture"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:612
msgid "ivec2 **textureSize** ( samplerCube s, int lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:612
msgid "Get the size of a cubemap"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:614
msgid "vec4_type **texture** ( sampler2D_type s, vec2 uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:614
msgid "Perform a 2D texture read"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:616
msgid "vec4_type **texture** ( samplerCube s, vec3 uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:616
msgid "Perform a Cube texture read"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:618
msgid "vec4_type **textureProj** ( sampler2D_type s, vec3 uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:618
#: ../../docs/tutorials/shading/shading_language.rst:620
msgid "Perform a texture read with projection"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:620
msgid "vec4_type **textureProj** ( sampler2D_type s, vec4 uv [, float bias] )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:622
msgid "vec4_type **textureLod** ( sampler2D_type s, vec2 uv, float lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:622
msgid "Perform a 2D texture read at custom mipmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:624
msgid "vec4_type **textureLod** ( samplerCube s, vec3 uv, float lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:624
msgid "Perform a Cube texture read at custom mipmap"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:626
msgid "vec4_type **textureProjLod** ( sampler2D_type s, vec3 uv, float lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:626
#: ../../docs/tutorials/shading/shading_language.rst:628
msgid "Perform a texture read with projection/lod"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:628
msgid "vec4_type **textureProjLod** ( sampler2D_type s, vec4 uv, float lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:630
msgid "vec4_type **texelFetch** ( sampler2D_type s, ivec2 uv, int lod )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:630
msgid "Fetch a single texel using integer coords"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:632
msgid "vec_type **dFdx** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:632
msgid "Derivative in x using local differencing"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:634
msgid "vec_type **dFdy** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:634
msgid "Derivative in y using local differencing"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:636
msgid "vec_type **fwidth** ( vec_type )"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:636
msgid "Sum of absolute derivative in x and y"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:642
msgid "Shader Types In-Depth"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:645
#: ../../docs/development/cpp/inheritance_class_tree.rst:25
msgid "Spatial"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:647
msgid "Accepted render modes and built-ins for **shader_type spatial;**."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:653
#: ../../docs/tutorials/shading/shading_language.rst:925
#: ../../docs/tutorials/shading/shading_language.rst:1085
msgid "Render Mode"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:655
#: ../../docs/tutorials/shading/shading_language.rst:927
msgid "**blend_mix**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:655
#: ../../docs/tutorials/shading/shading_language.rst:927
msgid "Mix blend mode (alpha is transparency), default."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:657
#: ../../docs/tutorials/shading/shading_language.rst:929
msgid "**blend_add**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:657
#: ../../docs/tutorials/shading/shading_language.rst:929
msgid "Additive blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:659
#: ../../docs/tutorials/shading/shading_language.rst:931
msgid "**blend_sub**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:659
msgid "Substractive blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:661
#: ../../docs/tutorials/shading/shading_language.rst:933
msgid "**blend_mul**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:661
#: ../../docs/tutorials/shading/shading_language.rst:933
msgid "Multiplicative blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:663
msgid "**depth_draw_opaque**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:663
msgid "Only draw depth for opaque geometry (not transparent)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:665
msgid "**depth_draw_always**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:665
msgid "Always draw depth (opaque and transparent)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:667
msgid "**depth_draw_never**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:667
msgid "Never draw depth."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:669
msgid "**depth_draw_alpha_prepass**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:669
msgid "Do opaque depth pre-pass for transparent geometry."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:671
msgid "**depth_test_disable**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:671
msgid "Disable depth testing."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:673
msgid "**cull_front**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:673
msgid "Cull front-faces."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:675
msgid "**cull_back**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:675
msgid "Cull back-faces (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:677
msgid "**cull_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:677
msgid "Culling disabled (double sided)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:679
#: ../../docs/tutorials/shading/shading_language.rst:937
msgid "**unshaded**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:679
#: ../../docs/tutorials/shading/shading_language.rst:937
msgid "Result is just albedo. No lighting/shading happens in material."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:681
msgid "**diffuse_lambert**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:681
msgid "Lambert shading for diffuse (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:683
msgid "**diffuse_lambert_wrap**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:683
msgid "Lambert wrapping (roughness dependent) for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:685
msgid "**diffuse_oren_nayar**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:685
msgid "Oren Nayar for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:687
msgid "**diffuse_burley**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:687
msgid "Burley (Disney PBS) for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:689
msgid "**diffuse_toon**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:689
msgid "Toon shading for diffuse."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:691
msgid "**specular_schlick_ggx**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:691
msgid "Schlick-GGX for specular (default)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:693
msgid "**specular_blinn**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:693
msgid "Blinn for specular (compatibility)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:695
msgid "**specular_phong**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:695
msgid "Phong for specular (compatibility)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:697
msgid "**specular_toon**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:697
msgid "Toon for specular."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:699
msgid "**specular_disabled**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:699
msgid "Disable specular."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:701
#: ../../docs/tutorials/shading/shading_language.rst:941
msgid "**skip_vertex_transform**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:701
#: ../../docs/tutorials/shading/shading_language.rst:941
msgid "VERTEX/NORMAL/etc need to be transformed manually in VS."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:703
msgid "**world_vertex_coords**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:703
msgid "VERTEX/NORMAL/etc are modified in world coordinates instead of local."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:705
msgid "**vertex_lighting**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:705
msgid "Use vertex-based lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:709
#: ../../docs/tutorials/shading/shading_language.rst:945
#: ../../docs/tutorials/shading/shading_language.rst:1095
msgid "Vertex Built-Ins"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:714
msgid "out mat4 **WORLD_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:714
#: ../../docs/tutorials/shading/shading_language.rst:794
#: ../../docs/tutorials/shading/shading_language.rst:877
msgid "Model space to world space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:716
#: ../../docs/tutorials/shading/shading_language.rst:796
#: ../../docs/tutorials/shading/shading_language.rst:879
msgid "in mat4 **INV_CAMERA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:716
#: ../../docs/tutorials/shading/shading_language.rst:796
#: ../../docs/tutorials/shading/shading_language.rst:879
msgid "World space to view space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:718
msgid "out mat4 **PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:718
#: ../../docs/tutorials/shading/shading_language.rst:798
#: ../../docs/tutorials/shading/shading_language.rst:881
msgid "View space to clip space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:720
msgid "in mat4 **CAMERA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:720
msgid "View space to world space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:722
msgid "out mat4 **MODELVIEW_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:722
msgid "Model space to view space transform (use if possible)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:724
msgid "out mat4 **INV_PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:724
#: ../../docs/tutorials/shading/shading_language.rst:800
#: ../../docs/tutorials/shading/shading_language.rst:883
msgid "Clip space to view space transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:726
#: ../../docs/tutorials/shading/shading_language.rst:802
#: ../../docs/tutorials/shading/shading_language.rst:885
#: ../../docs/tutorials/shading/shading_language.rst:956
#: ../../docs/tutorials/shading/shading_language.rst:1029
#: ../../docs/tutorials/shading/shading_language.rst:1060
#: ../../docs/tutorials/shading/shading_language.rst:1114
msgid "in float **TIME**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:726
#: ../../docs/tutorials/shading/shading_language.rst:802
#: ../../docs/tutorials/shading/shading_language.rst:885
msgid "Elapsed total time in seconds."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:728
#: ../../docs/tutorials/shading/shading_language.rst:804
#: ../../docs/tutorials/shading/shading_language.rst:887
msgid "in vec2 **VIEWPORT_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:728
#: ../../docs/tutorials/shading/shading_language.rst:804
#: ../../docs/tutorials/shading/shading_language.rst:887
msgid "Size of viewport (in pixels)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:730
msgid "out vec3 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:730
msgid "Vertex in local coords (see doc below)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:732
#: ../../docs/tutorials/shading/shading_language.rst:812
#: ../../docs/tutorials/shading/shading_language.rst:1007
msgid "out vec3 **NORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:732
msgid "Normal in local coords."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:734
#: ../../docs/tutorials/shading/shading_language.rst:814
msgid "out vec3 **TANGENT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:734
msgid "Tangent in local coords."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:736
#: ../../docs/tutorials/shading/shading_language.rst:816
msgid "out vec3 **BINORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:736
msgid "Binormal in local coords."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:738
#: ../../docs/tutorials/shading/shading_language.rst:964
msgid "out vec2 **UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:738
msgid "UV main channel."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:740
msgid "out vec2 **UV2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:740
msgid "UV secondary channel."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:742
#: ../../docs/tutorials/shading/shading_language.rst:966
#: ../../docs/tutorials/shading/shading_language.rst:1015
#: ../../docs/tutorials/shading/shading_language.rst:1100
msgid "out vec4 **COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:742
msgid "Color from vertices."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:744
#: ../../docs/tutorials/shading/shading_language.rst:968
msgid "out float **POINT_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:744
msgid "Point size for point rendering."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:746
msgid "in int **INSTANCE_ID**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:746
msgid "Instance ID for instancing."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:748
#: ../../docs/tutorials/shading/shading_language.rst:958
msgid "in vec4 **INSTANCE_CUSTOM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:748
msgid "Instance custom data (for particles, mostly)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:750
#: ../../docs/tutorials/shading/shading_language.rst:836
msgid "out float **ROUGHNESS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:750
msgid "Roughness for vertex lighting."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:753
msgid ""
"Values marked as \"in\" are read-only. Values marked as \"out\" are for "
"optional writing. Samplers are not subjects of writing and they are not "
"marked."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:755
msgid ""
"Vertex data (VERTEX, NORMAL, TANGENT, BITANGENT) is 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_language.rst:758
msgid ""
"They can be optionally set to be presented in world space (after being "
"transformed by world) by adding the *world_vertex_coords* render mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:761
msgid ""
"It is also possible to completely disable the built-in modelview transform "
"(projection will still happen later, though) with the following code, so it "
"can be done manually:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:776
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_language.rst:778
#: ../../docs/tutorials/shading/shading_language.rst:989
msgid ""
"For instancing, the INSTANCE_CUSTOM variable contains the instance custom "
"data. When using particles, this information is usually:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:781
#: ../../docs/tutorials/shading/shading_language.rst:992
msgid "**x**: Rotation angle in radians."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:782
#: ../../docs/tutorials/shading/shading_language.rst:993
msgid "**y**: Phase during lifetime (0 to 1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:783
#: ../../docs/tutorials/shading/shading_language.rst:994
msgid "**z**: Animation frame."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:785
#: ../../docs/tutorials/shading/shading_language.rst:996
msgid ""
"This allows to easily adjust the shader to a particle system using default "
"particles material. When writing a custom particles shader, this value can "
"be used as desired."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:789
#: ../../docs/tutorials/shading/shading_language.rst:1000
msgid "Fragment Built-Ins"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:794
#: ../../docs/tutorials/shading/shading_language.rst:877
#: ../../docs/tutorials/shading/shading_language.rst:950
msgid "in mat4 **WORLD_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:798
#: ../../docs/tutorials/shading/shading_language.rst:881
#: ../../docs/tutorials/shading/shading_language.rst:954
msgid "in mat4 **PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:800
#: ../../docs/tutorials/shading/shading_language.rst:883
msgid "in mat4 **INV_PROJECTION_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:806
msgid "in vec3 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:806
msgid "Vertex that comes from vertex function, in view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:808
#: ../../docs/tutorials/shading/shading_language.rst:1005
msgid "in vec4 **FRAGCOORD**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:808
#: ../../docs/tutorials/shading/shading_language.rst:1005
#: ../../docs/tutorials/shading/shading_language.rst:1042
msgid "Fragment coordinate, pixel adjusted."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:810
msgid "in bool **FRONT_FACING**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:810
msgid "true whether current face is front face."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:812
msgid "Normal that comes from vertex function, in view space."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:814
msgid "Tangent that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:816
msgid "Binormal that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:818
#: ../../docs/tutorials/shading/shading_language.rst:1009
msgid "out vec3 **NORMALMAP**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:818
msgid "Output this if reading normal from a texture instead of NORMAL."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:820
#: ../../docs/tutorials/shading/shading_language.rst:1011
msgid "out float **NORMALMAP_DEPTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:820
msgid "Depth from variable above. Defaults to 1.0."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:822
#: ../../docs/tutorials/shading/shading_language.rst:1013
#: ../../docs/tutorials/shading/shading_language.rst:1047
msgid "in vec2 **UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:822
msgid "UV that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:824
msgid "in vec2 **UV2**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:824
msgid "UV2 that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:826
#: ../../docs/tutorials/shading/shading_language.rst:1049
msgid "in vec4 **COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:826
msgid "COLOR that comes from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:828
msgid "out vec3 **ALBEDO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:828
msgid "Albedo (default white)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:830
msgid "out float **ALPHA**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:830
msgid ""
"Alpha (0..1), if written to the material will go to transparent pipeline."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:832
msgid "out float **METALLIC**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:832
msgid "Metallic (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:834
msgid "out float **SPECULAR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:834
msgid ""
"Specular. Defaults to 0.5, best to not modify unless you want to change IOR."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:836
msgid "Roughness (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:838
msgid "out float **RIM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:838
msgid "Rim (0..1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:840
msgid "out float **RIM_TINT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:840
msgid "Rim Tint, goes from 0 (white) to 1 (albedo)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:842
msgid "out float **CLEARCOAT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:842
msgid "Small added specular blob."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:844
msgid "out float **CLEARCOAT_GLOSS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:844
msgid "Gloss of Clearcoat."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:846
msgid "out float **ANISOTROPY**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:846
msgid "For distorting the specular blob according to tangent space."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:848
msgid "out vec2 **ANISOTROPY_FLOW**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:848
msgid "Distortion direction, use with flowmaps."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:850
msgid "out float **SSS_STRENGTH**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:850
msgid "Strength of Subsurface Scattering (default 0)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:852
msgid "out vec3 **TRANSMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:852
msgid "Transmission mask (default 0,0,0)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:854
msgid "out float **AO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:854
msgid "Ambient Occlusion (pre-baked)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:856
msgid "out float **AO_LIGHT_AFFECT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:856
msgid "How much AO affects lights (0..1. default 0, none)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:858
msgid "out vec3 **EMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:858
msgid "Emission color (can go over 1,1,1 for HDR)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:860
#: ../../docs/tutorials/shading/shading_language.rst:1033
msgid "sampler2D **SCREEN_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:860
msgid ""
"Built-in Texture for reading from the screen. Mipmaps contain increasingly "
"blurred copies."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:862
msgid "sampler2D **DEPTH_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:862
msgid ""
"Built-in Texture for reading depth from the screen. Must convert to linear "
"using INV_PROJECTION."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:864
msgid "out vec2 **SCREEN_UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:864
msgid "Screen UV coordinate for current pixel."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:866
#: ../../docs/tutorials/shading/shading_language.rst:1027
#: ../../docs/tutorials/shading/shading_language.rst:1058
msgid "in vec2 **POINT_COORD**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:866
msgid "Point Coord for drawing points with POINT_SIZE."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:868
msgid "out float **ALPHA_SCISSOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:868
msgid "If written to, values below a certain amount of alpha are discarded."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:872
#: ../../docs/tutorials/shading/shading_language.rst:1037
msgid "Light Built-Ins"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:875
msgid "Built-in"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:889
#: ../../docs/tutorials/shading/shading_language.rst:1044
msgid "in vec3 **NORMAL**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:889
msgid "Normal vector."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:891
msgid "in vec3 **VIEW**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:891
msgid "View vector."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:893
msgid "in vec3 **LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:893
msgid "Light Vector."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:895
msgid "in vec3 **LIGHT_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:895
msgid "Color of light multiplied by energy."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:897
msgid "in vec3 **ATTENUATION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:897
msgid "Attenuation based on distance or shadow."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:899
msgid "in vec3 **ALBEDO**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:899
msgid "Base albedo."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:901
msgid "in vec3 **TRANSMISSION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:901
msgid "Transmission mask."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:903
msgid "in float **ROUGHNESS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:903
msgid "Roughness."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:905
msgid "out vec3 **DIFFUSE_LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:905
msgid "Diffuse light result."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:907
msgid "out vec3 **SPECULAR_LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:907
msgid "Specular light result."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:910
msgid ""
"Writing light shaders is completely optional. Unlike other game engines, "
"they don't affect performance or force a specific pipeline."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:913
msgid ""
"To write a light shader, simply make sure to assign something to "
"DIFFUSE_LIGHT or SPECULAR_LIGHT. Assigning nothing means no light is "
"processed."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:917
msgid "Canvas Item"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:919
msgid "Accepted render modes and built-ins for **shader_type canvas_item;**."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:931
msgid "Subtractive blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:935
msgid "**blend_premul_alpha**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:935
msgid "Premultiplied alpha blend mode."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:939
msgid "**light_only**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:939
msgid "Only draw for light pass (when multipass is used)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:950
msgid "Image to World transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:952
msgid "in mat4 **EXTRA_MATRIX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:952
msgid "Extra transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:954
msgid "World to view transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:956
msgid "Global time, in seconds."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:958
msgid "Instance custom data."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:960
#: ../../docs/tutorials/shading/shading_language.rst:1031
msgid "in bool **AT_LIGHT_PASS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:960
#: ../../docs/tutorials/shading/shading_language.rst:1031
msgid "True if this is a light pass (for multi-pass light rendering)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:962
msgid "out vec2 **VERTEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:962
msgid "Vertex in image space."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:964
msgid "UV."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:966
msgid "Color from vertex primitive."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:968
msgid "Point size for point drawing."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:971
msgid ""
"Vertex data (VERTEX) is presented in local space. If not written to, these "
"values will not be modified and be passed through as they came."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:974
msgid ""
"It is possible to completely disable the built-in modelview transform "
"(projection will still happen later, though) with the following code, so it "
"can be done manually:"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:987
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_language.rst:1007
msgid "Normal, writable."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1009
msgid "Normal from texture, default is read from NORMAL_TEXTURE."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1011
msgid "Normalmap depth for scaling."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1013
msgid "UV from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1015
msgid "Color from vertex function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1017
#: ../../docs/tutorials/shading/shading_language.rst:1052
msgid "sampler2D **TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1017
msgid "Default 2D texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1019
msgid "sampler2D **NORMAL_TEXTURE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1019
msgid "Default 2D normal texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1021
#: ../../docs/tutorials/shading/shading_language.rst:1054
msgid "in vec2 **TEXTURE_PIXEL_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1021
msgid "Default 2D texture pixel size."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1023
#: ../../docs/tutorials/shading/shading_language.rst:1056
msgid "in vec2 **SCREEN_UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1023
msgid "Screen UV for use with SCREEN_TEXTURE."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1025
msgid "in vec2 **SCREEN_PIXEL_SIZE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1025
msgid "Size of individual pixels. Equal to inverse of resolution."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1027
msgid "Coordinate for drawing points."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1029
#: ../../docs/tutorials/shading/shading_language.rst:1060
#: ../../docs/tutorials/shading/shading_language.rst:1114
msgid "Global time in seconds."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1033
msgid "Screen texture, mipmaps contain gaussian blurred versions."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1042
msgid "in vec2 **POSITION**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1044
msgid ""
"Input Normal. Although this value is passed in, **normal calculation still "
"happens outside of this function**."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1047
msgid "UV from vertex function, equivalent to the UV in the fragment function."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1049
msgid ""
"Input Color. This is the output of the fragment function with final "
"modulation applied."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1052
msgid "Current texture in use for CanvasItem."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1054
msgid "Pixel size for current 2D texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1056
msgid "Screen Texture Coordinate (for using with texscreen)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1058
msgid "Current UV for Point Sprite."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1062
msgid "out vec2 **LIGHT_VEC**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1062
msgid ""
"Vector from light to fragment, can be modified to alter shadow computation."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1064
msgid "out float **LIGHT_HEIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1064
msgid "Height of Light."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1066
msgid "out vec4 **LIGHT_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1066
msgid "Color of Light."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1068
msgid "out vec2 **LIGHT_UV**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1068
msgid "UV for Light texture."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1070
msgid "out vec4 **SHADOW_COLOR**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1070
msgid "Shadow Color of Light. **(not yet implemented)**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1072
msgid "out vec4 **LIGHT**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1072
msgid ""
"Value from the Light texture. **(shader is ignored if this is not used).** "
"Can be modified."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1079
msgid "Accepted render modes and built-ins for **shader_type particles;**."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1087
msgid "**keep_data**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1087
msgid "Do not clear previous data on restart."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1089
msgid "**disable_force**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1089
msgid "Disable force."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1091
msgid "**disable_velocity**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1091
msgid "Disable velocity."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1100
msgid "Particle color, can be written to."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1102
msgid "out vec3 **VELOCITY**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1102
msgid "Particle velocity, can be modified."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1104
msgid "out float **MASS**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1104
msgid "Particle mass, use for attractors (default 1)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1106
msgid "out bool **ACTIVE**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1106
msgid "Particle is active, can be set to false."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1108
msgid "in bool **RESTART**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1108
msgid "Set to true when particle must restart (lifetime cycled)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1110
msgid "out vec4 **CUSTOM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1110
msgid "Custom particle data."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1112
msgid "out mat4 **TRANSFORM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1112
msgid "Particle transform."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1116
msgid "in float **LIFETIME**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1116
msgid "Particle lifetime."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1118
msgid "in float **DELTA**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1118
msgid "Delta process time."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1120
msgid "in uint **NUMBER**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1120
msgid "Unique number since emission start."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1122
msgid "in int **INDEX**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1122
msgid "Particle index (from total particles)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1124
msgid "in mat4 **EMISSION_TRANSFORM**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1124
msgid "Emitter transform (used for non-local systems)."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1126
msgid "in uint **RANDOM_SEED**"
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1126
msgid "Random seed used as base for random."
msgstr ""

#: ../../docs/tutorials/shading/shading_language.rst:1129
msgid ""
"Particle shades only support vertex processing. They are drawn with any "
"regular material for CanvasItem or Spatial, depending on whether they are 2D "
"or 3D."
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 SpatialMaterial, CanvasItemMaterial and "
"ParticlesMaterial (@TODO link to tutorials/classes). 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 blendings."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:19
msgid "Create animated materials, or materials that change with 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, that responds to baked animations or force "
"fields."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:26
msgid ""
"Traditionally, most engines will ask you to learn GLSL, HLSL or CG, which "
"are pretty complex for the skillset of most artists. Godot uses a simplified "
"version of a shader language that will detect errors as you type, so you can "
"see your edited shaders in real-time. Additionally, it is possible to edit "
"shaders using a visual, node-based graph editor."
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:33
msgid "Creating a ShaderMaterial"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:35
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:40
msgid "Edit the newly created shader, and the shader editor will open:"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:45
msgid "Converting to ShaderMaterial"
msgstr ""

#: ../../docs/tutorials/shading/shader_materials.rst:47
msgid ""
"It is possible to convert from SpatialMaterial, CanvasItemMaterial and "
"ParticlesMaterial to ShaderMaterial. To do this go to the material "
"properties and enable the convert option."
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 "
"it's writing to. 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 sort 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 makes 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 case of 3D). It takes as parameter "
"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 2D 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 "
"it's 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:43
msgid "SCREEN_TEXTURE example"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:45
msgid ""
"SCREEN_TEXTURE can be used for a lot of 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:69
msgid "Behind the scenes"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:71
msgid ""
"While this seems magical, it's not. 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."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:77
msgid ""
"As a result, 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:83
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:87
msgid ""
"In 3D, this is unavoidable because copying happens when opaque rendering "
"completes."
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:90
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:96
msgid "With correct back-buffer copying, the two spheres blend correctly:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:101
msgid "Back-buffer logic"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:103
msgid ""
"So, to make it clearer, here's how the backbuffer copying logic works in "
"Godot:"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:106
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:109
msgid ""
"If a BackBufferCopy node was processed before the situation in the point "
"above (even if SCREEN_TEXTURE was not used), this 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:115
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:124
msgid "DEPTH_TEXTURE"
msgstr ""

#: ../../docs/tutorials/shading/screen-reading_shaders.rst:126
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:130
msgid ""
"The following code retrieves the 3D position below the pixel being drawn:"
msgstr ""

#: ../../docs/tutorials/networking/index.rst:2
msgid "Networking"
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/tags/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 implementations can provide it:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:64
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:66
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>`), but this "
"could be used to implement mobile APIs (for adhoc WiFi, Bluetooth) or custom "
"device/console-specific networking APIs."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:69
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:73
msgid "Initializing the network"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:75
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:77
msgid ""
"To initialize high level networking, the SceneTree must be provided a "
"NetworkedMultiplayerPeer object."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:79
msgid ""
"To create that object it first has to be initialized as a server or client."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:81
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:89
msgid "Initializing as a client, connecting to a given IP and port:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:97
msgid ""
"Note that it may make sense to store the local network peer instance on the "
"SceneTree to be able to access it later, as there currently is no "
"`get_tree().get_network_peer()`. This can be done via SceneTree's metadata "
"feature:"
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_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 do 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 a RPC call."
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:230
msgid ""
"You might have noticed already something different, which is the usage of "
"the `remote` keyword on the `register_player` function:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:236
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:240
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:242
msgid "`remote`"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:243
msgid "`sync`"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:244
msgid "`master`"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:245
msgid "`slave`"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:247
msgid ""
"The `remote` keyword means that the `rpc()` call will go via network and "
"execute remotely."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:249
msgid ""
"The `sync` 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:251
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:254
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:259
msgid "Starting the game"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:261
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:265
msgid "Player scenes"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:267
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:270
msgid ""
"So, how to name such nodes? In Godot nodes need to have an unique name. It "
"must also be relatively easy for a player to tell which nodes represent each "
"player ID."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:273
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:301
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:305
msgid "Synchronizing game start"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:307
msgid ""
"Setting up players might take different amount of time on 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:316
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:337
msgid "Synchronizing the game"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:339
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 network "
"masters."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:343
msgid "Network master"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:345
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:347
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:349
msgid ""
"The network master can be set with the function :ref:`Node."
"set_network_master(id, recursive) <class_Node_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:352
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_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:354
msgid ""
"If you have paid attention to the previous example, it's possible you "
"noticed that the local peer is set to have network master authority for "
"their own player instead of the server:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:373
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 slaves with "
"the server being their network master."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:375
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:382
msgid "Master and slave keywords"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:386
msgid ""
"The real advantage of this model is when used with the `master`/`slave` "
"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:389
msgid "Example bomb code:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:397
msgid "Example player code:"
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:411
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:414
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:417
msgid ""
"This instance, then, calls the `stun` function in the same instances of that "
"same player (but in different peers), and only those which are set as slave, "
"making the player look stunned in all the peers (as well as the current, "
"master one)."
msgstr ""

#: ../../docs/tutorials/networking/high_level_multiplayer.rst:420
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/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 an "
"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_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 more 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 ""
"For SSL to work, certificates need to be provided. A .crt file must be "
"specified in the project settings:"
msgstr ""

#: ../../docs/tutorials/networking/ssl_certificates.rst:21
msgid ""
"This file should contain any number of public certificates in https://en."
"wikipedia.org/wiki/Privacy-enhanced_Electronic_Mail format."
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 put the public pair in the .crt file (again, in PEM format). 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/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:32
msgid "Can paid assets be uploaded to the asset library?"
msgstr ""

#: ../../docs/tutorials/assetlib/what_is_assetlib.rst:34
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 average rating, displayed in stars. (This is currently "
"unimplemented.)"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:64
msgid "Asset's category, Godot version, and support status."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:65
msgid "Asset's original author/submitter."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:66
msgid "The license the asset is distributed under."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:67
msgid "The date of the asset's latest edit/update."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:68
msgid "A textual description of the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:69
msgid "Links related to the asset (download link, file list, issue tracker)."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:70
msgid "A SHA-256 hash of the asset, for download validation purposes."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:71
msgid "Images and videos showcasing the asset."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:74
msgid "Registering and logging in"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:76
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:81
msgid "The login/registration page can be accessed from the AssetLib header."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:85
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:90
msgid "Then, you can use your username and password to log in."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:94
msgid ""
"This will change the look of the AssetLib header. Now you get access to a "
"handful new functions:"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:97
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:98
msgid "A list of your uploaded assets."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:99
msgid "The ability to submit new assets."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:101
msgid "|image6|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:103
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:107
msgid "In the editor"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:109
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:113
msgid "|image7| |image14|"
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:116
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:122
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:125
msgid ""
"Notably, you can only fetch assets for the current version of Godot you are "
"running. Also, you can only download Projects, Demos and Templates from the "
"Project Manager view of the AssetLib, while Addons (tools, scripts, "
"materials etc.) can only be downloaded from the in-project AssetLib. 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:133
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:139
msgid "When you click on an asset, you will see more information about it."
msgstr ""

#: ../../docs/tutorials/assetlib/using_assetlib.rst:143
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:149
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:154
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:162
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:169
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 both 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 "Submitting"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:19
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:24
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:29
msgid "**Asset Name**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:29
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:35
msgid "**Category**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:32
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:41
msgid "**Godot version**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:38
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:48
msgid "**Version**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:44
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/updated."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:53
msgid "**Repository host**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:51
msgid ""
"Assets uploaded to the AssetLib are not hosted on it directly, and instead "
"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 final download link can be computed."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:56
msgid "**Repository URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:56
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:61
msgid "**Issues URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:59
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.cmo/<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:65
msgid "**Download Commit/Tag**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:64
msgid ""
"The commit or tag of the asset. For example, "
"`b1d3172f89b86e52465a74f63a74ac84c491d3e1` or `v1.0`. From this, the actual "
"download URL will be computed."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:69
msgid "**Icon URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:68
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:74
msgid "**License**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:72
msgid ""
"The license under which you are distributing the asset. The list includes a "
"variety of free and open-source software liceses, 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:80
msgid "**Description**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:77
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:82
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:86
msgid "**Type**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:87
msgid "Either an image, or a video."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:88
msgid "**Image/YouTube URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:89
msgid "Either a link to the image, or to a video, hosted on YouTube."
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:93
msgid "**Thumbnail URL**:"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:91
msgid ""
"An URL to a 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:95
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/assetlib/uploading_to_assetlib.rst:106
msgid "Submission guidelines"
msgstr ""

#: ../../docs/tutorials/assetlib/uploading_to_assetlib.rst:108
msgid "[TODO]"
msgstr ""

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

#: ../../docs/tutorials/vr/vr_primer.rst:4
msgid "An AR/VR Primer for Godot"
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_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 stereo scopic image to 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 stereo scopic 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 arvr is set to true. But for interfaces that render on an externally "
"attached device you can use a secondary viewport. In this later case a "
"viewport that shows its output on screen will show an undistorted version of "
"the left eye while showing the fully processed stereo scopic 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 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 that "
"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 origin point which you will have to adjust the "
"position of."
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 Godots 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 "
"assumes 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 it 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 then most people realise. 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 acceptable 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 foviated 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/plugins/index.rst:2
msgid "Plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/index.rst:2
msgid "Editor plugins"
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 not as powerful, there's still a lot of "
"things you can do with them. Note that a plugin is not different from any "
"scene you already can make, except that it is made via script to add "
"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 base to develop and test the plugins."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:27
msgid ""
"The first thing you need to do is to create a new plugin that the editor can "
"understand as such. For that you need two files: ``plugin.cfg`` for the "
"configuration and a custom GDScript with the functionality."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:31
msgid ""
"Plugins have a standard path like ``addons/plugin_name`` inside the project "
"folder. So create the folder ``my_custom_node`` inside ``addons``. So you'll "
"have a directory structure like this:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:37
msgid ""
"To make the ``plugin.cfg`` file, open your favorite text editor with a blank "
"file. Godot is not able (yet) to open text files besides scripts, so this "
"must be done in an external editor. Add the following structure to your "
"``plugin.cfg``::"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:50
msgid ""
"This is a simple ``ini`` file with metadata about your plugin. You need to "
"set up the name and description so users can understand what it does. Add "
"your own name so you can be properly credited. A version number is useful so "
"users can see if they have an outdated version (if you are unsure on how to "
"come up with the version number, check `SemVer <https://semver.org/>`_). And "
"finally a main script file to load when your plugin is active."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:58
msgid "The script file"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:60
msgid ""
"Open the script editor (F3) and create a new GDScript file called "
"``custom_node.gd`` inside the ``my_custom_node`` folder. This script is "
"special and it has two requirements: it must be a ``tool`` script and it has "
"to inherit from :ref:`class_EditorPlugin`."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:65
msgid ""
"It's important to deal with initialization and clean-up of resources. So a "
"good practice is to use the virtual function :ref:`_enter_tree() "
"<class_Node__enter_tree>` to initialize your plugin and :ref:`_exit_tree() "
"<class_Node__exit_tree>` to clean it up. You can delete the default GDScript "
"template from your file and replace it with the following structure:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:86
msgid "This is a good template to use when devising new plugins."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:89
msgid "A custom node"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:91
msgid ""
"Sometimes you want a certain behavior in many nodes. Maybe 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 between 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:97
msgid ""
"To create a new node type, you can avail of the function :ref:"
"`add_custom_type() <class_EditorPlugin_add_custom_type>` from the :ref:"
"`class_EditorPlugin` class. This function can add new types to the editor, "
"be it nodes or resources. But before you can create the type you need a "
"script that will act as the logic for the type. While such script doesn't "
"need to have the ``tool`` keyword, it is interesting to use it so the user "
"can see it acting on the editor."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:105
msgid ""
"For this tutorial, we'll create a simple button that prints a message when "
"clicked. And 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:119
msgid ""
"That's it for our basic button. You can save this as ``button.gd`` inside "
"the plugin folder. You'll also need a 16x16 icon to show in the scene tree. "
"If you don't have one, you can grab the default one from the engine:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:125
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:141
msgid ""
"With that done, the plugin should already be available in the plugin list at "
"Project Settings. So activate it and try to add a new node to see the result:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:146
msgid ""
"When you add the node, you can see that it already have 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 a text in the console:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:154
msgid "A custom dock"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:156
msgid ""
"Maybe 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 how to create them is not far beyond your "
"knowledge."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:160
msgid ""
"The way to start this plugin is similar to the custom node. So create a new "
"``plugin.cfg`` file in the ``addons/my_custom_dock`` folder. And then with "
"your favorite text editor add the following content to it::"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:172
msgid ""
"Then create the script ``custom_dock.gd`` in the same folder. Fill 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:176
msgid ""
"Since we're trying to add a new custom dock, we need to create the contents "
"of such dock. This is nothing more than a standard Godot scene. So you can "
"create a new scene in the editor and start creating it."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:180
msgid ""
"For an editor dock, it is mandatory that the root of the scene is a :ref:"
"`Control <class_Control>` or one of its child classes. For this tutorial, "
"you can make a single button. The name of the root node will also be the "
"name that appears on the dock tab, so be sure to put a descriptive but short "
"one. Don't forget to add a text to your button."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:188
msgid "Save this scene as ``my_dock.tscn``."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:190
msgid ""
"Now you need to grab that scene you created and add it as a dock in the "
"editor. For this you can rely on the function :ref:`add_control_to_dock() "
"<class_EditorPlugin_add_control_to_dock>` from the :ref:`EditorPlugin "
"<class_EditorPlugin>` class."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:195
msgid ""
"The code is straightforward, you need to select a dock position to add it "
"and have a control to add (which is the scene you just created). It is also "
"important that you remember to **remove the dock** when the plugin is "
"deactivated. The code can be like this::"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:220
msgid ""
"While the dock position is chosen when adding it, the user is free to move "
"it and save the layout with the dock in any position."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:224
msgid "Checking the results"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:226
msgid ""
"Now it is the moment to check the results of your work. Open the *Project "
"Settings* and click on the *Plugins* tab. Your plugin should be the only on "
"the list. If it is not showing, click on the *Update* button at the top "
"right corner."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:233
msgid ""
"At the *Status* column, you can see that the plugin is inactive. So you need "
"to click on the status to select *Active*. The dock should be immediately "
"visible, even before you close the settings window. You should have a custom "
"dock:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:241
msgid "Going beyond"
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:243
msgid ""
"Now that you learned how to make basic plugins, you can extend the editor in "
"many nice ways. Many functions can be added to editor on the fly with "
"GDScript, it is a powerful way to create special editors without having to "
"delve into C++ modules."
msgstr ""

#: ../../docs/tutorials/plugins/editor/making_plugins.rst:248
msgid ""
"You can make your own plugins to help you and also share them in Godot's "
"Asset Library so many people can benefit of your work."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:4
msgid "Import plugins"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:9
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:14
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."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:20
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:24
msgid ""
"The sample file to import contains only a line representing the pure blue "
"color (zero red, zero green, and full blue):"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:32
msgid "Configuration"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:34
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:47
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:66
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_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_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:75
msgid ""
"Note that the import plugin is a reference type  so it doesn't need to be "
"explicitly released from the 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:80
msgid "The EditorImportPlugin class"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:82
msgid ""
"The main character of the show is the :ref:`EditorImportPlugin "
"class<class_EditorImportPlugin>`. It is responsible to implement 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:87
msgid "Let's begin to code our plugin, one method at time:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:98
msgid ""
"The first method is the :ref:"
"`get_importer_name<class_EditorImportPlugin_get_importer_name>`. This is a "
"unique name to 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:109
msgid ""
"The :ref:`get_visible_name<class_EditorImportPlugin_get_visible_name>` "
"method is responsible to inform the name of the type it imports and will be "
"shown to the user in the Import dock."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:113
msgid ""
"You should choose this name as a continuation to \"Import as\". Eg. *"
"\"Import as Silly Material\"*. Yes, this one is a bit silly, but you "
"certainly can come up with a descriptive name for your plugin."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:122
msgid ""
"Godot's import system detects file types by their extension. In the :ref:"
"`get_recognized_extensions<class_EditorImportPlugin_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:128
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:138
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 inform what will be the "
"used in the import."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:144
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:154
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:158
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:161
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:166
msgid "Options and presets"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:168
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:175
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:187
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:195
msgid ""
"The :ref:`get_preset_count<class_EditorImportPlugin_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:210
msgid ""
"Here we have the :ref:"
"`get_preset_name<class_EditorImportPlugin_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:215
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:220
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:235
msgid ""
"This is the method which defines the available options. :ref:"
"`get_import_options<class_EditorImportPlugin_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:242
msgid "Key"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
msgid "``name``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:244
msgid ""
"The name of the option. When showed, underscores become spaces and first "
"letters are capitalized."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
msgid "``default_value``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
msgid "Any"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:246
msgid "The default value of the option for this preset."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
msgid "``property_hint``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
#: ../../docs/tutorials/plugins/editor/import_plugins.rst:252
msgid "Enum value"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:248
msgid ""
"One of the :ref:`PropertyHint<enum_@GlobalScope_PropertyHint>` values to use "
"as hint."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
msgid "``hint_string``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:250
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:252
msgid "``usage``"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:252
msgid ""
"One of the :ref:`PropertyUsageFlags<enum_@GlobalScope_PropertyUsageFlags>` "
"values to define the usage."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:255
msgid ""
"The ``name`` and ``default_value`` keys are **mandatory**, the rest are "
"optional."
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:257
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:263
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:273
msgid ""
"For the :ref:"
"`get_option_visibility<class_EditorImportPlugin_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:278
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:282
msgid "The ``import`` method"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:284
msgid ""
"The heavy part of the process, responsible for the converting the files into "
"resources, is covered by the :ref:`import<class_EditorImportPlugin_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:300
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:304
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:319
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:323
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:332
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:340
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:347
msgid ""
"We also return the result from the :ref:`ResourceSaver."
"save<class_ResourceSaver_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:352
msgid "Platform variants and generated files"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:354
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:359
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:364
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:368
msgid ""
"For an example, let's say we save a different material for mobile platform. "
"We would need to do something like the following:"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:376
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:381
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:397
msgid "Trying the plugin"
msgstr ""

#: ../../docs/tutorials/plugins/editor/import_plugins.rst:399
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:404
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:409
msgid ""
"Create a MeshInstance node in the scene and for it's 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:416
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:420
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/gdnative/gdnative-c-example.rst:4
msgid "GDNative C example"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:8
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:10
msgid ""
"Before we begin, you can download the source code to the example object "
"we'll be describing here by following this link: https://github.com/"
"GodotNativeTools/GDNative-demos/tree/master/c/SimpleDemo"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:13
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."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:15
msgid ""
":ref:`GDNative <class_GDNative>` can be used to create several types of "
"additions to Godot, from PluginScript to ARVR interfaces. 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 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:29
msgid ""
"We'll be writing separate tutorials on the other types of GDNative modules "
"and explain what each of them is for as we go through them."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:32
msgid "Prerequisites"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:33
msgid "Before we start you'll need a few things."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:35
msgid "A Godot 3.0 executable"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:36
msgid "A C compiler"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:37
msgid ""
"A copy of this repository: https://github.com/GodotNativeTools/godot_headers"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:39
msgid ""
"The first two pretty much speak for themselves. On Linux, you'll likely have "
"a C compiler, on macOS, it's easiest to install Xcode from the Mac App Store "
"and, on Windows, we've tested this with both MSVC 2015 and 2017."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:41
msgid ""
"For number 3, we suggest that you create a folder somewhere that you use to "
"store your code, open up a terminal and CD into that folder. Then execute:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:47
msgid "This will download the required files into that folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:49
msgid ""
"If you are building Godot from source, you may need a newer version of these "
"files. You can find this at ``<godotsource>/modules/gdnative/include``"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:52
msgid "Our C source"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:53
msgid ""
"Let's start by writing our main code. Ideally, we want to end up with a file "
"structure that looks something like this:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:71
msgid ""
"Open up Godot and create a new project called simple. This will create the "
"simple folder and project.godot file. Then manually create a bin and src "
"subfolder in this folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:73
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 you 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:75
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. I'll explain each section as we add "
"it."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:77
msgid ""
"The below code includes our header files that we need and then defines two "
"pointers to two different structs. GDNative supports a large collection for "
"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:80
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:82
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:94
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:96
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:105
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 "
"initialises our dynamic library. Godot will give it a pointer to a structure "
"that contains various bits of information we may find useful amongst which "
"the pointers to our API structures."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:107
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:125
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:134
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 Godot what objects we make "
"available to Godot."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:136
msgid ""
"We first tell Godot 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:138
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. 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:140
msgid ""
"The descriptions contain the function pointers to the functions themselves. "
"The other two fields in these structs are for specifying per-method "
"userdata. The value in the ``method_data`` field will be 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 ``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:163
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:171
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:173
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:184
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:192
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:194
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:196
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_XXX_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:198
msgid "The variant we return is destroyed automatically by Godot."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:216
msgid "And that is the whole source code of our module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:218
msgid ""
"If you add a blank .gdignore file to the src folder, Godot will not try to "
"import the compiler-generated temporary files."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:221
#: ../../docs/development/compiling/index.rst:2
#: ../../docs/development/compiling/compiling_for_windows.rst:85
#: ../../docs/development/compiling/compiling_for_x11.rst:79
#: ../../docs/development/compiling/compiling_for_osx.rst:19
#: ../../docs/development/compiling/compiling_for_ios.rst:16
#: ../../docs/development/compiling/compiling_for_uwp.rst:21
msgid "Compiling"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:222
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:224
msgid ""
"Assuming you are sticking to the folder structure suggested above it is best "
"to CD into the src subfolder in a terminal session 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:226
msgid "On Linux:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:233
msgid "On Mac OS X:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:240
msgid "On Windows:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:247
msgid ""
"Note that 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 bonus 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:250
msgid "Creating our GDNLIB file"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:251
msgid ""
"With our module compiled we now need to create a gdnlib file for our module "
"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. "
"At the time of writing this tutorial work is still being done on making this "
"configurable from within Godot so for now grab your favourite text editor, "
"create a file called libsimple.gdnlib and add the following into this file:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:273
msgid "This file contains 3 sections."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:275
msgid ""
"The **general** section contains some info that tells Godot how to use our "
"module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:277
msgid ""
"If singleton is true our library is automatically loaded and a function "
"called godot_singleton_init is called. We'll leave that for another tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:279
msgid ""
"If load_once is true 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 false a new copy of the library is loaded into memory each time "
"a script access the library."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:281
msgid ""
"The symbol_prefix is a prefix for our core functions. So the godot in "
"godot_nativescript_init for instance. If you use multiple GDnative libraries "
"that you wish to statically link you'll 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:283
msgid ""
"The **entry** section 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:285
msgid ""
"The **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:288
msgid "Putting it all together"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:289
msgid ""
"Now that we should have a working GDNative library it is time to fire up "
"Godot and use it. Open up the sample project if you haven't left it open "
"after creating the project all the way at the beginning of this tutorial."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:292
msgid "Creating our GDNS file"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:293
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. This we do by creating a GDNS "
"resource file."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:295
msgid "Start by clicking the create resource button in the Inspector:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:299
msgid "And select NativeScript:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:303
msgid ""
"Press Create, now the inspector will show a few fields we need to enter. In "
"Class Name we enter \"SIMPLE\" which is the object class name we used 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:307
msgid "Finally click on the save icon and save this as bin/Simple.gdns:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:311
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 subnodes. Place them "
"somewhere nice on screen and give your button a name."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:315
msgid "Select the control node and create a script for the control node:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:319
msgid "Next link up the pressed signal on the button to your script:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:323
msgid "Don't forget to save your scene, call it main.tscn."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:325
msgid "Now we can implement our main.gd code:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-c-example.rst:337
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:8
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:10
msgid ""
"The C++ bindings for GDNative are build on top of the nativescript GDNative "
"API and provide a nicer way to \"extend\" nodes in Godot using C++. "
"Basically this is the equivalent to writing GDScript scripts but in C++."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:12
msgid ""
"We'll be looking at nativescript 1.0 which is available in Godot 3.0. Godot "
"3.1 will see the introduction of nativescript 1.1 which has a number of "
"improvements. We'll update this tutorial once that is officially released "
"but the overal structure is much the same."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:14
msgid ""
"You can download the full example we'll be creating in this tutorial here: "
"https://github.com/BastiaanOlij/gdnative_cpp_example"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:17
msgid "Setting up your project"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:18
msgid "There are a few prerequisites you'll need:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:20
msgid "A Godot 3.x executable"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:21
msgid "a C++ compiler"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:22
msgid "scons as a build tool"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:23
msgid ""
"a copy of the godot_headers repository you can find here: https://github.com/"
"GodotNativeTools/godot_headers"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:24
msgid ""
"a copy of the godot_cpp repository you can find here: https://github.com/"
"GodotNativeTools/godot-cpp"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:26
msgid ""
"See also http://docs.godotengine.org/en/latest/development/compiling/index."
"html as the build tools are identical to those you need to compile Godot "
"from source."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:28
msgid ""
"You can just download these repositories from GitHub or let git do all the "
"work for you. I've started to submodule them into my project folder. This is "
"how I usually start my projects:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:38
msgid ""
"You don't have to do it this way but I've found it easiest to manage. If you "
"decide to just download the repositories or just clone them into your "
"folder, makes sure to keep the folder layout the same as I'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:40
msgid ""
"If you downloaded or cloned my example from the link specified in the "
"introduction the submodules aren't automatically included. You will need to "
"execute the following:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:48
msgid ""
"This will trigger downloading these two repositories into your project "
"folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:51
msgid "Building the C++ bindings"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:52
msgid ""
"Now that we've downloaded our prerequisites it is time to build our C++ "
"bindings."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:54
msgid ""
"Now the repository contains a copy of the meta data for the current Godot "
"release but if you need to build these bindings for a newer version of Godot "
"you simply call the godot executable:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:60
msgid "And place the resulting godot_api.json file in our godot-cpp folder."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:62
msgid ""
"Now to generate and compile our bindings we do (do chose either Windows, "
"Linux or OSX):"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:70
msgid ""
"This step will take a while but at the end of it, you should have static "
"libraries you can compile into your project stored in godot-cpp/bin."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:72
msgid ""
"At some point we'll probably start making compiled binaries available for "
"download so you can skip this whole section."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:75
msgid "Creating a simple plugin"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:76
msgid "Now it's time to build an actual plugin."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:78
msgid ""
"To start we want to create an empty Godot project in which we'll be able to "
"place a few files so open up Godot and create a new project. I like to place "
"an demo project in my repository that shows how my GDNative module works so "
"for our example we'll create a project in a folder called \"demo\" inside of "
"our GDNative modules folder structure."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:80
msgid ""
"Inside our demo we'll create a scene with a single Node of type Node called "
"\"Main\" and we'll save this as main.tscn. We'll come back to that later."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:82
msgid ""
"Back in the top-level gdnative module folder, we're also going to create a "
"subfolder called ``src`` into which we'll place our source files."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:84
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:86
msgid ""
"In the ``src`` folder, we'll start with creating our header file for the "
"GDNative node we'll be creating. This we'll call ``gdexample.h``:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:117
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 includes the bindings to our sprite class. This class we'll be "
"extending in our module."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:120
msgid ""
"We're using the namespace ``godot``, everything in GDNative is defined "
"within this namespace."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:122
msgid ""
"Then we have our class definition and we see that we're inheriting from our "
"Sprite but through a container class. We'll see a few side effects from this "
"later on. This is also the main bit that is going to improve in nativescript "
"1.1. The GODOT_CLASS macro sets up a few internal things for us."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:125
msgid "After that we declare a single member variables called ``time_passed``."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:127
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."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:129
msgid ""
"The first is ``_register_methods`` which is a static function that Godot "
"will call to find out what our methods can be called on our native_script "
"and what properties it has. The second is our ``_process`` function which "
"will work exactly the same as the ``_process`` function you're used to using "
"in GDScript."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:132
msgid ""
"So, let's implement our functions by creating our ``gdexample.cpp`` file:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:161
msgid ""
"This one should be straight forward. We're implementing each method of our "
"class that we defined in our header file. Of note is the ``register_method`` "
"call that informs Godot that we have a ``_process`` method. We do not have "
"to tell Godot about our constructor nor destructor."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:163
msgid ""
"The other method of note is our ``_process`` function where I'm simply "
"keeping track of how much time has passed and calculating a new position for "
"our sprite using a simple sine and cosine function. What does stand 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 and owner points to "
"the actual sprite node our script relates to. Once we can use nativescript "
"1.1 we'll be able to call ``set_position`` directly on our class."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:167
msgid ""
"Now there is one more C++ file we need that we call ``gdlibrary.cpp``. Our "
"GDNative plugin can contain multiple native_scripts each one with their own "
"header and source file like we've implemented ``gdexample`` up above. What "
"we now need is a small bit of code that tells Godot about all the "
"native_scripts in our GDNative plugin."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:187
msgid ""
"Note that we are not using our namespace here because the three functions "
"implemented here need to be defined without a namespace."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:189
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 to the functions in our bindings module "
"that does some initialisation for us but you might have a need to setup more "
"things."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:191
msgid ""
"The important function is the third function called "
"``godot_nativescript_init``. Again 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:195
msgid "Compiling our plugin"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:197
msgid ""
"We can't really make pretty the ``SConstruct`` files used for building in "
"scons. For the purpose of this example, just use this hardcoded build file "
"we've prepared. We'll cover a more customizable, detailed example on how to "
"use these build files in a subsequent tutorial: :download:`SConstruct <files/"
"cpp_example/SConstruct>`"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:199
msgid ""
"Once you've downloaded the ``SConstruct`` file, place it in your gdnative "
"module folder, beside ``godot-cpp``, ``godot_headers``, and ``demo``. Next "
"just run:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:205
msgid ""
"And our module should compile. You should now be able to find your module in "
"``demo/bin/<platform>``"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:207
msgid ""
"**Note**, we've compiled both godot-cpp and our gdexample library as debug "
"builds. For release you should recompile them using the ``target=release`` "
"switch."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:210
msgid "Using your GDNative module"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:212
msgid ""
"Before we jump back into Godot we need to create two more files in ``demo/"
"bin/`` . Both can now be created through the interface in Godot but I find "
"it easier to just create them directly."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:214
msgid ""
"The first 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:236
msgid ""
"So what's in this file? Well there is a ``general`` section that controls "
"how our module is loaded. It also contains a prefix section which we should "
"leave 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 "
"and GDNative modules are statically linked."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:238
msgid ""
"The ``entry`` section is the important bit, it tells Godot for each platform "
"we support where our dynamic library is on disk. It will also result in just "
"that file being exported when you export your game."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:240
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 elses library and requires you to supply "
"a 3rd party dynamic library with your game."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:242
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:246
msgid ""
"The second file we need to create is a file we need to create for each "
"native_script we've added to our plugin. We name it ``gdexample.gdns`` for "
"our gdexample native_script."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:261
msgid ""
"This is a standard Godot resource and you could just create that directly "
"inside of your scene but having this as a resource file makes life a lot "
"easier in (re)using your native_script. The important bits here are that "
"we're pointing to our gdnlib file so Godot knows which dynamic library "
"contains our native_script, and the ``class_name`` which identifies the "
"native_script in our plugin we want to use."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:264
msgid ""
"Ok, we're all setup. Time to jump back into Godot. We load up the main scene "
"we created way back in the beginning and now we add a Sprite to our scene:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:268
msgid ""
"We're going to assign our Godot logo to this sprite as our texture, turn off "
"centered, and drag our ``gdexample.gdns`` file onto the script property of "
"our sprite:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:272
msgid "And we're ready to run our project:"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:277
msgid "Next steps"
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:278
msgid ""
"Obviously the above is a very basic example just to get you setup but we "
"hope it shows the basics. You can build upon this example to create full "
"fledged scripts to control the nodes in Godot but using C++ as the language."
msgstr ""

#: ../../docs/tutorials/plugins/gdnative/gdnative-cpp-example.rst:280
msgid ""
"You should be able to edit and recompile your plugin while the Godot editor "
"remains open and just rerun the project."
msgstr ""

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

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:4
msgid "Android in-app purchases"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:8
msgid ""
"Godot engine has integrated GooglePaymentsV3 module with which we can "
"implement in-app purchases in our game."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:10
msgid ""
"The Godot engine demo project repository has an android-iap example project. "
"It includes a gdscript interface for android IAP."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:12
msgid ""
"Check the repository here https://github.com/godotengine/godot-demo-projects"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:14
msgid "Find the iap.gd script in"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:21
msgid ""
"Add it to the Autoload list and name it as IAP so that we can reference it "
"anywhere in the game."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:24
msgid "Getting the product details"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:26
msgid ""
"When starting our game, we will need to get the item details from Google "
"such as the product price, description and localized price string etc."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:42
msgid ""
"We can use the IAP details to display the title, price and/or description on "
"our shop scene."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:45
msgid "Check if user purchased an item"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:47
msgid ""
"When starting our game, we can check if the user has purchased any product. "
"YOU SHOULD DO THIS ONLY AFTER 2/3 SECONDS AFTER YOUR GAME IS LOADED. If we "
"do this as the first thing when the game is launched, IAP might not be "
"initialized and our game will crash on start."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:60
msgid ""
"Google IAP policy says the game should restore the user's purchases if the "
"user replaces their phone or reinstalls the same app. We can use the above "
"code to check what products the user has purchased and we can make our game "
"respond accordingly."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:63
msgid "Simple Purchase"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:65
msgid "We can put this purchase logic on a product's buy button."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:80
msgid ""
"We can also implement other signals for the purchase flow and improve the "
"user experience as you needed."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:82
msgid "``purchase_fail`` - When the purchase is failed due to any reason"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:84
msgid "``purchase_cancel`` - When the user cancels the purchase"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:86
msgid "``purchase_owned`` - When the user already bought the product earlier"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:90
msgid "Consumables and Non-Consumables"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:92
msgid ""
"There are two types of products - consumables and non-consumables. "
"**Consumables** are purchased and used, for eg: healing potions which can be "
"purchased again and again. **Non-consumables** are one time purchases, for "
"eg: Level packs."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:96
msgid ""
"Google doesn't have this separation in their dashboard. If our product is a "
"consumable, and if a user has purchased it, it will not be available for "
"purchase until it is consumed. So we should call the consume method for our "
"consumables and don't call consume for your non-consumables."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:106
msgid ""
"If our game has only consumables, we don't have to do this. We can set it to "
"consume the item automatically after a purchase."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:112
msgid "If our game has only non-consumables, we can"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:118
msgid "We should set the auto consume value only once when the game starts."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:121
msgid "Testing"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:123
msgid ""
"If we add a gmail id as a tester in Google dashboard, that tester can "
"purchase items and they will not be charged. Another way to test IAP is "
"using redeem codes generated by us for our game because the purchase flow is "
"the same."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:125
msgid ""
"Third way of testing is in development side. If we put the product ids as "
"shown below, we will get a static fixed response according to the product "
"id. This is a quick way of testing things before going to the dashboard."
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:127
msgid "android.test.purchased"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:128
msgid "android.test.canceled"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:129
msgid "android.test.refunded"
msgstr ""

#: ../../docs/tutorials/platform/android_in_app_purchases.rst:130
msgid "android.test.item_unavailable"
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 "
"two 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:73
msgid "and the pending_event interface"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:81
msgid "purchase"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:83
msgid "Purchases a product id through the Store Kit API."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:88
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:96
#: ../../docs/tutorials/platform/services_for_ios.rst:136
#: ../../docs/tutorials/platform/services_for_ios.rst:190
#: ../../docs/tutorials/platform/services_for_ios.rst:237
#: ../../docs/tutorials/platform/services_for_ios.rst:266
#: ../../docs/tutorials/platform/services_for_ios.rst:296
#: ../../docs/tutorials/platform/services_for_ios.rst:328
#: ../../docs/tutorials/platform/services_for_ios.rst:385
msgid "Response event"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:98
#: ../../docs/tutorials/platform/services_for_ios.rst:138
#: ../../docs/tutorials/platform/services_for_ios.rst:192
#: ../../docs/tutorials/platform/services_for_ios.rst:239
#: ../../docs/tutorials/platform/services_for_ios.rst:268
#: ../../docs/tutorials/platform/services_for_ios.rst:298
#: ../../docs/tutorials/platform/services_for_ios.rst:330
#: ../../docs/tutorials/platform/services_for_ios.rst:387
msgid "The response event will be a dictionary with the following fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:100
#: ../../docs/tutorials/platform/services_for_ios.rst:194
#: ../../docs/tutorials/platform/services_for_ios.rst:241
#: ../../docs/tutorials/platform/services_for_ios.rst:270
#: ../../docs/tutorials/platform/services_for_ios.rst:300
#: ../../docs/tutorials/platform/services_for_ios.rst:332
msgid "On error:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:110
#: ../../docs/tutorials/platform/services_for_ios.rst:205
#: ../../docs/tutorials/platform/services_for_ios.rst:251
#: ../../docs/tutorials/platform/services_for_ios.rst:280
#: ../../docs/tutorials/platform/services_for_ios.rst:310
#: ../../docs/tutorials/platform/services_for_ios.rst:342
msgid "On success:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:121
msgid "request_product_info"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:123
msgid "Requests the product info on a list of product IDs."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:128
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:154
msgid "Game Center"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:156
msgid "Implemented in platform/iphone/game_center.mm"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:158
msgid ""
"The Game Center API is available through the \"GameCenter\" singleton. It "
"has 6 methods:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:161
msgid "``Error post_score(Variant p_score);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:162
msgid "``Erroraward_achievement(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:163
msgid "``Error reset_achievements();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:164
msgid "``Error request_achievements();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:165
msgid "``Error request_achievement_descriptions();``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:166
msgid "``Error show_game_center(Variant p_params);``"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:168
msgid "plus the standard pending event interface."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:171
msgid "post_score"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:173
msgid "Posts a score to a Game Center leaderboard."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:178
#: ../../docs/tutorials/platform/services_for_ios.rst:367
msgid "Takes a Dictionary as a parameter, with two fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:180
msgid "``score`` a float number"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:181
msgid "``category`` a string with the category name"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:215
msgid "award_achievement"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:217
msgid "Modifies the progress of a Game Center achievement."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:222
msgid "Takes a Dictionary as a parameter, with 3 fields:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:224
msgid "``name`` (string) the achievement name"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:225
msgid ""
"``progress`` (float) the achievement progress from 0.0 to 100.0 (passed to "
"``GKAchievement::percentComplete``)"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:227
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:261
msgid "reset_achievements"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:263
msgid "Clears all Game Center achievements. The function takes no parameters."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:290
msgid "request_achievements"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:292
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:322
msgid "request_achievement_descriptions"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:324
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:359
msgid "show_game_center"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:361
msgid ""
"Displays the built in Game Center overlay showing leaderboards, "
"achievements, and challenges."
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:369
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:372
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:377
msgid "Examples:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:389
msgid "On close:"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:399
msgid "Multi-platform games"
msgstr ""

#: ../../docs/tutorials/platform/services_for_ios.rst:401
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/consoles.rst:4
msgid "Console Support in Godot"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:7
msgid "Official Support"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:9
msgid ""
"Godot does not officially support consoles (save for XBox One via UWP) "
"currently."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:11
msgid "The reasons for this are:"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:13
msgid ""
"To develop for consoles, one must be licensed as a company. Godot, as an "
"open source project, does not have such a legal figure."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:14
msgid ""
"Console SDKs are secret, and protected by non-disclosure agreements. Even if "
"we could get access to them, we could not publish the code as open-source."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:15
msgid ""
"Consoles require specialized hardware to develop for, so regular individuals "
"can't create games for them anyway."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:17
msgid ""
"This, however, does not mean you can't port your games to consoles. Quite "
"the contrary."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:20
msgid "Third-Party Support"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:22
msgid ""
"Console ports of Godot are offered via third party companies (which have "
"ported Godot on their own) and offer porting and publishing services of your "
"games to consoles."
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:26
msgid "Following is the list of providers:"
msgstr ""

#: ../../docs/tutorials/platform/consoles.rst:28
msgid ""
"`Lone Wolf Technology <http://www.lonewolftechnology.com/>`_ offers Switch, "
"PS4 and XBox One porting and publishing of Godot games."
msgstr ""

#: ../../docs/tutorials/misc/index.rst:2
msgid "Miscellaneous"
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 titlebar. "
"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 ""
"The :ref:`MainLoop <class_MainLoop>` has a special notification that is sent "
"to all nodes when quit is requested: MainLoop.NOTIFICATION_WM_QUIT."
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:21
msgid "Handling it is done as follows (on any node):"
msgstr ""

#: ../../docs/tutorials/misc/handling_quit_requests.rst:38
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:41
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_paused>` member "
"variable:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:35
msgid "Doing so will have the following behavior:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:37
msgid "2D and 3D physics will be stopped."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:38
msgid "_process and _physics_process will not be called anymore in nodes."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:39
msgid "_input and _input_event will not be called anymore either."
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:41
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:46
msgid "White-listing nodes"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:48
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:54
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:62
msgid "So the three possible states for a node are:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:64
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:66
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:68
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:74
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:79
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:83
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:101
msgid "To remove the pause, do the opposite when the pause screen is closed:"
msgstr ""

#: ../../docs/tutorials/misc/pausing_games.rst:119
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:23
msgid "Value"
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:387
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:149
#: ../../docs/tutorials/misc/binary_serialization_api.rst:164
#: ../../docs/tutorials/misc/binary_serialization_api.rst:177
#: ../../docs/tutorials/misc/binary_serialization_api.rst:196
#: ../../docs/tutorials/misc/binary_serialization_api.rst:211
#: ../../docs/tutorials/misc/binary_serialization_api.rst:226
#: ../../docs/tutorials/misc/binary_serialization_api.rst:245
#: ../../docs/tutorials/misc/binary_serialization_api.rst:270
#: ../../docs/tutorials/misc/binary_serialization_api.rst:301
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:151
#: ../../docs/tutorials/misc/binary_serialization_api.rst:179
#: ../../docs/tutorials/misc/binary_serialization_api.rst:198
#: ../../docs/tutorials/misc/binary_serialization_api.rst:213
#: ../../docs/tutorials/misc/binary_serialization_api.rst:228
#: ../../docs/tutorials/misc/binary_serialization_api.rst:247
#: ../../docs/tutorials/misc/binary_serialization_api.rst:272
#: ../../docs/tutorials/misc/binary_serialization_api.rst:303
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:181
#: ../../docs/tutorials/misc/binary_serialization_api.rst:230
#: ../../docs/tutorials/misc/binary_serialization_api.rst:249
#: ../../docs/tutorials/misc/binary_serialization_api.rst:274
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:183
#: ../../docs/tutorials/misc/binary_serialization_api.rst:232
#: ../../docs/tutorials/misc/binary_serialization_api.rst:251
#: ../../docs/tutorials/misc/binary_serialization_api.rst:276
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:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:86
msgid "0: null"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:89
msgid "1: :ref:`bool<class_bool>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:92
#: ../../docs/tutorials/misc/binary_serialization_api.rst:101
#: ../../docs/tutorials/misc/binary_serialization_api.rst:110
#: ../../docs/tutorials/misc/binary_serialization_api.rst:119
#: ../../docs/tutorials/misc/binary_serialization_api.rst:132
#: ../../docs/tutorials/misc/binary_serialization_api.rst:143
#: ../../docs/tutorials/misc/binary_serialization_api.rst:158
#: ../../docs/tutorials/misc/binary_serialization_api.rst:171
#: ../../docs/tutorials/misc/binary_serialization_api.rst:190
#: ../../docs/tutorials/misc/binary_serialization_api.rst:205
#: ../../docs/tutorials/misc/binary_serialization_api.rst:220
#: ../../docs/tutorials/misc/binary_serialization_api.rst:239
#: ../../docs/tutorials/misc/binary_serialization_api.rst:264
#: ../../docs/tutorials/misc/binary_serialization_api.rst:295
#: ../../docs/tutorials/misc/binary_serialization_api.rst:310
#: ../../docs/tutorials/misc/binary_serialization_api.rst:319
#: ../../docs/tutorials/misc/binary_serialization_api.rst:330
#: ../../docs/tutorials/misc/binary_serialization_api.rst:340
#: ../../docs/tutorials/misc/binary_serialization_api.rst:359
#: ../../docs/tutorials/misc/binary_serialization_api.rst:371
#: ../../docs/tutorials/misc/binary_serialization_api.rst:383
#: ../../docs/tutorials/misc/binary_serialization_api.rst:396
#: ../../docs/tutorials/misc/binary_serialization_api.rst:407
#: ../../docs/tutorials/misc/binary_serialization_api.rst:418
#: ../../docs/tutorials/misc/binary_serialization_api.rst:426
#: ../../docs/tutorials/misc/binary_serialization_api.rst:439
#: ../../docs/tutorials/misc/binary_serialization_api.rst:452
#: ../../docs/tutorials/misc/binary_serialization_api.rst:467
msgid "Offset"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:92
#: ../../docs/tutorials/misc/binary_serialization_api.rst:101
#: ../../docs/tutorials/misc/binary_serialization_api.rst:110
#: ../../docs/tutorials/misc/binary_serialization_api.rst:119
#: ../../docs/tutorials/misc/binary_serialization_api.rst:132
#: ../../docs/tutorials/misc/binary_serialization_api.rst:143
#: ../../docs/tutorials/misc/binary_serialization_api.rst:158
#: ../../docs/tutorials/misc/binary_serialization_api.rst:171
#: ../../docs/tutorials/misc/binary_serialization_api.rst:190
#: ../../docs/tutorials/misc/binary_serialization_api.rst:205
#: ../../docs/tutorials/misc/binary_serialization_api.rst:220
#: ../../docs/tutorials/misc/binary_serialization_api.rst:239
#: ../../docs/tutorials/misc/binary_serialization_api.rst:264
#: ../../docs/tutorials/misc/binary_serialization_api.rst:295
#: ../../docs/tutorials/misc/binary_serialization_api.rst:310
#: ../../docs/tutorials/misc/binary_serialization_api.rst:319
#: ../../docs/tutorials/misc/binary_serialization_api.rst:330
#: ../../docs/tutorials/misc/binary_serialization_api.rst:340
#: ../../docs/tutorials/misc/binary_serialization_api.rst:359
#: ../../docs/tutorials/misc/binary_serialization_api.rst:371
#: ../../docs/tutorials/misc/binary_serialization_api.rst:383
#: ../../docs/tutorials/misc/binary_serialization_api.rst:396
#: ../../docs/tutorials/misc/binary_serialization_api.rst:407
#: ../../docs/tutorials/misc/binary_serialization_api.rst:418
#: ../../docs/tutorials/misc/binary_serialization_api.rst:426
#: ../../docs/tutorials/misc/binary_serialization_api.rst:439
#: ../../docs/tutorials/misc/binary_serialization_api.rst:452
#: ../../docs/tutorials/misc/binary_serialization_api.rst:467
msgid "Len"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:94
msgid "0 for False, 1 for True"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:98
msgid "2: :ref:`int<class_int>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:103
msgid "Signed, 32-Bit Integer"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:107
msgid "3: :ref:`float<class_float>`/real"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:112
#: ../../docs/tutorials/misc/binary_serialization_api.rst:134
#: ../../docs/tutorials/misc/binary_serialization_api.rst:136
#: ../../docs/tutorials/misc/binary_serialization_api.rst:145
#: ../../docs/tutorials/misc/binary_serialization_api.rst:147
#: ../../docs/tutorials/misc/binary_serialization_api.rst:149
#: ../../docs/tutorials/misc/binary_serialization_api.rst:151
#: ../../docs/tutorials/misc/binary_serialization_api.rst:160
#: ../../docs/tutorials/misc/binary_serialization_api.rst:162
#: ../../docs/tutorials/misc/binary_serialization_api.rst:164
#: ../../docs/tutorials/misc/binary_serialization_api.rst:173
#: ../../docs/tutorials/misc/binary_serialization_api.rst:175
#: ../../docs/tutorials/misc/binary_serialization_api.rst:177
#: ../../docs/tutorials/misc/binary_serialization_api.rst:179
#: ../../docs/tutorials/misc/binary_serialization_api.rst:181
#: ../../docs/tutorials/misc/binary_serialization_api.rst:183
#: ../../docs/tutorials/misc/binary_serialization_api.rst:192
#: ../../docs/tutorials/misc/binary_serialization_api.rst:194
#: ../../docs/tutorials/misc/binary_serialization_api.rst:196
#: ../../docs/tutorials/misc/binary_serialization_api.rst:198
#: ../../docs/tutorials/misc/binary_serialization_api.rst:207
#: ../../docs/tutorials/misc/binary_serialization_api.rst:209
#: ../../docs/tutorials/misc/binary_serialization_api.rst:211
#: ../../docs/tutorials/misc/binary_serialization_api.rst:213
#: ../../docs/tutorials/misc/binary_serialization_api.rst:222
#: ../../docs/tutorials/misc/binary_serialization_api.rst:224
#: ../../docs/tutorials/misc/binary_serialization_api.rst:226
#: ../../docs/tutorials/misc/binary_serialization_api.rst:228
#: ../../docs/tutorials/misc/binary_serialization_api.rst:230
#: ../../docs/tutorials/misc/binary_serialization_api.rst:232
#: ../../docs/tutorials/misc/binary_serialization_api.rst:241
#: ../../docs/tutorials/misc/binary_serialization_api.rst:243
#: ../../docs/tutorials/misc/binary_serialization_api.rst:245
#: ../../docs/tutorials/misc/binary_serialization_api.rst:247
#: ../../docs/tutorials/misc/binary_serialization_api.rst:249
#: ../../docs/tutorials/misc/binary_serialization_api.rst:251
#: ../../docs/tutorials/misc/binary_serialization_api.rst:253
#: ../../docs/tutorials/misc/binary_serialization_api.rst:255
#: ../../docs/tutorials/misc/binary_serialization_api.rst:257
#: ../../docs/tutorials/misc/binary_serialization_api.rst:266
#: ../../docs/tutorials/misc/binary_serialization_api.rst:268
#: ../../docs/tutorials/misc/binary_serialization_api.rst:270
#: ../../docs/tutorials/misc/binary_serialization_api.rst:272
#: ../../docs/tutorials/misc/binary_serialization_api.rst:274
#: ../../docs/tutorials/misc/binary_serialization_api.rst:276
#: ../../docs/tutorials/misc/binary_serialization_api.rst:278
#: ../../docs/tutorials/misc/binary_serialization_api.rst:280
#: ../../docs/tutorials/misc/binary_serialization_api.rst:282
#: ../../docs/tutorials/misc/binary_serialization_api.rst:284
#: ../../docs/tutorials/misc/binary_serialization_api.rst:286
#: ../../docs/tutorials/misc/binary_serialization_api.rst:288
#: ../../docs/tutorials/misc/binary_serialization_api.rst:297
#: ../../docs/tutorials/misc/binary_serialization_api.rst:299
#: ../../docs/tutorials/misc/binary_serialization_api.rst:301
#: ../../docs/tutorials/misc/binary_serialization_api.rst:303
#: ../../docs/tutorials/misc/binary_serialization_api.rst:443
#: ../../docs/tutorials/misc/binary_serialization_api.rst:445
#: ../../docs/tutorials/misc/binary_serialization_api.rst:456
#: ../../docs/tutorials/misc/binary_serialization_api.rst:458
#: ../../docs/tutorials/misc/binary_serialization_api.rst:460
#: ../../docs/tutorials/misc/binary_serialization_api.rst:471
#: ../../docs/tutorials/misc/binary_serialization_api.rst:473
#: ../../docs/tutorials/misc/binary_serialization_api.rst:475
#: ../../docs/tutorials/misc/binary_serialization_api.rst:477
msgid "Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:112
msgid "IEE 754 32-Bits Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:116
msgid "4: :ref:`String<class_string>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:121
msgid "String Length (in Bytes)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:123
#: ../../docs/tutorials/misc/binary_serialization_api.rst:321
#: ../../docs/tutorials/misc/binary_serialization_api.rst:344
#: ../../docs/tutorials/misc/binary_serialization_api.rst:430
msgid "X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:123
#: ../../docs/tutorials/misc/binary_serialization_api.rst:321
#: ../../docs/tutorials/misc/binary_serialization_api.rst:344
#: ../../docs/tutorials/misc/binary_serialization_api.rst:430
msgid "Bytes"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:123
#: ../../docs/tutorials/misc/binary_serialization_api.rst:321
#: ../../docs/tutorials/misc/binary_serialization_api.rst:344
#: ../../docs/tutorials/misc/binary_serialization_api.rst:430
msgid "UTF-8 Encoded String"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:126
msgid "This field is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:129
msgid "5: :ref:`Vector2<class_vector2>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:134
#: ../../docs/tutorials/misc/binary_serialization_api.rst:145
#: ../../docs/tutorials/misc/binary_serialization_api.rst:160
#: ../../docs/tutorials/misc/binary_serialization_api.rst:222
#: ../../docs/tutorials/misc/binary_serialization_api.rst:443
#: ../../docs/tutorials/misc/binary_serialization_api.rst:456
msgid "X Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:136
#: ../../docs/tutorials/misc/binary_serialization_api.rst:147
#: ../../docs/tutorials/misc/binary_serialization_api.rst:162
#: ../../docs/tutorials/misc/binary_serialization_api.rst:224
#: ../../docs/tutorials/misc/binary_serialization_api.rst:445
#: ../../docs/tutorials/misc/binary_serialization_api.rst:458
msgid "Y Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:140
msgid "6: :ref:`Rect2<class_rect2>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:149
#: ../../docs/tutorials/misc/binary_serialization_api.rst:228
msgid "X Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:151
#: ../../docs/tutorials/misc/binary_serialization_api.rst:230
msgid "Y Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:155
msgid "7: :ref:`Vector3<class_vector3>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:164
#: ../../docs/tutorials/misc/binary_serialization_api.rst:226
#: ../../docs/tutorials/misc/binary_serialization_api.rst:460
msgid "Z Coordinate"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:168
msgid "8: :ref:`Transform2D<class_transform2d>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:173
#: ../../docs/tutorials/misc/binary_serialization_api.rst:241
#: ../../docs/tutorials/misc/binary_serialization_api.rst:266
msgid "[0][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:175
#: ../../docs/tutorials/misc/binary_serialization_api.rst:243
#: ../../docs/tutorials/misc/binary_serialization_api.rst:268
msgid "[0][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:177
#: ../../docs/tutorials/misc/binary_serialization_api.rst:247
#: ../../docs/tutorials/misc/binary_serialization_api.rst:272
msgid "[1][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:179
#: ../../docs/tutorials/misc/binary_serialization_api.rst:249
#: ../../docs/tutorials/misc/binary_serialization_api.rst:274
msgid "[1][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:181
#: ../../docs/tutorials/misc/binary_serialization_api.rst:253
#: ../../docs/tutorials/misc/binary_serialization_api.rst:278
msgid "[2][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:183
#: ../../docs/tutorials/misc/binary_serialization_api.rst:255
#: ../../docs/tutorials/misc/binary_serialization_api.rst:280
msgid "[2][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:187
msgid "9: :ref:`Plane<class_plane>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:192
msgid "Normal X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:194
msgid "Normal Y"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:196
msgid "Normal Z"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:198
msgid "Distance"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:202
msgid "10: :ref:`Quat<class_quat>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:207
msgid "Imaginary X"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:209
msgid "Imaginary Y"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:211
msgid "Imaginary Z"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:213
msgid "Real W"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:217
msgid "11: :ref:`AABB<class_aabb>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:232
msgid "Z Size"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:236
msgid "12: :ref:`Basis<class_basis>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:245
#: ../../docs/tutorials/misc/binary_serialization_api.rst:270
msgid "[0][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:251
#: ../../docs/tutorials/misc/binary_serialization_api.rst:276
msgid "[1][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:253
#: ../../docs/tutorials/misc/binary_serialization_api.rst:278
msgid "28"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:255
#: ../../docs/tutorials/misc/binary_serialization_api.rst:280
msgid "32"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:257
#: ../../docs/tutorials/misc/binary_serialization_api.rst:282
msgid "36"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:257
#: ../../docs/tutorials/misc/binary_serialization_api.rst:282
msgid "[2][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:261
msgid "13: :ref:`Transform<class_transform>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:284
msgid "40"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:284
msgid "[3][0]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:286
msgid "44"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:286
msgid "[3][1]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:288
msgid "48"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:288
msgid "[3][2]"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:292
msgid "14: :ref:`Color<class_color>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:297
#: ../../docs/tutorials/misc/binary_serialization_api.rst:471
msgid "Red (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:299
#: ../../docs/tutorials/misc/binary_serialization_api.rst:473
msgid "Green (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:301
#: ../../docs/tutorials/misc/binary_serialization_api.rst:475
msgid "Blue (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:303
#: ../../docs/tutorials/misc/binary_serialization_api.rst:477
msgid "Alpha (0..1)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:307
msgid "15: :ref:`NodePath<class_nodepath>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:312
msgid ""
"String Length, or New Format (val&0x80000000!=0 and NameCount=val&0x7FFFFFFF)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:316
msgid "For old format:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:324
msgid "Padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:327
msgid "For new format:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:332
msgid "Sub-Name Count"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:334
msgid "Flags (absolute: val&1 != 0 )"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:337
msgid "For each Name and Sub-Name"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:342
#: ../../docs/tutorials/misc/binary_serialization_api.rst:428
msgid "X+0"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:342
#: ../../docs/tutorials/misc/binary_serialization_api.rst:428
msgid "String Length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:344
#: ../../docs/tutorials/misc/binary_serialization_api.rst:430
msgid "X+4"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:347
msgid "Every name string is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:350
msgid "16: :ref:`RID<class_rid>` (unsupported)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:353
msgid "17: :ref:`Object<class_object>` (unsupported)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:356
msgid "18: :ref:`Dictionary<class_dictionary>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:361
#: ../../docs/tutorials/misc/binary_serialization_api.rst:373
msgid "val&0x7FFFFFFF = elements, val&0x80000000 = shared (bool)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:364
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:368
msgid "19: :ref:`Array<class_array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:376
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:380
msgid "20: :ref:`PoolByteArray<class_poolbytearray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:385
msgid "Array Length (Bytes)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:387
msgid "8..8+length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:387
msgid "Byte"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:387
msgid "Byte (0..255)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:390
msgid "The array data is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:393
msgid "21: :ref:`PoolIntArray<class_poolintarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:398
msgid "Array Length (Integers)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:400
#: ../../docs/tutorials/misc/binary_serialization_api.rst:411
msgid "8..8+length\\*4"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:400
msgid "32 Bits Signed Integer"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:404
msgid "22: :ref:`PoolRealArray<class_poolrealarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:409
msgid "Array Length (Floats)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:411
msgid "32 Bits IEE 754 Float"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:415
msgid "23: :ref:`PoolStringArray<class_poolstringarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:420
msgid "Array Length (Strings)"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:423
msgid "For each String:"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:433
msgid "Every string is padded to 4 bytes."
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:436
msgid "24: :ref:`PoolVector2Array<class_poolvector2array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:441
#: ../../docs/tutorials/misc/binary_serialization_api.rst:454
#: ../../docs/tutorials/misc/binary_serialization_api.rst:469
msgid "Array Length"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:443
msgid "8..8+length\\*8"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:445
msgid "8..12+length\\*8"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:449
msgid "25: :ref:`PoolVector3Array<class_poolvector3array>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:456
msgid "8..8+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:458
msgid "8..12+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:460
msgid "8..16+length\\*12"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:464
msgid "26: :ref:`PoolColorArray<class_poolcolorarray>`"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:471
msgid "8..8+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:473
msgid "8..12+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:475
msgid "8..16+length\\*16"
msgstr ""

#: ../../docs/tutorials/misc/binary_serialization_api.rst:477
msgid "8..20+length\\*16"
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:9
msgid ""
"When developing your game, you would want to test your game and debug when "
"problems occurred. Godot provides several debugging options and tools which "
"aid your debugging process."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:12
msgid "Debug options"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:14
msgid ""
"There are a few options that you can enable when running your game in the "
"editor which can help you in debugging your game. These options are located "
"in ``DEBUG`` in the main menus."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:19
msgid "Here are the descriptions of the options:"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:22
msgid "Deploy with Remote Debug"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:24
msgid ""
"When exporting and deploying, the resulting executable will attempt to "
"connect to the IP of your computer, in order to be debugged."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:27
msgid "Small Deploy with Network FS"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:29
msgid ""
"Export or deploy will produce minimal executable. The filesystem will be "
"provided from the project by the editor over the network. On Android, deploy "
"will use the USB cable for faster performance. This option speeds up testing "
"for games with a large footprint."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:33
msgid "Visible Collision Shapes"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:35
msgid ""
"Collision shapes and raycast nodes(for 2D and 3D) will be visible on the "
"running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:38
msgid "Visible Navigation"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:40
msgid "Navigation meshes and polygons will be visible on the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:43
msgid "Sync Scene Changes"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:45
msgid ""
"Any changes made to the scene in the editor will be replicated in the "
"running game. When used remotely on a device, this is more efficient with "
"network filesystem."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:49
msgid "Sync Script Changes"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:51
msgid ""
"Any script that is saved will be reloaded on the running game. When used "
"remotely on a device, this is more efficient with network filesystem."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:55
msgid "Debugging tools"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:57
msgid ""
"The ``Debugger`` is the second option in the bottom panel. Click on it and a "
"new panel occurs."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:61
msgid "The ``Debugger`` provides certain tools under different tabs."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:63
msgid "Here are some brief descriptions of the tools:"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:66
msgid "Debugger"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:68
msgid "Monitor the game running process."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:71
msgid "Errors"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:73
msgid "Print out errors when running the game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:76
msgid "Profiler"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:78
msgid "Profiling the performance of the any function call in the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:81
msgid "Monitors"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:83
msgid ""
"Monitors the performance of the running game, such as the fps and physics "
"collisions."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:86
msgid "Video Mem"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:88
msgid "Listing the video memory usage of the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:91
msgid "Misc"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:93
msgid "Miscellaneous options for debug."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:97
msgid "Remote in Scene dock"
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:99
msgid ""
"When running your game, a bar will occur at the top of the ``Scene`` dock. "
"You can switch to ``Remote`` and inspect or change the nodes' parameters in "
"the running game."
msgstr ""

#: ../../docs/tutorials/debug/overview_of_debugging_tools.rst:103
msgid ""
"Some editor settings related to debugging can be find in the ``Editor "
"Settings``, under Network>Debug and Debugger sections."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:4
msgid "Getting the source"
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:7
msgid "Downloading the Godot source code"
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:9
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:12
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:16
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:19
msgid ""
"In general, you need to install ``git`` and/or one of the various GUI "
"clients."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:21
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:24
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:31
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:35
msgid ""
"There are also generally branches besides ``master`` for each major version."
msgstr ""

#: ../../docs/development/compiling/getting_source.rst:37
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 many web-based platforms (such as HTML5 "
"and Chrome PNACL)."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:21
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:25
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:28
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:33
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:37
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:44
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:47
msgid "Platform selection"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:49
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:54
msgid "SCons is invoked by just calling ``scons``."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:56
msgid ""
"However, this will do nothing except list the available platforms, for "
"example:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:77
msgid ""
"To build for a platform (for example, x11), run with the ``platform=`` (or "
"just ``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 just 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:95
msgid ""
"Note that there are currently `issues <https://github.com/godotengine/godot/"
"issues/5182>`__ with parallel builds for at least some users, so if you are "
"running into errors, try building without the ``-j`` parameter."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:98
msgid "Resulting binary"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:100
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:107
msgid "For the previous build attempt the result would look like this:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:114
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:117
msgid "A Windows binary with the same configuration will look like this."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:124
msgid ""
"Just copy that binary to wherever 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:130
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:136
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:146
msgid "Target"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:148
msgid "Target controls optimization and debug flags. Each mode means:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:150
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:152
msgid ""
"**release_debug**: Build without C++ debugging symbols and optimization, but "
"keep the runtime checks (performs checks and reports errors). Official "
"binaries use this configuration."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:155
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 "
"tools require some debug functionality and run-time checks to run."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:164
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:169
msgid "Bits"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:171
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:175
msgid "**32**: Build binaries for 32 bits platform."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:176
msgid "**64**: Build binaries for 64 bits platform."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:177
msgid ""
"**default**: Build whatever the build system feels is best. On Linux this "
"depends on the host platform (if not cross compiling), on Mac it defaults to "
"64 bits and on Windows it defaults to 32 bits."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:185
msgid ""
"This flag appends \".32\" or \".64\" suffixes to resulting binaries when "
"relevant."
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:189
msgid "Other build options"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:191
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:195
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:201
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:206
msgid ""
"If you download the official export templates package and unzip it, you will "
"notice that most are just optimized binaries or packages for each platform:"
msgstr ""

#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:229
msgid ""
"To create those yourself, just 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:233
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 C++, `Visual Studio Community <https://www.visualstudio.com/vs/"
"community/>`__ (recommended), version 2013 (12.0) or later. **Make sure you "
"read Installing Visual Studio caveats below or you will have to run/download "
"the installer again.**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:18
msgid "`Python 2.7+ or Python 3.5+ <https://www.python.org/downloads/>`__."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:19
msgid ""
"`Pywin32 Python Extension <https://github.com/mhammond/pywin32>`__ for "
"parallel builds (which increase the build speed by a great factor)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:21
msgid "`SCons <https://www.scons.org>`__ build system."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:24
msgid "Setting up SCons"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:26
msgid ""
"Python adds the interpreter (python.exe) to the path. It usually installs in "
"``C:\\Python`` (or ``C:\\Python[Version]``). SCons installs inside the "
"Python install (typically in the ``Scripts`` folder) and provides a batch "
"file called ``scons.bat``. The location of this file can be added to the "
"path or it can simply be copied to ``C:\\Python`` together with the "
"interpreter executable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:33
msgid ""
"To check whether you have installed Python and SCons correctly, you can type "
"``python --version`` and ``scons --version`` into the Windows Command Prompt "
"(``cmd.exe``)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:37
msgid ""
"If commands above do not work, make sure you add Python to your PATH "
"environment variable after installing it, and check again."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:41
msgid "Setting up Pywin32"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:43
msgid ""
"Pywin32 is required for parallel builds using multiple CPU cores. If SCons "
"is issuing a warning about Pywin32 after parsing SConstruct build "
"instructions, when beginning to build, you need to install it properly from "
"the correct installer executable for your Python version `located at "
"Sourceforge. <https://sourceforge.net/projects/pywin32/files/pywin32/>`__"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:49
msgid ""
"For example, if you installed a 32-bit version of Python 2.7, you would want "
"to install the latest version of Pywin32 that is built for the mentioned "
"version of Python. That executable installer would be named ``pywin32-221."
"win32-py2.7.exe``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:53
msgid ""
"The ``amd64`` version of Pywin32 is for a 64-bit version of Python "
"``pywin32-221.win-amd64-py2.7.exe``. Change the ``py`` number to install for "
"your version of Python (check via ``python --version`` mentioned above)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:58
msgid "Installing Visual Studio caveats"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:60
msgid ""
"If installing Visual Studio 2015 or later, make sure to run **Custom** "
"installation, not **Typical** and select C++ as language there (and any "
"other things you might need). The installer does not install C++ by default. "
"C++ was the `only language made optional <https://blogs.msdn.microsoft.com/"
"vcblog/2015/07/24/setup-changes-in-visual-studio-2015-affecting-c-developers/"
">`__ in Visual Studio 2015."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:66
msgid ""
"If you have already made the mistake of installing a **Typical**, "
"installation, rerun the executable installer you downloaded from internet, "
"it will give you a **Modify** Button option. Running the install from Add/"
"Remove programs will only give you the \"Repair\" option, which will do "
"nothing for your problem."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:72
msgid ""
"If you're using Express, make sure you get/have a version that can compile "
"for ***C++, Desktop***."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:76
msgid "Downloading Godot's source"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:78
msgid ""
"`Godot's <https://github.com/godotengine/godot>`__ source is hosted on "
"GitHub. Downloading it (cloning) via `Git <https://git-scm.com/>`__ is "
"recommended."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:81
msgid ""
"The tutorial will presume from now on that you placed the source into ``C:"
"\\godot``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:87
msgid ""
"SCons will not be able out of the box to compile from the Windows Command "
"Prompt (``cmd.exe``) because SCons and Visual C++ compiler will not be able "
"to locate environment variables and executables they need for compilation."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:92
msgid ""
"Therefore, you need to start a Visual Studio command prompt. It sets up "
"environment variables needed by SCons to locate the compiler. It should be "
"called similar to one of the below names (for your respective version of "
"Visual Studio):"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:97
msgid "\"Developer Command Prompt for VS2013\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:98
msgid "\"VS2013 x64 Native Tools Command Prompt\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:99
msgid "\"VS2013 x86 Native Tools Command Prompt\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:100
msgid "\"VS2013 x64 Cross Tools Command Prompt\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:101
msgid "\"VS2013 x86 Cross Tools Command Prompt\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:103
msgid ""
"You should be able to find at least the Developer Command Prompt for your "
"version of Visual Studio in your start menu."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:106
msgid ""
"However Visual Studio sometimes seems to not install some of the above "
"shortcuts, except the Developer Console at these locations that are "
"automatically searched by the start menu search option:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:116
msgid ""
"If you found the Developer Console, it will do for now to create a 32-bit "
"version of Godot, but if you want the 64-bit version, you might need to "
"setup the prompts manually for easy access."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:120
msgid ""
"If you don't see some of the shortcuts, \"How the prompts actually work\" "
"section below will explain how to setup these prompts if you need them."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:124
msgid "About the Developer/Tools Command Prompts and the Visual C++ compiler"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:126
msgid ""
"There is a few things you need to know about these consoles and the Visual C+"
"+ compiler."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:129
msgid ""
"Your Visual Studio installation will ship with several Visual C++ compilers, "
"them being more or less identical, however each ``cl.exe`` (Visual C++ "
"compiler) will compile Godot for a different architecture (32-bit x86 or 64-"
"bit x86; the ARM compiler is not supported)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:134
msgid ""
"The **Developer Command Prompt** will build a 32-bit version of Godot by "
"using the 32-bit Visual C++ compiler."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:137
msgid ""
"**Native Tools** Prompts (mentioned above) are used when you want the 32-bit "
"cl.exe to compile a 32-bit executable (x86 Native Tools Command Prompt). For "
"the 64-bit cl.exe, it will compile a 64-bit executable (x64 Native Tools "
"Command Prompt)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:142
msgid ""
"The **Cross Tools** are used when your Windows is using one architecture (32-"
"bit, for example) and you need to compile to a different architecture (64-"
"bit). As you might be familiar, 32-bit Windows can not run 64-bit "
"executables, but you still might need to compile for them."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:147
#: ../../docs/development/cpp/object_class.rst:134
msgid "For example:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:149
msgid ""
"\"VS2013 x64 Cross Tools Command Prompt\" will use a 32-bit cl.exe that will "
"compile a 64 bit application."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:152
msgid ""
"\"VS2013 x86 Cross Tools Command Prompt\" will use a 64-bit cl.exe that will "
"compile a 32-bit application. This one is useful if you are running a 32-bit "
"Windows."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:156
msgid ""
"On a 64-bit Windows, you can run any of above prompts and compilers (``cl."
"exe`` executables) because 64-bit Windows can run any 32-bit application. 32-"
"bit Windows cannot run 64-bit executables, so the Visual Studio installer "
"won't even install shortcuts for some of these prompts."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:162
msgid ""
"Note that you need to choose the **Developer Console** or the correct "
"**Tools Prompt** to build Godot for the correct architecture. Use only "
"Native Prompts if you are not sure yet what exactly Cross Compile Prompts do."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:168
msgid "Running SCons"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:170
msgid ""
"Once inside the **Developer Console/Tools Console Prompt**, go to the root "
"directory of the engine source code and type:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:177
msgid ""
"Tip: if you installed \"Pywin32 Python Extension\" you can append the -j "
"command to instruct SCons to run parallel builds like this:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:184
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 if you setup the \"Pywin32 Python "
"Extension\"."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:189
msgid ""
"If all goes well, the resulting binary executable will be placed in ``C:"
"\\godot\\bin\\`` with the name of ``godot.windows.tools.32.exe`` or ``godot."
"windows.tools.64.exe``. SCons will automatically detect what compiler "
"architecture the environment (the prompt) is setup for and will build a "
"corresponding executable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:195
msgid ""
"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_windows.rst:199
msgid "How the prompts actually work"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:201
msgid ""
"The Visual Studio command prompts are just shortcuts that call the standard "
"Command Prompt and have it run a batch file before giving  you control. The "
"batch file itself is called **vcvarsall.bat** and it sets up environment "
"variables, including the PATH variable, so that the correct version of the "
"compiler can be run. The Developer Command Prompt calls a different file "
"called **VsDevCmd.bat** but none of the other tools that this batch file "
"enables are needed by Godot/SCons."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:209
msgid ""
"Since you are probably using Visual Studio 2013 or 2015, if you need to "
"recreate them manually, use the below folders, or place them on the desktop/"
"taskbar:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:218
msgid ""
"Start the creation of the shortcut by pressing the ``right mouse button/New/"
"Shortcut`` in an empty place in your desired location."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:221
msgid ""
"Then copy one of these commands below for the corresponding tool you need "
"into the \"Path\" and \"Name\" sections of the shortcut creation wizard, and "
"fix the path to the batch file if needed."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:225
msgid "Visual Studio 2013 is in the \"Microsoft Visual Studio 12.0\" folder."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:226
msgid "Visual Studio 2015 is in the \"Microsoft Visual Studio 14.0\" folder."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:227
#: ../../docs/development/cpp/custom_godot_servers.rst:36
msgid "etc."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:246
msgid ""
"After you create the shortcut, in the shortcut's properties, that you can "
"access by right clicking with your mouse on the shortcut itself, you can "
"choose the starting directory of the command prompt (\"Start in\" field)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:251
msgid ""
"Some of these shortcuts (namely the 64-bit compilers) seem to not be "
"available in the Express edition of Visual Studio or Visual C++. Before "
"recreating the commands, make sure that ``cl.exe`` executables are present "
"in one of these locations, they are the actual compilers for the "
"architecture you want to build from the command prompt."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:272
msgid ""
"In case you are wondering what these prompt shortcuts do, they call ``cmd."
"exe`` with the ``\\k`` option and have it run a Batch file."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:284
msgid "How to run an automated build of Godot"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:286
msgid ""
"If you just need to run the compilation process via a Batch file or directly "
"in the Windows Command Prompt you need to use the following command:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:294
msgid "with one of the following parameters:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:296
msgid "x86 (32-bit cl.exe to compile for the 32-bit architecture)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:297
msgid "amd64 (64-bit cl.exe to compile for the 64-bit architecture)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:298
msgid "x86_amd64 (32-bit cl.exe to compile for the 64-bit architecture)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:299
msgid "amd64_x86 (64-bit cl.exe to compile for the 32-bit architecture)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:301
msgid "and after that one, you can run SCons:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:307
msgid "or you can run them together:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:318
msgid "Development in Visual Studio or other IDEs"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:320
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:324
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:331
msgid ""
"You will be able to open Godot's source in a Visual Studio solution now, and "
"able to build Godot via the Visual Studio **Build** button. However, make "
"sure that you have installed Pywin32 so that parallel (-j) builds work "
"properly."
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:336
msgid ""
"If you need to edit the compilation 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:343
msgid "Cross-compiling for Windows from other operating systems"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:345
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 distro, here are some "
"known ones:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:350
#: ../../docs/development/compiling/compiling_for_x11.rst:30
msgid "**Arch**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:354
#: ../../docs/development/compiling/compiling_for_x11.rst:34
msgid "**Debian** / **Ubuntu**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:358
#: ../../docs/development/compiling/compiling_for_x11.rst:40
msgid "**Fedora**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:362
msgid "**macOS**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:366
#: ../../docs/development/compiling/compiling_for_x11.rst:56
msgid "**Mageia**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:371
msgid ""
"Before allowing you to attempt the compilation, SCons will check for the "
"following binaries in your ``$PATH``:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:379
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:388
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:398
#: ../../docs/development/compiling/compiling_for_android.rst:131
#: ../../docs/development/compiling/compiling_for_android.rst:173
#: ../../docs/development/cpp/creating_android_modules.rst:301
msgid "Troubleshooting"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:400
msgid ""
"Cross-compiling from some versions of Ubuntu 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:403
msgid ""
"You can change that configuration following those instructions, for 32-bit:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:413
msgid "And for 64-bit:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:423
msgid "Creating Windows export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:425
msgid ""
"Windows export templates are created by compiling Godot as release, with the "
"following flags:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:428
msgid "(using Mingw32 command prompt, using the bits parameter)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:435
msgid "(using Mingw-w64 command prompt, using the bits parameter)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:442
msgid ""
"(using the Visual Studio command prompts for the correct architecture, "
"notice the lack of bits parameter)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:450
msgid "If you plan on replacing the standard templates, copy these to:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:456
msgid "With the following names:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_windows.rst:465
#: ../../docs/development/compiling/compiling_for_x11.rst:141
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_windows.rst:471
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:4
msgid "Compiling for X11 (Linux, \\*BSD)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:11
#: ../../docs/development/compiling/compiling_for_osx.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 or Clang"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:15
msgid "Python 2.7+ (Python 3 only supported as of SCons 3.0)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:16
#: ../../docs/development/compiling/compiling_for_osx.rst:15
#: ../../docs/development/compiling/compiling_for_android.rst:25
msgid "SCons build system"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:17
msgid "pkg-config (used to detect the dependencies below)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:18
msgid "X11, Xcursor, Xinerama, Xi and XRandR development libraries"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:19
msgid "MesaGL development libraries"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:20
msgid "ALSA development libraries"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:21
msgid "PulseAudio development libraries (for sound support)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:22
msgid "Freetype (for the editor)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:23
msgid "OpenSSL (for HTTPS and TLS)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:24
msgid "*Optional* - libudev (build with ``udev=yes``)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:25
msgid "*Optional* - yasm (for WebM SIMD optimizations)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:28
msgid "Distro-specific oneliners"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:46
msgid "**FreeBSD**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:51
msgid "**Gentoo**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:62
msgid "**OpenBSD**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:66
msgid "**openSUSE**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:72
msgid "**Solus**"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:81
#: ../../docs/development/compiling/compiling_for_osx.rst:21
msgid ""
"Start a terminal, go to the root dir of the engine source code and type:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:87
#: ../../docs/development/compiling/compiling_for_osx.rst:27
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:94
msgid "If you wish to compile using Clang rather than GCC, use this command:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:100
msgid ""
"Using Clang appears to be a requirement for OpenBSD, otherwise fonts would "
"not build."
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:104
#: ../../docs/development/compiling/compiling_for_web.rst:20
msgid "Building export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:106
msgid ""
"To build X11 (Linux, \\*BSD) export templates, run the build system with the "
"following parameters:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:109
msgid "(32 bits)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:116
msgid "(64 bits)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:123
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:126
msgid ""
"To create standard export templates, the resulting files must be copied to:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:132
msgid ""
"and named like this (even for \\*BSD which is seen as \"Linux X11\" by "
"Godot):"
msgstr ""

#: ../../docs/development/compiling/compiling_for_x11.rst:147
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_osx.rst:4
msgid "Compiling for OSX"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:14
#: ../../docs/development/compiling/compiling_for_android.rst:24
msgid "Python 2.7+ or Python 3.5+"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:16
msgid "Xcode (or the more lightweight Command Line Tools for Xcode)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:32
msgid ""
"To create an .app like in the official builds, you need to use the template "
"located in ``misc/dist/osx_tools.app``. Typically, for a \".64\" optimised "
"binary built with `scons p=osx target=release_debug`:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:44
msgid "Compiling for 32 and 64-bit"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:46
msgid ""
"All macOS versions after 10.6 are 64-bit exclusive, so the executable will "
"be a \".64\" file by default for most users. If you would like to compile a "
"\".fat\" executable which contains both 32 and 64-bit code, you can do so by "
"specifying the bits in the scons command like so:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:56
msgid "Cross-compiling"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:58
msgid ""
"It is possible to compile for OSX in a Linux environment (and maybe also in "
"Windows with Cygwin). For that you will need `OSXCross <https://github.com/"
"tpoechtrager/osxcross>`__ to be able to use OSX as target. First, follow the "
"instructions to install it:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:63
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:71
msgid ""
"Follow the instructions to package the SDK: https://github.com/tpoechtrager/"
"osxcross#packaging-the-sdk"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:73
msgid ""
"Follow the instructions to install OSXCross: https://github.com/tpoechtrager/"
"osxcross#installation"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:76
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:84
msgid "Now you can compile with SCons like you normally would:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_osx.rst:90
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 ""
"For 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 do all the steps mentioned in the :ref:"
"`doc_exporting_for_android` tutorial before attempting your 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:26
msgid "[Windows only] PyWin32 (optional, for parallel compilation)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:27
msgid ""
"Android SDK version 23.0.3 [Note: Please install all tools and extras of the "
"SDK Manager]"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:28
msgid "Android build tools version 19.1"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:29
msgid "Android NDK r13 or later"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:30
msgid "Gradle (will be downloaded and installed automatically if missing)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:31
msgid ""
"JDK 6 or later (either OpenJDK or Oracle JDK) - JDK 9 is untested as of now"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:34
msgid "Setting up the buildsystem"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:36
msgid "Set the environment variable ANDROID_HOME to point to the Android SDK."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:39
msgid ""
"Set the environment variable ANDROID_NDK_ROOT to point to the Android NDK."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:42
msgid ""
"To set those environment variables on Windows, press 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:47
msgid ""
"To set those environment variables on Unix (e.g. Linux, 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 is the "
"path where Android SDK and Android NDK are placed on your PC."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:54
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:101
msgid "Toolchain"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:56
msgid ""
"We usually try to keep the Godot Android build code up to date, but Google "
"changes their toolchain versions often, so if compilation fails due to wrong "
"toolchain version, go to your NDK directory and check the current number, "
"then set the following environment variable:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:66
msgid "Building the export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:68
msgid ""
"Godot needs two export templates for Android: the optimized \"release\" "
"template (`android_release.apk`) and the debug version (`android_debug."
"apk`). Compiling the standard export templates is done by calling scons with "
"the following arguments:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:73
msgid "Release template (used when exporting with \"Debugging Enabled\" OFF)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:81
msgid ""
"(on Linux or macOS, execute the `gradlew` script with `./gradlew build`)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:83
#: ../../docs/development/compiling/compiling_for_android.rst:97
msgid "The resulting APK is in:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:89
msgid "Debug template (used when exporting with \"Debugging Enabled\" ON)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:104
msgid "Faster compilation"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:106
msgid ""
"If you are on Unix or installed PyWin32 on Windows and have multiple CPU "
"cores available, you can speed up the compilation by adding the ``-jX`` "
"argument to the SCons command, where ``X`` is the number of cores that you "
"want to allocate to the compilation, e.g. ``scons -j4``."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:113
msgid "Adding support for x86 devices"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:115
msgid ""
"If you also want to include support for x86 devices, run the scons command a "
"second time with the ``android_arch=x86`` argument before building the APK "
"with Gradle. For example for the release template:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:127
msgid ""
"This will create a fat binary that works in both platforms, but will add "
"about 6 megabytes to the APK."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:133
msgid ""
"It might be necessary to clean the build cache between two APK compilations, "
"as some users have reported issues when building the two export templates "
"one after the other."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:138
msgid "Using the export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:140
msgid ""
"As export templates for Android, 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 to build your own from the same version."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:145
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:149
msgid "Installing the templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:151
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:155
msgid "Windows: ``C:\\Users\\[username]\\AppData\\Roaming\\Godot\\templates``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:156
msgid "Linux: ``/home/[username]/.local/share/godot/templates/[gd-version]/``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:157
msgid "macOS: ``/users/[username]/.godot/templates``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:161
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:167
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:176
msgid "Application not installed"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:178
msgid ""
"Android might complain the application is not correctly installed. If so, "
"check the following:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:181
msgid "Check that the debug keystore is properly generated."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:182
msgid "Check that jarsigner is from JDK 6, 7 or 8."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:184
msgid "If it still fails, open a command line and run logcat:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:190
msgid ""
"And check the output while the application is installed. Reason for failure "
"should be presented there."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:193
msgid "Seek assistance if you can't figure it out."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:196
msgid "Application exits immediately"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:198
msgid ""
"If the application runs but exits immediately, there might be one of the "
"following reasons:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:201
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:203
msgid "libgodot_android.so is not in ``lib/armeabi-v7a`` or ``lib/armeabi``"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:204
msgid "Device does not support armv7 (try compiling yourself for armv6)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:205
msgid "Device is Intel, and apk is compiled for ARM."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:207
msgid "In any case, ``adb logcat`` should also show the cause of the error."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:210
msgid "Compilation fails"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:212
msgid ""
"On Linux systems with Kernel version 4.3 or newer, compilation may fail with "
"the error \"pthread_create failed: Resource temporarily unavailable.\""
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:215
msgid ""
"This is because of a change in the way Linux limits thread creation. But you "
"can change those limits through the command line. Please read this section "
"thoroughly before beginning."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:219
msgid ""
"First open a terminal, then begin compilation as usual (it may be a good "
"idea to run a --clean first). While compiling enter the following in your "
"terminal:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:227
msgid ""
"The output should list a scons process, with its PID as the first number in "
"the output. For example the PID 1077 in the output shown below:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:235
msgid ""
"Now you can use another command to increase the number of processes that "
"scons is allowed to spawn. You can check its current limits with:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:242
msgid "You can increase those limits with the command:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:248
msgid ""
"Obviously you should substitute the scons PID output by top and a limits "
"that you think suitable. These are in the form --nproc=soft:hard where soft "
"must be lesser than or equal to hard. See the man page for more information."
msgstr ""

#: ../../docs/development/compiling/compiling_for_android.rst:253
msgid ""
"If all went well, and you entered the prlimit command while scons was "
"running, then your compilation should continue without 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 (you can get it from macports, you should be able to run ``scons`` in "
"a terminal when installed)"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:13
msgid "Xcode with the iOS SDK and the command line tools."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:18
msgid "Open a Terminal, go to the root dir of the engine source code and type:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:24
msgid "for a debug build, or:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:30
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:33
msgid "Alternatively, you can run"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:39
msgid "for a Simulator executable."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:41
msgid ""
"Additionally since some time Apple requires 64 bit version of application "
"binary when you are uploading to iStore. The best way to provide these is to "
"create a bundle in which there are both 32bit and 64 binaries, so every "
"device will be able to run the game. It can be done in three steps, first "
"compile 32 bit version, then compile 64 bit version and then use ``lipo`` to "
"bundle them into one fat binary, all those steps can be performed with "
"following commands:"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:53
msgid "Run"
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:55
msgid ""
"To run on a device or simulator, follow these instructions: :ref:"
"`doc_exporting_for_ios`."
msgstr ""

#: ../../docs/development/compiling/compiling_for_ios.rst:58
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: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:159
msgid ""
"Then you will have an iOS fat binary in ``bin/godot.iphone.opt.debug.fat``."
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 (see :ref:`doc_compiling_for_windows` for more details)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:12
msgid ""
"Visual Studio 2015 Update 2. It may work with earlier versions. See :ref:"
"`doc_compiling_for_windows` about the caveats of installing it and the "
"various prompts."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:15
msgid "Windows 10 SDK (can be selected in Visual Studio installation)."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:16
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:23
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:27
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:31
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:35
msgid ""
"Once you're set, run the SCons command similarly to the other platforms::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:40
msgid "Creating UWP export templates"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:42
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:46
msgid ""
"Open the command prompt for one architecture and run SCons twice (once for "
"each target)::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:52
msgid "Repeat for the other architectures."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:54
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:58
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:64
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:74
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:81
msgid "Running UWP apps with Visual Studio"
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:83
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:88
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:92
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:97
msgid ""
"Create a new Windows App project using the \"App for OpenGL ES (Windows "
"Unversal)\" project template, which can be found under the ``Visual C++/"
"Windows/Universal`` category."
msgstr ""

#: ../../docs/development/compiling/compiling_for_uwp.rst:101
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:107
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:111
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:118
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:124
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:130
msgid ""
"Now you can just run the project and your app should open. You can use also "
"the \"Start Without Debugging\" from the \"Debug\" menu (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.37.9+ <http://kripken.github.io/emscripten-site>`__: If the "
"version available per package manager is not recent enough, the best "
"alternative is to install using the `Emscripten SDK <http://kripken.github."
"io/emscripten-site/docs/getting_started/downloads.html>`__"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:16
msgid "`Python 2.7+ or Python 3.5+ <https://www.python.org/>`__"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:17
msgid "`SCons <https://www.scons.org>`__ build system"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:22
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:29
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:36
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:43
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:48
msgid ""
"Finally, rename the zip archive to ``webassembly_release.zip`` for the "
"release template::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:53
msgid "And ``webassembly_debug.zip`` for the debug template::"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:58
msgid "Building per asm.js translation or LLVM backend"
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:60
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:66
msgid ""
"The other method uses LLVM's WebAssembly backend. This backend is not yet "
"available in release versions of LLVM, only in development builds built with "
"``LLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly``. Compiling with this "
"backend outputs files in LLVM's ``.s`` format, which is translated into "
"actual WebAssembly using a tool called ``s2wasm``. Emscripten manages these "
"processes as well, so we just invoke SCons."
msgstr ""

#: ../../docs/development/compiling/compiling_for_web.rst:73
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 "
"``s2wasm`` is used. On Windows, make sure to escape backslashes of paths "
"within this file as double backslashes ``\\\\`` or use Unix-style paths with "
"a single forward slash ``/``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:4
msgid "Compiling with Mono"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:11
msgid "Mono (the required version is listed here: :ref:`doc_c_sharp`)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:12
msgid "MSBuild"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:13
msgid "pkg-config"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:16
msgid "Environment Variables"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:18
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 using the following environment variables for the "
"respective ``bits`` option: ``MONO32_PREFIX`` and ``MONO64_PREFIX``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:20
msgid ""
"The specified directory must contain the subdirectories ``bin``, "
"``include``, and ``lib``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:23
msgid "Enable Mono Module"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:25
msgid ""
"By default, the mono module is disabled for builds. To enable it you can "
"pass the option ``module_mono_enabled=yes`` to your SCons command."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:28
msgid "Generate The Glue"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:30
msgid ""
"The glue sources are the wrapper functions that will be called by the "
"managed side. In order to generate them, first, you must build Godot with "
"the options ``tools=yes`` and ``mono_glue=no``:"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:36
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:42
msgid ""
"This command will tell Godot to generate the file *modules/mono/glue/"
"mono_glue.gen.cpp*. Once this file is generated, you can build Godot for all "
"the desired targets without the need to repeat this process."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:44
msgid ""
"As always, ``godot`` refers to the compiled Godot binary, so if it isn't in "
"your PATH, you need to give the full path to the executable, e.g. if it is "
"located in the ``bin`` subfolder, it becomes ``bin/godot``."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:47
#: ../../docs/development/cpp/custom_godot_servers.rst:469
msgid "Notes"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:48
msgid ""
"**Do not** build normal binaries with ``mono_glue=no``. This option disables "
"C# scripting and therefore must only be used for the temporary binary that "
"will be used to generate the glue. Godot should print a message at startup "
"warning you about this."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:49
msgid ""
"The glue sources must be regenerated every time the ClassDB API changes. If "
"there is an API mismatch with the generated glue, Godot will print an error "
"at startup."
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:55
msgid "Example (Windows)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:71
msgid "Example (x11)"
msgstr ""

#: ../../docs/development/compiling/compiling_with_mono.rst:86
msgid ""
"If everything went well, apart from the normal output, SCons should have "
"also built the *GodotSharpTools.dll* assembly and copied it together with "
"the mono runtime shared library to the ``bin`` subdirectory."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:4
msgid "Packaging Godot"
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:6
msgid ""
"Godot has features to make it easier to distribute and to package it for "
"application repositories."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:9
msgid "Default behaviour"
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:11
msgid ""
"By default, Godot stores all settings and installed templates in a per-user "
"directory. First Godot checks the ``APPDATA`` environment variable. If it "
"exists, the per-user directory is the ``Godot`` subdirectory of ``APPDATA``. "
"If ``APPDATA`` doesn't exist, Godot checks the ``HOME`` environment "
"variable. The per-user directory is then the \".godot\" subdir of ``HOME``."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:17
msgid "This meets common operating system standards."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:20
msgid "Global template path (Unix only)"
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:22
msgid ""
"The ``unix_global_settings_path`` build variable is meant for Unix/Linux "
"distro packagers who want to package export templates together with godot. "
"It allows to put the export templates on a hardcoded path."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:26
msgid ""
"To use it, pass the desired path via the scons ``unix_global_settings_path`` "
"build variable when building the editor. The export templates then live at "
"the \"templates\" subdirectory of the path specified."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:30
msgid ""
"Templates installed at the per-user location still override the system wide "
"templates."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:32
msgid "This option is only available on unix based platforms."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:35
msgid "Self contained mode"
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:37
msgid ""
"The self contained mode can be used to package Godot for distribution "
"systems where it doesn't live at a fixed location. If the editor finds a ``."
"_sc_`` file in the directory the executable is located in, Godot will "
"continue in \"self contained mode\". On Windows, the file name to use is "
"``_sc_`` (without the preceding dot)."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:42
msgid ""
"In self contained mode, all config files are located next to the executable "
"in a directory called ``editor_data``. Godot doesn't read or write to the "
"per-user location anymore."
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:45
msgid ""
"The contents of the ``._sc_`` file (when not empty) are read with the "
"ConfigFile api (same format as ``project.godot``, etc). So far it can "
"contain a list of pre-loaded project in this format:"
msgstr ""

#: ../../docs/development/compiling/packaging_godot.rst:54
msgid ""
"The paths are relative to the executable location, and will be added to the "
"file ``editor_settings.xml`` when this is created for the first time."
msgstr ""

#: ../../docs/development/cpp/index.rst:2
msgid "Engine development"
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.rst:4
msgid "Configuring an IDE"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:6
msgid ""
"We assume that you already `cloned <https://github.com/godotengine/godot>`_ "
"and :ref:`compiled <toc-devel-compiling>` Godot."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:10
msgid "Kdevelop"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:12
msgid ""
"It is a free, open source IDE (Integrated Development Environment) for "
"Linux, Solaris, FreeBSD, Mac OS X and other Unix flavors."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:15
msgid ""
"You can find a video tutorial `here <https://www.youtube.com/watch?"
"v=yNVoWQi9TJA>`_. Or you may follow this text version tutorial."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:18
msgid "Start by opening Kdevelop and choosing \"open project\"."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:22
msgid "Choose the directory where you cloned Godot."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:26
msgid "For the build system, choose \"custom build system\"."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:30
msgid "Now that the project has been imported, open the project configuration."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:34
msgid "Add the following includes/imports:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:48
msgid ""
"Apply the changes then switch to the \"Custom Buildsystem\" tab. Leave the "
"build directory blank. Enable build tools and add ``scons`` as the "
"executable and add ``platform=x11 target=debug`` (``platform=osx`` if you're "
"on OS X)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:55
msgid ""
"Next we need to tell KDevelop where to find the binary. From the \"run\" "
"menu, choose \"Configure Launches\"."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:60
msgid ""
"Click \"Add new\" if no launcher exists. Then add the path to your "
"executable in the executable section. Your executable should be located in "
"the ``bin/`` sub-directory and should be named something like ``godot.x11."
"tools.64`` (the name could be different depending on your platform and "
"depending on your build options)."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:68
msgid "That's it! Now you should be good to go :)"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:71
#, fuzzy
msgid "Qt Creator"
msgstr "تکرارکننده"

#: ../../docs/development/cpp/configuring_an_ide.rst:74
msgid "Importing the project"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:76
msgid "Choose *New Project* -> *Import Project* -> *Import Existing Project*."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:80
msgid "Set the path to your Godot root directory and enter the project name."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:84
msgid ""
"Here you can choose which folders and files will be visible to the project. "
"C/C++ files are added automatically. Potentially useful additions: \\*.py "
"for buildsystem files, \\*.java for Android development, \\*.mm for macOS. "
"Click \"Next\"."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:90
msgid "Click *Finish*."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:91
msgid ""
"Add a line containing ``.`` to *project_name.includes* to get working code "
"completion."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:96
msgid "Build and run"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:98
msgid "Build configuration:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:100
msgid "Click on *Projects* and open the *Build* tab."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:101
msgid "Delete the pre-defined ``make`` build step."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:105
msgid "Click *Add Build Step* -> *Custom Process Step*."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:109
msgid "Type ``scons`` in the *Command* field."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:110
msgid ""
"Fill the *Arguments* field with your compilation options. (e.g.: ``p=x11 "
"target=debug -j 4``)"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:114
msgid "Run configuration:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:116
msgid "Open the *Run* tab."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:117
msgid ""
"Point the *Executable* to your compiled Godot binary (e.g: ``%{buildDir}/bin/"
"godot.x11.opt.tools.64``)"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:118
msgid ""
"If you want to run a specific game or project, point *Working directory* to "
"the game directory."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:119
msgid ""
"If you want to run the editor, add ``-e`` to the *Command line arguments* "
"field."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:124
msgid "Updating Sources after pulling latest commits"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:126
msgid ""
"As a developer you usually want to frequently pull the latest commits from "
"the upstream git repository or a specific fork etc. However this brings a "
"little problem with it: as the development continues, source files (and "
"folders) are added or removed. These changes needs to be reflected in your "
"project files for Qt Creator too, so you continue to have a nice experience "
"coding in it. A simple way to check these things, is to right click at your "
"root folder in the \"Projects View\" and click on \"Edit files...\""
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:136
msgid ""
"Now a new dialog should appear that is similar in functionality to the one "
"in the third step of the \"Importing the project\" section. Here now you can "
"check whether you want to add/remove specific files and/or folders. You can "
"chose by clicking with your mouse or just simply by clicking the \"Apply "
"Filter\" button. A simple click on \"Ok\" and you're ready to continue your "
"work."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:144
msgid "Xcode"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:149
msgid "Create an Xcode external build project anywhere"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:153
msgid "Set the *Build tool* to the path to scons"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:155
msgid "Modify Build Target's Xcode Info Tab:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:157
msgid ""
"Set *Arguments* to something like: platform=osx tools=yes bits=64 "
"target=debug"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:158
msgid ""
"Set *Directory* to the path to Godot's source folder. Keep it blank if "
"project is already there."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:159
msgid "You may uncheck *Pass build settings in environment*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:163
msgid "Add a Command Line Target:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:165
msgid ""
"Go to Xcode File > New > Target... and add a new Xcode command line target"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:171
msgid "Name it something so you know not to compile with this target"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:172
msgid "e.g. ``GodotXcodeIndex``"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:173
msgid ""
"Goto the newly created target's *Build Settings* tab and search for *Header "
"Search Paths*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:174
msgid "Set *Header Search Paths* to an absolute path to Godot's source folder"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:175
msgid "Make it recursive by adding two \\*'s to the end of the path"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:176
msgid "e.g. ``/Users/me/repos/godot-source/\\**``"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:178
msgid "Add Godot Source to the Project:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:180
msgid "Drag and drop godot source into project file browser."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:181
msgid "Uncheck *Create External Build System*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:185
msgid "Click Next"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:186
msgid "Select *create groups*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:190
msgid "Check off only your command line target in the *Add to targets* section"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:191
msgid "Click finish. Xcode will now index the files."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:192
msgid "Grab a cup of coffee... Maybe make something to eat, too"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:193
msgid ""
"You should have jump to definition, auto completion, and full syntax "
"highlighting when it is done."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:196
msgid "Scheme Setup"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:198
msgid "Edit Build Scheme of External Build Target:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:200
msgid "Open scheme editor of external build target"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:201
msgid "Expand the *Build* menu"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:202
msgid "Goto *Post Actions*"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:203
msgid ""
"Add a new script run action, select your project in ``Provide build settings "
"from`` as this allows you to use ``${PROJECT_DIR}`` variable."
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:207
msgid "Write a script that gives the binary a name that Xcode will recognize"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:208
msgid ""
"e.g. ``ln -f ${PROJECT_DIR}/godot/bin/godot.osx.tools.64 ${PROJECT_DIR}/"
"godot/bin/godot``"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:209
msgid "Build the external build target"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:211
msgid "Edit Run Scheme of External Build Target:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:213
msgid "Open the scheme editor again"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:214
msgid "Click Run"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:218
msgid ""
"Set the *Executable* to the file you linked in your post build action script"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:219
msgid "Check *Debug executable* if it isn't already"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:220
msgid ""
"You can go to *Arguments* tab and add an -e and a -path to a project to "
"debug the editor not the project selection screen"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:223
msgid "Test it:"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:225
msgid "Set a breakpoint in platform/osx/godot_main_osx.mm"
msgstr ""

#: ../../docs/development/cpp/configuring_an_ide.rst:226
msgid "It should break at the point!"
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:133
#: ../../docs/development/cpp/core_types.rst:167
#: ../../docs/development/cpp/core_types.rst:183
#: ../../docs/development/cpp/core_types.rst:199
#: ../../docs/development/cpp/core_types.rst:210
#: ../../docs/development/cpp/core_types.rst:221
#: ../../docs/development/cpp/core_types.rst:234
#: ../../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:251
#: ../../docs/development/cpp/object_class.rst:267
#: ../../docs/development/cpp/object_class.rst:288
#: ../../docs/development/cpp/object_class.rst:307
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:19
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:40
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:211
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:244
#: ../../docs/development/cpp/custom_audiostreams.rst:23
#: ../../docs/development/cpp/custom_audiostreams.rst:119
#: ../../docs/development/cpp/custom_audiostreams.rst:356
#: ../../docs/development/cpp/custom_godot_servers.rst:20
#: ../../docs/development/cpp/custom_godot_servers.rst:279
#: ../../docs/development/cpp/custom_godot_servers.rst:429
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 "
"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 DVector<> template is provided. Use it like this:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:113
msgid ""
"DVector is a standard vector class, it can be accessed using the [] "
"operator, but that's probably slow for large amount of accesses (as it has "
"to lock internally). A few helpers exist for this:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:129
msgid ""
"respectively. These allow fast read/write from DVectors and keep it locked "
"until they go out of scope."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:135
msgid ""
"`core/os/memory.h <https://github.com/godotengine/godot/blob/master/core/os/"
"memory.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:136
msgid ""
"`core/dvector.h <https://github.com/godotengine/godot/blob/master/core/"
"dvector.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:139
msgid "Containers"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:141
msgid "Godot provides also a set of common containers:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:143
msgid "Vector"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:144
msgid "List"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:145
msgid "Set"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:146
msgid "Map"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:148
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:159
msgid "The Vector<> class also has a few nice features:"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:161
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:163
msgid ""
"It supports multi-threading, by using atomic operations on the reference "
"counter."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:169
msgid ""
"`core/vector.h <https://github.com/godotengine/godot/blob/master/core/vector."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:170
msgid ""
"`core/list.h <https://github.com/godotengine/godot/blob/master/core/list."
"h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:171
msgid ""
"`core/set.h <https://github.com/godotengine/godot/blob/master/core/set.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:172
msgid ""
"`core/map.h <https://github.com/godotengine/godot/blob/master/core/map.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:177
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:185
msgid ""
"`core/ustring.h <https://github.com/godotengine/godot/blob/master/core/"
"ustring.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:188
msgid "StringName"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:190
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:195
msgid ""
"Creation of a StringName (especially a new one) is slow, but comparison is "
"fast."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:201
msgid ""
"`core/string_db.h <https://github.com/godotengine/godot/blob/master/core/"
"string_db.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:204
msgid "Math types"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:206
msgid ""
"There are several linear math types available in the core/math directory."
msgstr ""

#: ../../docs/development/cpp/core_types.rst:212
msgid ""
"`core/math <https://github.com/godotengine/godot/tree/master/core/math>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:215
msgid "NodePath"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:217
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:223
msgid ""
"`core/node_path.h <https://github.com/godotengine/godot/blob/master/core/"
"node_path.h>`__"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:226
msgid "RID"
msgstr ""

#: ../../docs/development/cpp/core_types.rst:228
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:236
#: ../../docs/development/cpp/custom_godot_servers.rst:282
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: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:173
msgid "Binding properties using ``_set``/``_get``/``_get_property_list``"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:175
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:178
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:189
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:193
msgid "Dynamic casting"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:195
msgid ""
"Godot provides dynamic casting between Object-derived classes, for example:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:205
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:213
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:222
msgid ""
"The method ``_node_entered_tree`` must be registered to the class using "
"``ClassDB::register_method`` (explained before)."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:225
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:235
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:247
msgid ""
"``myref`` is reference counted. It will be freed when no more Ref<> "
"templates point to it."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:253
msgid ""
"`core/reference.h <https://github.com/godotengine/godot/blob/master/core/"
"reference.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:256
msgid "Resources:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:258
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:264
msgid "Resources without a path are fine too."
msgstr ""

#: ../../docs/development/cpp/object_class.rst:269
msgid ""
"`core/resource.h <https://github.com/godotengine/godot/blob/master/core/"
"resource.h>`__"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:272
msgid "Resource loading"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:274
msgid "Resources can be loaded with the ResourceLoader API, like this:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:280
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:285
msgid "resourceinteractiveloader (TODO)"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:290
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:293
msgid "Resource saving"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:295
msgid "Saving a resource can be done with the resource saver API:"
msgstr ""

#: ../../docs/development/cpp/object_class.rst:301
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:309
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: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
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, many different modules exist, 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, and "
"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:25
#: ../../docs/development/cpp/custom_audiostreams.rst:31
#: ../../docs/development/cpp/custom_godot_servers.rst:29
msgid "What for?"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:24
msgid ""
"While it's recommended that most of a game is 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:83
msgid "And then the cpp file."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:117
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:125
msgid "With the following contents:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:152
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:162
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:170
msgid ""
"This allows for powerful possibilities using Python to contruct the file "
"list using loops and logic statements. Look at some of the other modules "
"that ship with Godot by default for examples."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:174
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:182
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:195
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:208
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:211
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:223
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:228
#: ../../docs/development/cpp/creating_android_modules.rst:269
msgid "Using the module"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:230
msgid "You can now use your newly created module from any script:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:241
msgid "And the output will be ``60``."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:244
msgid "Improving the build system for development"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:246
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:249
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:252
msgid ""
"However the trade-of 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:257
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:289
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`` environ variable:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:299
msgid ""
"**note**: Pay attention you have to ``export`` the environ variable "
"otherwise you won't be able to play you project from within the editor."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:302
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:332
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:335
msgid ""
"Finally you can even speedup build further by explicitly specifying your "
"shared module as target in the scons command:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:343
msgid "Writing custom documentation"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:345
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:351
msgid "There are several steps in order to setup custom docs for the module:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:353
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:356
msgid "Append the following code snippet to ``config.py``:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:368
msgid ""
"The ``get_doc_classes()`` method is necessary for the build system to know "
"which documentation classes of the module must be merged, since the module "
"may contain several classes. Replace ``ClassName`` with the name of the "
"class you want to write documentation for. If you need docs for more than "
"one class, append those as well."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:374
msgid ""
"The ``get_doc_path()`` method is used by the build system to determine the "
"location of the docs. In our case, they will be located in the "
"``doc_classes`` directory."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:378
msgid "Run command:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:384
msgid ""
"This will dump the engine API reference to the given ``<path>`` in XML "
"format. Notice that you'll need to configure your ``PATH`` to locate Godot's "
"executable, and make sure that you have write access rights. If not, you "
"might encounter an error similar to the following:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:394
msgid "Get generated doc file from ``godot/doc/classes/ClassName.xml``"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:396
msgid ""
"Copy this file to ``doc_classes``, optionally edit it, then compile the "
"engine."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:398
msgid ""
"The build system will fetch the documentation files from the ``doc_classes`` "
"directory and merge them with the base types. 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:402
msgid ""
"In order to keep documentation up-to-date, all you'll have to do is simply "
"modify one of the ``ClassName.xml`` files and recompile the engine from now "
"on."
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:406
msgid "Summing up"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:408
msgid "Remember to:"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:410
msgid "use ``GDCLASS`` macro for inheritance, so Godot can wrap it"
msgstr ""

#: ../../docs/development/cpp/custom_modules_in_cpp.rst:411
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:414
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:417
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:420
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:423
msgid ""
"By this same logic, you can extend the Editor and almost any area of the "
"engine."
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
#: ../../docs/development/cpp/custom_godot_servers.rst:16
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:21
msgid ":ref:`ResourceLoader<class_resourceloader>`"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:22
msgid ""
"`core/io/resource_loader.cpp <https://github.com/godotengine/godot/blob/"
"master/core/io/resource_loader.cpp#L258>`__"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:27
msgid "Adding new support for many file formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:28
msgid "Audio formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:29
msgid "Video formats"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:30
msgid "Machine learning models"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:33
msgid "What not?"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:35
msgid "Raster images"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:37
msgid "ImageFormatLoader should be used to load images."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:42
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:46
msgid "Creating a ResourceFormatLoader"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:48
msgid ""
"Each file format consist of a data container and a ``ResourceFormatLoader``."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:50
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:54
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:111
msgid "Creating Custom Data Types"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:113
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:117
msgid "Here is an example of how to create a custom datatype"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:174
msgid "Considerations"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:176
msgid ""
"Some libraries may not define certain common routines such as i/o handling. "
"Therefore, Godot call translations are required."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:179
msgid ""
"For example, here is the code for translating ``FileAccess`` calls into "
"``std::istream``."
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:212
msgid "`istream <http://www.cplusplus.com/reference/istream/istream/>`__"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:213
msgid ""
"`streambuf <http://www.cplusplus.com/reference/streambuf/streambuf/?"
"kw=streambuf>`__"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:214
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:217
msgid "Registering the New File Format"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:219
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:245
msgid ""
"`core/io/resource_loader.cpp <https://github.com/godotengine/godot/blob/"
"master/core/io/resource_loader.cpp#L280>`__"
msgstr ""

#: ../../docs/development/cpp/custom_resource_format_loaders.rst:249
msgid "Loading it on GDScript"
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:121
#: ../../docs/development/cpp/custom_audiostreams.rst:358
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:359
msgid ""
"`scene/audio/audioplayer.cpp <https://github.com/godotengine/godot/blob/"
"master/scene/audio/audio_player.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:33
msgid "Binding external libraries (like Wwise, FMOD, etc)."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:34
msgid "Adding custom audio queues"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:35
msgid "Adding support for more audio formats"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:38
msgid "Create an AudioStream"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:41
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:47
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:125
msgid "Create an AudioStreamPlayback"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:127
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:129
msgid ""
"Since AudioStreamPlayback is controlled by the audio thread, i/o and dynamic "
"memory allocation are forbidden."
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:235
msgid "Resampling"
msgstr ""

#: ../../docs/development/cpp/custom_audiostreams.rst:238
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:242
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:357
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. Server implements 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:22
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:24
msgid "`Sigleton Pattern <https://en.wikipedia.org/wiki/Singleton_pattern>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:26
msgid "`Mediator Pattern <https://en.wikipedia.org/wiki/Mediator_pattern>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:31
msgid "Adding AI"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:32
msgid "Adding a custom asynchronous threads"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:33
msgid "Adding Input support"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:34
msgid "Adding writing threads"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:35
msgid "Adding custom VOIP protocol"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:39
msgid "Creating a Godot Server"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:41
msgid ""
"At minimum, a server must to have: a static instance, sleep timer, thread "
"loop, initialize state, and cleanup."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:245
msgid "Custom Managed Resource Data"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:247
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. Only during debug mode, RID_Owner maintains a list of RID. In "
"practice, RID is similar to writing object oriented C code."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:281
msgid ":ref:`RID<class_rid>`"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:286
msgid "Registering the class to GDScript"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:288
msgid ""
"Server 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:292
msgid ""
"Since 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:296
msgid ""
"In ``register_godotserver_types()``, ``Engine::get_singleton()-"
">add_singleton`` is used to register the dummy class to GDScript."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:338
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:341
msgid "Bind methods"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:343
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:351
#, fuzzy
msgid "Binding Signals"
msgstr "سیگنال‌ها"

#: ../../docs/development/cpp/custom_godot_servers.rst:353
msgid ""
"It is possible to emit signals to gdscript but calling the GDScript dummy "
"object."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:420
msgid "MessageQueue"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:422
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. Queue will be flushed "
"whenever either ``SceneTree::idle`` or ``SceneTree::iteration`` are executed."
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:431
msgid ""
"`core/message_queue.cpp <https://github.com/godotengine/godot/blob/master/"
"core/message_queue.cpp>`__"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:434
msgid "Summing it up"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:436
msgid "Here is the GDScript sample code"
msgstr ""

#: ../../docs/development/cpp/custom_godot_servers.rst:471
msgid ""
"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:473
msgid "Connecting signal example code is pretty hacky"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:4
msgid "Creating Android modules"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:9
msgid ""
"Making video games portable is all fine and dandy, until mobile gaming "
"monetization shows up."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:12
msgid ""
"This area is complex, usually a mobile game that monetizes needs special "
"connections to a server for thingst like:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:15
msgid "Analytics"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:16
msgid "In-app purchases"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:17
msgid "Receipt validation"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:18
msgid "Install tracking"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:19
msgid "Ads"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:20
msgid "Video ads"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:21
msgid "Cross-promotion"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:22
msgid "In-game soft & hard currencies"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:23
msgid "Promo codes"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:24
msgid "A/B testing"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:25
msgid "Login"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:26
msgid "Cloud saves"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:27
msgid "Leaderboards and scores"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:28
msgid "User support & feedback"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:29
msgid "Posting to Facebook, Twitter, etc."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:30
msgid "Push notifications"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:32
msgid ""
"On iOS, you can write a C++ module and take advantage of the C++/ObjC "
"intercommunication."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:35
msgid ""
"On Android, interfacing with C++ through JNI (Java Native Interface) isn't "
"as convenient."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:38
msgid "Maybe REST?"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:40
msgid ""
"Most of these APIs allow communication via REST/JSON APIs. Godot has great "
"support for HTTP, HTTPS and JSON, so consider this as an option that works "
"on every platform. Only write the code once and you are set to go."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:46
msgid "Android module"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:48
msgid ""
"Writing an Android module is similar to :ref:`doc_custom_modules_in_c++`, "
"but needs a few more steps."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:51
msgid ""
"Make sure you are familiar with building your own :ref:`Android export "
"templates <doc_compiling_for_android>`, as well as creating :ref:"
"`doc_custom_modules_in_c++`."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:55
msgid "config.py"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:57
msgid ""
"In the config.py for the module, some extra functions are provided for "
"convenience. First, it's often wise to detect if Android is the target "
"platform being built for and only enable building in this case:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:66
msgid ""
"If more than one platform can be built (typical if implementing the module "
"also for iOS), check manually for Android in the configure functions for "
"Android (or other platform-specific) code:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:80
msgid "Java singleton"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:82
msgid ""
"An Android module will usually have a singleton class that will load it, "
"this class inherits from ``Godot.SingletonBase``. Resource identifiers for "
"any additional resources you have provided for the module will be in the "
"``com.godot.game.R`` class, so you'll likely want to import it."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:87
msgid "A singleton object template follows:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:134
msgid ""
"Calling back to Godot from Java is a little more difficult. The instance ID "
"of the script must be known first, this is obtained by calling "
"``get_instance_ID()`` on the script. This returns an integer that can be "
"passed to Java."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:139
msgid ""
"From Java, use the ``calldeferred`` function to communicate back with Godot. "
"Java will most likely run in a separate thread, so calls are deferred:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:146
msgid ""
"Add this singleton to the build of the project by adding the following to "
"config.py:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:162
msgid "AndroidManifest"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:164
msgid ""
"Some SDKs need custom values in AndroidManifest.xml. Permissions can be "
"edited from the godot exporter so there is no need to add those, but maybe "
"other functionalities are needed."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:168
msgid ""
"Create the custom chunk of android manifest and put it inside the module, "
"add it like this:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:187
msgid ""
"In order to provide additional resources with your module you have to add "
"something like this:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:197
msgid ""
"Now you can refer to those resources by their id (``R.string.my_string``, "
"and the like) by importing the ``com.godot.game.R`` class in your Java code."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:201
msgid "SDK library"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:203
msgid ""
"So, finally it's time to add the SDK library. The library can come in two "
"flavors, a JAR file or an Android project for ant. JAR is the easiest to "
"integrate, put it in the module directory and add it:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:223
msgid "SDK project"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:225
msgid ""
"When this is an Android project, things usually get more complex. Copy the "
"project folder inside the module directory and configure it:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:232
msgid ""
"As of this writing, Godot uses minsdk 10 and target sdk 15. If this ever "
"changes, it should be reflected in the manifest template: `AndroidManifest."
"xml.template <https://github.com/godotengine/godot/blob/master/platform/"
"android/AndroidManifest.xml.template>`"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:236
msgid "Then, add the module folder to the project:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:252
msgid "Building"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:254
msgid ""
"As you probably modify the contents of the module, and modify your .java "
"inside the module, you need the module to be built with the rest of Godot, "
"so compile android normally."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:262
msgid ""
"This will cause your module to be included, the .jar will be copied to the "
"java folder, the .java will be copied to the sources folder, etc. Each time "
"you modify the .java, scons must be called."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:266
msgid ""
"Afterwards, continue the steps for compiling android  :ref:"
"`doc_compiling_for_android`."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:271
msgid ""
"To use the module from GDScript, first enable the singleton by adding the "
"following line to project.godot:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:280
msgid ""
"More than one singleton module can be enabled by separating with commas:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:288
msgid "Then request the singleton Java object from Globals like this:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:304
msgid "Godot crashes upon load"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:306
msgid "Check ``adb logcat`` for possible problems, then:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:308
msgid "Make sure libgodot_android.so is in the ``libs/armeabi`` folder"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:309
msgid ""
"Check that the methods used in the Java singleton only use simple Java "
"datatypes, more complex ones are not supported."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:313
msgid "Future"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:315
msgid ""
"Godot has an experimental Java API Wrapper that allows to use the entire "
"Java API from GDScript."
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:318
msgid "It's simple to use and it's used like this:"
msgstr ""

#: ../../docs/development/cpp/creating_android_modules.rst:324
msgid ""
"This is most likely not functional yet, if you want to test it and help us "
"make it work, contact us through the `developer mailing list <https://groups."
"google.com/forum/#!forum/godot-engine>`__."
msgstr ""

#: ../../docs/development/file_formats/index.rst:2
msgid "Godot file formats"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:2
msgid "TSCN File Format"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:4
msgid ""
"A :code:`.tscn` File format is the \"Text SCeNe\" file format and represents "
"a single scene-tree inside Godot. TSCN files have the advantage of being "
"nearly human-readable and easy for version control systems to manage. During "
"import the TSCN files are compiled into binary :code:`.scn` files stored "
"inside the .import folder. This reduces the data size and speed up loading."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:10
msgid ""
"The :code:`.escn` 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 `scene_format_text.cpp <https://github.com/godotengine/godot/blob/"
"master/scene/resources/scene_format_text.cpp>`_ in the class :code:"
"`ResourceFormatLoaderText`"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:20
msgid "File Structure"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:22
msgid "There are five main sections inside the TSCN File:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:24
msgid "File Descriptor"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:25
msgid "External resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:26
msgid "Internal resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:31
msgid ""
"The file descriptor looks like :code:`[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, though in practice it's "
"value seems not to matter."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:36
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 :code:`[ext_resource .....]`"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:44
msgid "Entries inside the file"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:45
msgid ""
"A heading looks like: :code:`[<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 ""
"Underneath every heading comes zero or more :code:`key = value` pairs. The "
"values can be complex datatypes such as arrays, transformations, colors, and "
"so on. For example, a spatial node looks like:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:64
msgid "The Scene Tree"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:66
msgid ""
"The scene tree is made up of ... nodes! The heading of each node consists of "
"it's name, parent and (most of the time) a type. For example :code:`[node "
"type=\"Camera\" name=\"PlayerCamera\" parent=\"Player/Head\"]`"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:70
msgid "Other valid keywords include:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:72
msgid "instance"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:73
msgid "instance_placeholder"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:74
msgid "owner"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:75
msgid "index (if two nodes have the same name)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:76
msgid "groups"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:78
msgid ""
"The first node in the file should not have the :code:`parent=Path/To/Node` "
"entry in it's heading, and it is the scene root. All scene files should have "
"exactly one scene root. It it does not, Godot will fail to import the file. "
"The parent path of other nodes should be absolute, but without the scene "
"root's name. If it is a direct child of the scene root, it should be :code:`"
"\".\"`. Here is an example scene tree (but without any node content). ::"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:91
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:129
msgid "Node Path"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:131
msgid ""
"A tree structure is not enough to represent the whole scene, Godot use a :"
"code:`NodePath(Path/To/Node)` structure to refer to another node or "
"attribute of the node anywhere in the scene tree. Some typical usages of "
"NodePath like mesh node use :code:`NodePath()` to point to its skeleton, "
"animation track use :code:`NodePath()` points to animated attribute in node."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:154
msgid "Skeleton"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:155
msgid ""
"Skeleton node inherits Spatial node, besides that it may have a list of "
"bones described in key, value pair in the format :code:`bones/Id/"
"Attribute=Value`, attributes of bone consisits of"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:159
msgid "name"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:160
msgid "parent"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:161
msgid "rest"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:162
msgid "pose"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:163
#: ../../docs/development/file_formats/tscn.rst:384
msgid "enabled"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:164
msgid "bound_children"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:166
msgid ":code:`name` must put as the first attribute of each bone"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:168
msgid ""
":code:`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:171
msgid ":code:`rest` is the transform matrix of bone in rest position"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:173
msgid ":code:`pose` is the pose matrix use :code:`rest` as basis"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:175
msgid ""
":code:`bound_children` is a list of NodePath() points to BoneAttachments "
"belong to this bone"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:178
msgid "An example of a skeleton node with two bones:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:198
msgid "BoneAttachment"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:199
msgid ""
"BoneAttachment node is an intermediate node to describe some node being "
"parented to a single bone in Skeleton node. The BoneAttachment has a :code:"
"`bone_name=NameOfBone`, and the corresponding bone being the parent has the "
"BoneAttachment node in its :code:`bound_children` list."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:204
msgid "An example of one MeshInstance parented to a bone in Skeleton:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:228
msgid "AnimationPlayer"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:229
msgid ""
"AnimationPlayer works as an animation lib. it has animations listed in the "
"format :code:`anim/Name=SubResource(ResourceId)`, each refers to a Animation "
"internal resource. All the animation resources use the root node of "
"AnimationPlayer. The root node is stored as :code:`root_node=NodePath(Path/"
"To/Node)`."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:250
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:254
msgid ""
"References to the resources are handled by id numbers in the resources "
"heading. External resources and internal resource are referred to with :code:"
"`ExtResource(id)` and :code:`SubResource(id)`. Because there have different "
"methods to refer to internal and external resource, you can have the same ID "
"for both an internal and external resource."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:260
msgid ""
"For example, to refer to the resource :code:`[ext_resource id=3 type="
"\"PackedScene\" path=....]` you would use :code:`ExtResource(3)`"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:266
msgid "External Resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:268
msgid ""
"External resources are links to resources not contained within the TSCN file "
"itself. An external resource consists of:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:271
msgid "A path"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:272
msgid "A type"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:273
msgid "An ID"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:275
msgid ""
"Godot alway generates absolute paths relative to the resource directory and "
"thus prefixed with :code:`res://`, but paths relative to the TSCN file's "
"location are also valid."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:279
msgid "Some example external resources are:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:288
msgid "Internal Resources"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:290
msgid ""
"A TSCN file can contain meshes, materials and other data, and these are "
"contained in the internal resources section of the file. The heading for an "
"internal resource looks similar to those of external resources, but does not "
"have a path. Internal resources also have :code:`key=value` pairs under each "
"heading. For example, a capsule collision shape looks like:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:303
msgid ""
"Some internal resource 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. Thus, in the internal resources section of the "
"file, order does matter."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:308
msgid ""
"Unfortunately, documentation on the formats for these subresources is not "
"complete, and while some can be found through inspecting resources of saved "
"files, others can only be found by looking through Godot's source."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:313
msgid "ArrayMesh"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:314
msgid ""
"ArrayMesh consists of several surfaces, each in the format :code:`surface"
"\\Index={}`, each surface is a set of vertex and a material."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:317
msgid "TSCN support two format of surface,"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:319
msgid "for the old format, each surface has three essential keys:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:321
msgid "primitive"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:322
msgid "arrays"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:323
msgid "morph_arrays"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:325
msgid ""
":code:`primitive` is an enumerate variable, :code:`primitive=4` which is "
"PRIMITIVE_TRIANGLES is frequently used."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:328
msgid ":code:`arrays` as name suggestes is an array of array, it contains:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:330
msgid "a array of vertex position"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:331
msgid "tagents array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:332
msgid "vertex color array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:333
msgid "UV array 1"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:334
msgid "UV array 2"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:335
msgid "bone index array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:336
msgid "bone weight array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:337
msgid "vertex index array"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:339
msgid ""
":code:`morph_arrays` is an array of morph, each morph is exactly an :code:"
"`arrays` without vertex index array."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:342
msgid "An example of ArrayMesh:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:366
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:369
msgid "length"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:370
msgid "loop"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:371
msgid "step"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:373
msgid ":code:`length` and :code:`step` are both time in seconds"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:375
msgid ""
"Each track is described by a list of key, value pairt in the format :code:"
"`tracks/Id/Attribute`, it includs:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:378
msgid "type"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:379
msgid "path"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:380
msgid "interp"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:381
msgid "keys"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:382
msgid "loop_wrap"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:383
msgid "imported"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:387
msgid ""
"The :code:`type` must be put as the first attribute of each track. The value "
"of :code:`type` can be:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:390
msgid "'transform'"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:391
msgid "'value'"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:392
msgid "'method'"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:394
msgid ""
"The :code:`path` has the format :code:`NodePath(Path/To/Node:Attribute)`. It "
"is the path from animation root node (property of AnimationPlayer) to the "
"animated node or attrbute."
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:398
msgid ""
"The :code:`interp` is the method to interpolate frames from the keyframes. "
"it is a enum variable and can has value:"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:401
#, fuzzy
msgid "0 (constant)"
msgstr "ثابت ها"

#: ../../docs/development/file_formats/tscn.rst:402
msgid "1 (linear)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:403
msgid "2 (cubic)"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:405
msgid ""
"The :code:`keys` is the keyframes, it appears as a PoolRealArray() but have "
"different structure for track with different type"
msgstr ""

#: ../../docs/development/file_formats/tscn.rst:408
msgid ""
"A transform track use every 12 real number in the :code:`keys` to describte "
"a keyframe. The first number is the timestamp, the second number is the "
"transision (default 1.0 in transform track), followed by a three number "
"translation vector, followed by four number rotation quaternion (x,y,z,w) "
"and finally a three number scale vector."
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 promotion 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 300 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 nice place to start may be the issue tagged as `junior jobs <https://"
"github.com/godotengine/godot/issues?q=is%3Aissue+is%3Aopen+label%3A%22junior"
"+job%22>`_ 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/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 "
"organisation 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 documention, 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.0`` and ``2.1``. "
"They are used to backport bugfixes and enhancements from the ``master`` "
"branch to the currently maintained stable release (e.g. 3.0.2 or 2.1.5). As "
"a rule of thumb, the last stable branch is maintained until the next major "
"version (e.g. the ``2.0`` branch was maintained until the release of Godot "
"2.1). If you want to make PRs against a maintained stable branch, you will "
"have to check if your changes are also relevant for the ``master`` branch."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:65
msgid ""
"There might be feature branches at time, usually meant to be merged into the "
"``master`` branch at some time."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:69
msgid "Forking and cloning"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:71
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:78
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:83
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:88
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:91
msgid "To clone your fork from GitHub, use the following command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:97
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:101
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:108
msgid ""
"We will start by setting up a reference to the original repository that we "
"forked:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:115
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."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:120
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:124
msgid ""
"*Branch it, pull it, code it, stage it, commit, push it, rebase it... "
"technologic.*"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:127
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:135
msgid ""
"In the following, we will assume 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:140
msgid "Branching"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:142
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:154
msgid "This command is equivalent:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:161
msgid "If you want to go back to the ``master`` branch, you'd use:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:167
msgid ""
"You can see which branch you are currently on with the ``git branch`` "
"command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:178
msgid "Updating your branch"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:180
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:186
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:194
msgid ""
"However, if you had local commits, this method will create a so-called "
"\"merge commit\", and you will soon hear from fellow contributors that those "
"are not wanted in PRs. Then how to update the branch without creating a "
"merge commit? You will have to use the ``--rebase`` option, so that your "
"local commits are replayed on top of the updated upstream ``master`` branch. "
"It will effectively modify the Git history of your branch, but that is for "
"the greater good."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:201
msgid "Therefore, the command that you should (almost) always use is:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:208
msgid "Making changes"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:210
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:214
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:221
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:224
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:226
msgid ""
"``git checkout -- <files>`` will undo the unstaged changes to the given "
"files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:228
msgid "``git add <files>`` will *stage* the changes on the listed files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:229
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:231
msgid "``git reset HEAD <files>`` will *unstage* changes to the listed files."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:232
msgid ""
"``git status`` will show you what are the currently staged and unstaged "
"modifications."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:234
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:239
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:241
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:244
msgid ""
"That's a lot to memorise! 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:247
msgid "Here's how the shell history could look like on our example:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:279
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:284
msgid "Pushing changes to a remote"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:286
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:295
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:303
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:308
msgid "Issuing a pull request"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:310
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:317
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:323
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:329
msgid "Modifying a pull request"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:331
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:335
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:350
msgid "That should do the trick, but..."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:353
msgid "Mastering the PR workflow: the rebase"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:355
msgid ""
"On the situation outlined above, your fellow contributors who are "
"particularly pedantic regarding the Git history might ask your to *rebase* "
"your branch to *squash* or *meld* the last two commits together (i.e. the "
"two related to the project manager), as the second commit basically fixes an "
"issue in the first one."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:360
msgid ""
"Once the PR is merged, it is not relevant for a changelog reader that the PR "
"author made mistakes; instead, we want to keep only commits that bring from "
"one working state to another working state."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:364
msgid ""
"To squash those two commits together, 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:369
msgid ""
"We will use the *interactive rebase* ``git rebase -i`` to do this. This "
"command takes a commit hash as argument, and will let you modify all commits "
"between that commit hash and the last one of the branch, the so-called "
"*HEAD*. In our example, we want to act on the last two commits, so we will "
"do:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:380
msgid "This will open a text editor with:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:387
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:400
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:405
msgid ""
"You could have avoided this rebase by using ``git commit --amend`` when "
"fixing the typo. This command will write the staged changes directly into "
"the *last* commit (``HEAD``), instead of creating a new commit like we did "
"in this example. So it is equivalent to what we did with a new commit and "
"then a rebase to mark it as \"fixup\"."
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:411
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:425
msgid ""
"This is a sane behaviour, 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:433
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:438
msgid "Deleting a Git branch"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:440
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:445
msgid "To delete our better project manager branch locally, use this command:"
msgstr ""

#: ../../docs/community/contributing/pr_workflow.rst:451
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:454
msgid "Next, to delete the remote branch on GitHub use this command:"
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:27
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:31
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:36
msgid ""
"Godot's code style should *not* be applied to thirdparty 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:43
msgid ""
"Thirdparty code is usually included in the ``thirdparty/`` folder and can "
"thus easily be excluded from formatting scripts. For the rare cases where a "
"thirdparty 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:51
msgid "Using clang-format locally"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:53
msgid ""
"First of all, you will need to install clang-format. As of now, you need to "
"use **clang-format 5.x** to be compatible with Godot's format. The upcoming "
"6.x branch has not been tested yet and my cause inconsistencies; the "
"previous 3.x branch is incompatible with the style definitions and will "
"error out."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:59
msgid "Installation"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:61
msgid "Here's how to install clang-format:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:63
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:68
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:73
msgid ""
"You then have different possibilities to apply clang-format to your changes:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:76
msgid "Manual usage"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:78
msgid ""
"You can apply clang-format manually one or more files with the following "
"command:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:85
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:87
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:93
msgid "Pre-commit hook"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:95
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:99
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:102
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:108
msgid "IDE plugin"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:110
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:113
msgid "Here is a non-exhaustive list of beautifier plugins for some IDEs:"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:115
msgid ""
"Qt Creator: `Beautifier plugin <http://doc.qt.io/qtcreator/creator-"
"beautifier.html>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:116
msgid ""
"Visual Studio Code: `Clang-Format <https://marketplace.visualstudio.com/"
"items?itemName=xaver.clang-format>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:117
msgid ""
"Visual Studio: `ClangFormat <https://marketplace.visualstudio.com/items?"
"itemName=LLVMExtensions.ClangFormat>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:118
msgid "vim: `vim-clang-format <https://github.com/rhysd/vim-clang-format>`__"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:120
msgid "(Pull requests welcome to extend this list with tested plugins.)"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:123
msgid "Java"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:125
msgid ""
"For Godot's Java code (mostly in ``platform/android``), there is currently "
"no style guide, so for now try to stay consistent with the existing code."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:128
msgid ""
"Once a style is decided upon, it could also be enforced via clang-format."
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:131
msgid "Python"
msgstr ""

#: ../../docs/community/contributing/code_style_guidelines.rst:133
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:136
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*, *OS X*, *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 <http://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:17
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 "What makes good documentation?"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:42
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:46
msgid ""
"We differentiate tutorial pages from other documentation pages by these "
"definitions:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:49
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:53
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:57
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:61
msgid "Titles"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:63
msgid "Always begin pages with their title and a Sphinx reference name:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:72
msgid ""
"The reference allows to link 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:76
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:80
msgid "Insert your title here"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:82
msgid "And this is a bad example:"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:84
msgid "Insert Your Title Here"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:86
msgid ""
"Only project, people and node class names should have capitalized first "
"letter."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:90
msgid "Translating existing pages"
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:92
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:99
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 "
"synced."
msgstr ""

#: ../../docs/community/contributing/documentation_guidelines.rst:104
#, 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 ""
"تمام مطالب تحت مجوز Creative Commons Attribution 3.0 (`CC-BY 3.0 <https://"
"creativecommons.org/licenses/by/3.0/>`_) به نام «Juan Linietsky, Ariel "
"Manzur و انجمن موتور گودات» می‌باشد."

#: ../../docs/community/contributing/documentation_guidelines.rst:107
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:40
msgid "Use the direct voice"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:15
#: ../../docs/community/contributing/docs_writing_guidelines.rst:76
msgid "Use precise action verbs"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:16
#: ../../docs/community/contributing/docs_writing_guidelines.rst:98
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:212
msgid "Use explicit references"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:20
#: ../../docs/community/contributing/docs_writing_guidelines.rst:233
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:280
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:309
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:334
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 a clear english"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:42
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:48
msgid "Passive:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:54
msgid "Active:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:61
#: ../../docs/community/contributing/docs_writing_guidelines.rst:315
msgid "**Don't** use the passive voice:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:68
msgid "**Do** use the node's name as a noun:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:78
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:81
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:89
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:100
msgid ""
"The progressive forms describe continuous actions. E.g. \"is calling\", \"is "
"moving\"."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:103
msgid "**Don't** use the progressive form for instant changes."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:110
msgid "**Do** use simple present, preterit or future."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:117
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:122
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:127
msgid "Remove unnecessary adverbs and adjectives"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:129
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:132
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:139
msgid "**Do** write short sentences in a simple, descriptive language:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:146
msgid "Ban these 8 words"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:148
msgid "**Don't** ever use these 8 banned words:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:150
msgid "obvious"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:151
msgid "simple"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:152
msgid "basic"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:153
msgid "easy"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:154
msgid "actual"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:155
msgid "just"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:156
msgid "clear"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:157
msgid "however (some uses)"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:159
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:165
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:173
msgid "**Do** remove them:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:180
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:190
msgid "**Do** explain what the node does instead:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:197
msgid "**Don't** use \"basic\", it is too vague:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:204
msgid "**Do** use the brief description to offer an overview of the node:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:214
msgid "Favor explicit references over implicit ones."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:216
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:223
msgid "**Do** repeat words. They remove all ambiguity:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:229
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:235
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:238
msgid "**Don't** write \"of the X\":"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:244
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:252
msgid "Use the Oxford comma to enumerate anything"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:254
msgid "From the Oxford dictionary:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:256
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:259
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:262
msgid "**Don't** leave the last element of a list without a comma:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:268
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:277
msgid "How to write methods and classes"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:282
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:285
msgid "It's the only description in the \"Create New Node\" dialog."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:286
msgid "It's at the top of every page in the reference"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:288
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:291
msgid "**Don't** write tiny and vague summaries:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:298
msgid "**Do** give an overview of the node's functionality:"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:305
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:311
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:322
msgid "**Do** always use \"Returns\"."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:329
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:336
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:340
msgid ""
"Also surround boolean values, variable names and methods with [code][/code]."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:342
msgid "**Do** start with \"if true\":"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:351
msgid "Use [code] around arguments"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:353
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:357
msgid "Common vocabulary to use in godot's docs"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:359
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:367
msgid "Overview of the interface and common vocabulary"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:369
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:375
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:381
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:384
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:391
msgid "Image Contribution guidelines"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:393
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:396
msgid ""
"First, you should always be using the default editor theme and text when "
"taking screenshots."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:398
msgid ""
"For 3D screenshots use 4xMSAA, enable anisotropic filtering on the projects "
"textures, and set the anisotropic filter quality to 16x in Project Settings"
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:401
msgid "Screenshot size should not exceed 1920x1080."
msgstr ""

#: ../../docs/community/contributing/docs_writing_guidelines.rst:403
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:406
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 done. However you should also "
"use a lossy one, 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:6
msgid ""
"Godot ships with many nodes and singletons to help you develop your games in "
"GDscript. 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:8
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:10
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:13
msgid ""
"This guide is available as a `Youtube video <https://www.youtube.com/watch?"
"v=mKKjOulm5XI>`_."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:19
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:21
msgid "There are 5 steps to update the class reference (full guide below):"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:23
msgid "Fork `Godot's repository <https://github.com/godotengine/godot>`_"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:24
msgid "Clone your fork on your computer"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:25
msgid "Edit the class file in ``doc/classes/`` to write documentation"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:26
msgid "Commit your changes and push them to your fork"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:27
msgid "Make a pull request on the Godot repository"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:29
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:32
msgid "Get started with GitHub"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:34
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:36
msgid "Fork and clone Godot's repository"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:37
msgid "Keep your fork up to date with other contributors"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:38
msgid "Create a pull request so your improvements end in the official docs"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:40
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:43
msgid "Fork Godot"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:45
msgid "Fork the Godot Engine into a GitHub repository of your own."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:47
msgid "Clone the repository on your computer:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:53
msgid ""
"Create a new branch to make your changes. It makes it a lot easier to sync "
"your improvements with other docs writers, and it's easier to cleanup your "
"repository clean if you have any issues with git."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:59
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:62
msgid "How to keep your local clone up-to-date"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:64
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:66
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:72
msgid "You can check the list of all remote servers with:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:78
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:88
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:94
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:96
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:103
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:105
msgid ""
"Another option is to delete the branch you're working on, synchronize the "
"master branch with the Godot repository, and create a brand new branch:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:114
msgid ""
"If you're feeling lost by now, come to our `IRC channels <http://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:117
msgid "Updating the documentation template"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:119
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:125
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:132
msgid "You are now ready to edit this file to add stuff."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:134
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:137
msgid "Push and request a pull of your changes"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:139
msgid ""
"Once your modifications are finished, push your changes on your GitHub "
"repository:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:148
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:152
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:154
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:157
msgid "How to edit class XML"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:159
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:161
msgid ""
"Edit it using your favourite 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:164
msgid "How to write the class reference"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:166
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:168
msgid "Our job is to add the missing text between these marks:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:170
msgid "<description></description>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:171
msgid "<brief_description></brief_description>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:172
msgid "<constant></constant>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:173
msgid "<method></method>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:174
msgid "<member></member>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:175
msgid "<signal></signal>"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:177
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:179
msgid "Here's how a class looks like in XML:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:218
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:222
msgid "Improve formatting with BBcode style tags"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:224
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:227
msgid "Effect"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:227
msgid "Result"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:229
msgid "[Class]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:229
msgid "Link a class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:229
msgid "Move the [Sprite]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:229
msgid "Move the :ref:`class_sprite`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:231
msgid "[method methodname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:231
msgid "Link to a method in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:231
msgid "Call [method hide]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:231
#: ../../docs/community/contributing/updating_the_class_reference.rst:233
msgid "See :ref:`hide <class_spatial_hide>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:233
msgid "[method Class.methodname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:233
msgid "Link to another class's method"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:233
msgid "Call [method Spatial.hide]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:235
msgid "[member membername]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:235
msgid "Link to a member in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:235
msgid "Get [member scale]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:235
#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Get :ref:`scale <class_node2d_scale>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "[member Class.membername]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Link to another class's member"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:237
msgid "Get [member Node2D.scale]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "[signal signalname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "Link to a signal in this class"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
msgid "Emit [signal renamed]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:239
#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "Emit :ref:`renamed <class_node_renamed>`."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "[signal Class.signalname]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "Link to another class's signal"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:241
msgid "Emit [signal Node.renamed]."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "[b] [/b]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "Bold"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "Some [b]bold[/b] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:243
msgid "Some **bold** text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "[i] [/i]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "Italic"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "Some [i]italic[/i] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:245
msgid "Some *italic* text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "[code] [/code]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Monospace"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Some [code]monospace[/code] text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:247
msgid "Some ``monospace`` text."
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "[codeblock] [/codeblock]"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "Multiline preformatted block"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:249
msgid "*See below.*"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:252
msgid ""
"Use ``[codeblock]`` for pre-formatted code blocks. Inside ``[codeblock]``, "
"always use spaces for indentation (the parser will delete tabs). Example:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:262
msgid "Will display as:"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:272
msgid "I don't know what this method does!"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:274
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:276
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:280
msgid "Localization"
msgstr ""

#: ../../docs/community/contributing/updating_the_class_reference.rst:282
msgid ""
"Before we translate the documentation, we need to complete and proof-read it "
"in English. We'll work on localization when we get past 90% completion."
msgstr ""

#: ../../docs/community/channels.rst:4
msgid "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
msgid ""
"A brief overview over these channels is also available on the `website "
"<https://godotengine.org/community>`_."
msgstr ""

#: ../../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 ""
"`GDNative: #godotengine-gdnative <http://webchat.freenode.net/?"
"channels=#godotengine-gdnative>`_"
msgstr ""

#: ../../docs/community/channels.rst:24
msgid ""
"`Webseite/PR: #godotengine-atelier <http://webchat.freenode.net/?"
"channels=#godotengine-atelier>`_"
msgstr ""

#: ../../docs/community/channels.rst:25
msgid "`IRC logs <https://godot.eska.me/irc-logs/>`_"
msgstr ""

#: ../../docs/community/channels.rst:28
msgid "Other chats"
msgstr ""

#: ../../docs/community/channels.rst:30
msgid ""
"`Matrix (IRC compatible) <https://matrix.to/#/#godotengine:matrix.org>`_"
msgstr ""

#: ../../docs/community/channels.rst:31
msgid "`Discord <https://discordapp.com/invite/zH7NUgz>`_"
msgstr ""

#: ../../docs/community/channels.rst:34
msgid "Social networks"
msgstr ""

#: ../../docs/community/channels.rst:36
msgid "`GitHub <https://github.com/godotengine/>`_"
msgstr ""

#: ../../docs/community/channels.rst:37
msgid "`Facebook group <https://www.facebook.com/groups/godotengine/>`_"
msgstr ""

#: ../../docs/community/channels.rst:38
msgid "`Twitter (also, #godotengine) <https://twitter.com/godotengine>`_"
msgstr ""

#: ../../docs/community/channels.rst:39
msgid "`Reddit <https://www.reddit.com/r/godot>`_"
msgstr ""

#: ../../docs/community/channels.rst:40
msgid "`Youtube <https://www.youtube.com/c/GodotEngineOfficial>`_"
msgstr ""

#: ../../docs/community/channels.rst:41
msgid "`Steam <https://steamcommunity.com/app/404790>`_"
msgstr ""

#: ../../docs/community/channels.rst:44
msgid "Forum"
msgstr ""

#: ../../docs/community/channels.rst:46
msgid "`Forum (godotdevelopers.org) <https://godotdevelopers.org/forum>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:6
msgid ""
"This is a list of third-party tutorials created by the community that may be "
"of interest."
msgstr ""

#: ../../docs/community/tutorials.rst:9
msgid "Video tutorials"
msgstr ""

#: ../../docs/community/tutorials.rst:11
msgid ""
"`GDQuest <https://www.youtube.com/channel/UCxboW7x0jZqFdvMdCFKTMsQ/"
"playlists>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:12
msgid ""
"`KidsCanCode <https://www.youtube.com/channel/UCNaPQ5uLX5iIEHUCLmfAgKg/"
"playlists>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:13
msgid ""
"`Game from Scratch: Godot 3 Tutorial Series <https://www.youtube.com/watch?"
"v=iDEcP8Mc-7s&list=PLS9MbmO_ssyDk79j9ewONxV88fD5e_o5d>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:14
msgid ""
"`HeartBeast <https://www.youtube.com/watch?v=wETY5_9kFtA&list=PL9FzW-"
"m48fn2jlBu_0DRh7PvAt-GULEmd>`_"
msgstr ""

#: ../../docs/community/tutorials.rst:15
msgid "`Steincodes <https://www.youtube.com/c/steincodes/playlists>`_"
msgstr ""

#: ../../docs/community/resources.rst:6
msgid ""
"This is a list of third-party resources created by the community that may be "
"of interest."
msgstr ""

#: ../../docs/community/resources.rst:11
msgid ""
"`awesome-godot: A curated list of resources by Calinou <https://github.com/"
"Calinou/awesome-godot>`_"
msgstr ""

#: ../../docs/community/resources.rst:12
msgid ""
"`Zeef Godot Engine: A curated directory of resources by Andre Schmitz "
"<https://godot-engine.zeef.com/andre.antonio.schmitz>`_"
msgstr ""