godotengine/godot-docs-l10n
1
0
Fork 0
mirror of https://github.com/godotengine/godot-docs-l10n.git synced 2026-01-05 14:10:19 +03:00
Code Issues Packages Projects Releases Wiki Activity

Generate Sphinx templates from current rst source

Browse Source
This commit is contained in:
Rémi Verschelde
2018-04-10 12:23:26 +02:00
parent 14efd8e5d2
commit 57e7cecaab
192 changed files with 41688 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

432
sphinx/templates/about/faq.pot Normal file
View File

@@ -0,0 +1,432 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/about/faq.rst:4
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
msgid "Android"
msgstr ""
#: ../../docs/about/faq.rst:48
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 system 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 very simple and easy to learn. Takes at most a day or two to get comfortable and it's very easy to see the benefits once you do. Please do 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 very well supported by GDScript."
msgstr ""
#: ../../docs/about/faq.rst:128
msgid "GDScript was designed to solve the issues above, and performs very well in all the above scenarios. Please learn GDScript and enjoy a very smooth integration of scripting with the game engine (yes, it's a rare but very 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 very `restrictive license <http://www.blender.org/bf/Autodesk_FBX_License.rtf>`_, that is incompatible with the `open license <http://opensource.org/licenses/MIT>`_ provided by Godot."
msgstr ""
#: ../../docs/about/faq.rst:158
msgid "That said, Godot's Collada support is really 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 really is a desire to make your game also work on ancient devices with tiny screens (less 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 ""

22
sphinx/templates/about/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/about/index.rst:2
msgid "About"
msgstr ""

106
sphinx/templates/about/introduction.pot Normal file
View File

@@ -0,0 +1,106 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/about/introduction.rst:4
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 ""
#: ../../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 ""
#: ../../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 ""
#: ../../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 ""
#: ../../docs/about/introduction.rst:34
msgid "Godot is completely free and open source under the very 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 ""
#: ../../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 ""
#: ../../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>`_."
msgstr ""
#: ../../docs/about/introduction.rst:59
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 ""
#: ../../docs/about/introduction.rst:64
msgid "Organisation of the documentation"
msgstr ""
#: ../../docs/about/introduction.rst:66
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:70
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 ""
#: ../../docs/about/introduction.rst:73
msgid "The :ref:`sec-learn` section is the 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 ""
#: ../../docs/about/introduction.rst:78
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:80
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:83
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:88
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:94
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:97
msgid "Have fun reading and making games with Godot Engine!"
msgstr ""

118
sphinx/templates/community/channels.pot Normal file
View File

@@ -0,0 +1,118 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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://discord.gg/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) <http://godotdevelopers.org/>`_"
msgstr ""

222
sphinx/templates/community/contributing/bug_triage_guidelines.pot Normal file
View File

@@ -0,0 +1,222 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

178
sphinx/templates/community/contributing/code_style_guidelines.pot Normal file
View File

@@ -0,0 +1,178 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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://llvm.org/releases/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://llvm.org/releases/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.python.org/pypi/autopep8>`__."
msgstr ""

403
sphinx/templates/community/contributing/docs_writing_guidelines.pot Normal file
View File

@@ -0,0 +1,403 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

126
sphinx/templates/community/contributing/documentation_guidelines.pot Normal file
View File

@@ -0,0 +1,126 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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."
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:11
msgid "How to contribute"
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:13
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:20
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:25
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:29
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:37
msgid "What makes good documentation?"
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:39
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."
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:43
msgid "We differentiate tutorial pages from other documentation pages by these definitions:"
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:46
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:50
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:54
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). In particular, you can contribute tutorials in the \"Community\" section of the docs, where they could be merged relatively easily, improved by other contributors and eventually moved to an \"official\" section if relevant."
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 "For the moment, only English documentation is provided. We want to propose localized documentation in the future, but this is not a priority for now. Indeed, since the English documentation is still evolving a lot as the community improves it and make it more professional, we prefer that translators do not spend too much time on it, as their translated documentation might quickly grow out of sync with the original."
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:99
msgid "When the English documentation is ready for translations, we will provide tools to simplify the work of translators by tracking changes to the English docs that they should translate on their end."
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:104
msgid "License"
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:106
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), with attribution to \"Juan Linietsky, Ariel Manzur and the Godot community\"."
msgstr ""
#: ../../docs/community/contributing/documentation_guidelines.rst:110
msgid "By contributing to the documentation on the GitHub repository, you agree that your changes are distributed under this license."
msgstr ""

22
sphinx/templates/community/contributing/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/community/contributing/index.rst:2
msgid "Contributing"
msgstr ""

346
sphinx/templates/community/contributing/pr_workflow.pot Normal file
View File

@@ -0,0 +1,346 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 qucikly 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 Mac, if you're using Linux install it through your package manager."
msgstr ""
#: ../../docs/community/contributing/pr_workflow.rst:88
msgid "if you are on Windows open Git Bash to type commands. Mac 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 "Then command that you should (almost) always use is there:"
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 config) 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 wont 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 ""

478
sphinx/templates/community/contributing/updating_the_class_reference.pot Normal file
View File

@@ -0,0 +1,478 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:17
msgid "How to contribute"
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 2: ``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 "Tag"
msgstr ""
#: ../../docs/community/contributing/updating_the_class_reference.rst:227
msgid "Effect"
msgstr ""
#: ../../docs/community/contributing/updating_the_class_reference.rst:227
msgid "Usage"
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
#: ../../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 ""

166
sphinx/templates/community/contributing/ways_to_contribute.pot Normal file
View File

@@ -0,0 +1,166 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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). The following sections will cover each of those \"direct\" ways of contributing to the engine."
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:39
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 our lead developer Juan Linietsky, so that he 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 <http://godotengine.org/donate>`_ for details."
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:53
msgid "Contributing code"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:55
msgid "The possibility to study, use, modify and redistribute modifications of the engine's source code are the fundamental rights that Godot's license grant 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:59
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:66
msgid "Contributing code changes upstream has two big advantages:"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:68
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:76
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:81
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:85
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:88
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:93
msgid "Testing and reporting issues"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:95
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:101
msgid "Testing development versions"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:103
msgid "To help with the testing, you have several possibilities:"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:105
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:108
msgid "Test official pre-release binaries when they are announced (usually on the blog and other community platforms), such as alpha, beta and RC (release candidate) builds."
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:112
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:117
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:123
msgid "Filing an issue on GitHub"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:125
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:129
msgid "When you report a bug, you should keep in mind that the process is very 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:136
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:141
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:146
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:150
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:156
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:167
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:172
msgid "Contributing to the documentation"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:174
msgid "There are two separate resources referred to as \"documentation\" in Godot:"
msgstr ""
#: ../../docs/community/contributing/ways_to_contribute.rst:176
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:184
msgid "**The tutorials and engine documentation.** 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 ""

22
sphinx/templates/community/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/community/index.rst:2
msgid "Community"
msgstr ""

38
sphinx/templates/community/resources.pot Normal file
View File

@@ -0,0 +1,38 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/community/resources.rst:4
msgid "Resources"
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:9
msgid "General"
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 ""

38
sphinx/templates/community/tutorials.pot Normal file
View File

@@ -0,0 +1,38 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/community/tutorials.rst:4
msgid "Tutorials"
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 ""

288
sphinx/templates/development/compiling/compiling_for_android.pot Normal file
View File

@@ -0,0 +1,288 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:20
msgid "Requirements"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:22
msgid "For compiling under Windows, Linux or macOS, the following is required:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:24
msgid "Python 2.7+ or Python 3.5+"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:25
msgid "SCons build system"
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
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 very 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:131
#: ../../docs/development/compiling/compiling_for_android.rst:174
msgid "Troubleshooting"
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, adds your file and spits it back. It's really handy! (and required some reverse engineering of the format)."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:150
msgid "Installing the templates"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:152
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:156
msgid "Windows: ``C:\\Users\\[username]\\AppData\\Roaming\\Godot\\templates``"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:157
msgid "Linux: ``/home/[username]/.local/share/godot/templates/[gd-version]/``"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:158
msgid "macOS: ``/users/[username]/.godot/templates``"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:162
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:168
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:177
msgid "Application not installed"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:179
msgid "Android might complain the application is not correctly installed. If so, check the following:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:182
msgid "Check that the debug keystore is properly generated."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:183
msgid "Check that jarsigner is from JDK 6, 7 or 8."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:185
msgid "If it still fails, open a command line and run logcat:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:191
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:194
msgid "Seek assistance if you can't figure it out."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:197
msgid "Application exits immediately"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:199
msgid "If the application runs but exits immediately, there might be one of the following reasons:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:202
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:204
msgid "libgodot_android.so is not in ``lib/armeabi-v7a`` or ``lib/armeabi``"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:205
msgid "Device does not support armv7 (try compiling yourself for armv6)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:206
msgid "Device is Intel, and apk is compiled for ARM."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:208
msgid "In any case, ``adb logcat`` should also show the cause of the error."
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:211
msgid "Compilation fails"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:213
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:216
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:220
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:228
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:236
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:243
msgid "You can increase those limits with the command:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_android.rst:249
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:254
msgid "If all went well, and you entered the prlimit command while scons was running, then your compilation should continue without the error."
msgstr ""

74
sphinx/templates/development/compiling/compiling_for_ios.pot Normal file
View File

@@ -0,0 +1,74 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_ios.rst:4
msgid "Compiling for iOS"
msgstr ""
#: ../../docs/development/compiling/compiling_for_ios.rst:9
msgid "Requirements"
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:16
msgid "Compiling"
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 ""

98
sphinx/templates/development/compiling/compiling_for_osx.pot Normal file
View File

@@ -0,0 +1,98 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_osx.rst:4
msgid "Compiling for OSX"
msgstr ""
#: ../../docs/development/compiling/compiling_for_osx.rst:9
msgid "Requirements"
msgstr ""
#: ../../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_osx.rst:14
msgid "Python 2.7+ or Python 3.5+"
msgstr ""
#: ../../docs/development/compiling/compiling_for_osx.rst:15
msgid "SCons build system"
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:19
msgid "Compiling"
msgstr ""
#: ../../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_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_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 ""

138
sphinx/templates/development/compiling/compiling_for_uwp.pot Normal file
View File

@@ -0,0 +1,138 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_uwp.rst:4
msgid "Compiling for Universal Windows Platform"
msgstr ""
#: ../../docs/development/compiling/compiling_for_uwp.rst:9
msgid "Requirements"
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:21
msgid "Compiling"
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 a very 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 ""

94
sphinx/templates/development/compiling/compiling_for_web.pot Normal file
View File

@@ -0,0 +1,94 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_web.rst:4
msgid "Compiling for the Web"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:9
msgid "Requirements"
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://emscripten.org/>`__: 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/gettng_started/downloads.html>`__ (Install in a path without spaces, i.e. not in ``Program Files``)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:17
msgid "`Python 2.7+ or Python 3.5+ <https://www.python.org/>`__"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:18
msgid "`SCons <http://www.scons.org>`__ build system"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:21
msgid "Building export templates"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:23
msgid "Start a terminal and set the environment variable ``EMSCRIPTEN_ROOT`` to the installation directory of Emscripten:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:26
msgid "If you installed Emscripten via the Emscripten SDK, declare the variable with a path to the downloaded folder::"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:31
msgid "If you installed Emscripten via package manager, the path can be retrieved with the ``em-config`` command::"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:36
msgid "On Windows you can set the environment variable in the system settings or in the command prompt::"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:41
msgid "Now go to the root directory of the engine source code and 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:48
msgid "The engine will now be compiled to WebAssembly by Emscripten. If all goes well, the resulting file will be placed in the ``bin`` subdirectory. Its name is ``godot.javascript.opt.zip`` for release or ``godot.javascript.opt.debug.zip`` for debug."
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:53
msgid "Finally, rename the zip archive to ``webassembly_release.zip`` for the release template::"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:58
msgid "And ``webassembly_debug.zip`` for the debug template::"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:63
msgid "Building per asm.js translation or LLVM backend"
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:65
msgid "WebAssembly can be compiled in two ways: The default is to first compile to asm.js, a highly optimizable subset of JavaScript, using Emscripten's *fastcomp* fork of LLVM. This code is then translated to WebAssembly using a tool called ``asm2wasm``. Emscripten automatically takes care of both processes, we simply run SCons."
msgstr ""
#: ../../docs/development/compiling/compiling_for_web.rst:71
msgid "The other method uses LLVM's WebAssembly backend. This backend is 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:78
msgid "In order to choose one of the two methods, the ``LLVM_ROOT`` variable in the Emscripten configuration file ``~/.emscripten`` is set. 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 ""

414
sphinx/templates/development/compiling/compiling_for_windows.pot Normal file
View File

@@ -0,0 +1,414 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_windows.rst:4
msgid "Compiling for Windows"
msgstr ""
#: ../../docs/development/compiling/compiling_for_windows.rst:9
msgid "Requirements"
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/en-us/products/visual-studio-community-vs.aspx>`__ (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 <http://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:85
msgid "Compiling"
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
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
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 arhitecture 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 very 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>`_, 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
msgid "**Arch**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_windows.rst:354
msgid "**Debian** / **Ubuntu**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_windows.rst:358
msgid "**Fedora**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_windows.rst:362
msgid "**macOS**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_windows.rst:366
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
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
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 ""

170
sphinx/templates/development/compiling/compiling_for_x11.pot Normal file
View File

@@ -0,0 +1,170 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_for_x11.rst:4
msgid "Compiling for X11 (Linux, \\*BSD)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:9
msgid "Requirements"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:11
msgid "For compiling under Linux or other Unix variants, the following is required:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:14
msgid "GCC 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
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 "libudev (optional, build with `udev=yes`)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:27
msgid "Distro-specific oneliners"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:29
msgid "**Arch**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:33
msgid "**Debian** / **Ubuntu**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:39
msgid "**Fedora**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:45
msgid "**FreeBSD**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:50
msgid "**Gentoo**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:55
msgid "**Mageia**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:61
msgid "**OpenBSD**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:65
msgid "**openSUSE**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:71
msgid "**Solus**"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:78
msgid "Compiling"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:80
msgid "Start a terminal, go to the root dir of the engine source code and type:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:86
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:93
msgid "If you wish to compile using Clang rather than GCC, use this command:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:99
msgid "Using Clang appears to be a requirement for OpenBSD, otherwise fonts would not build."
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:103
msgid "Building export templates"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:105
msgid "To build X11 (Linux, \\*BSD) export templates, run the build system with the following parameters:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:108
msgid "(32 bits)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:115
msgid "(64 bits)"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:122
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:125
msgid "To create standard export templates, the resulting files must be copied to:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:131
msgid "and named like this (even for \\*BSD which is seen as \"Linux X11\" by Godot):"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:140
msgid "However, if you are writing your custom modules or custom C++ code, you might instead want to configure your binaries as custom export templates here:"
msgstr ""
#: ../../docs/development/compiling/compiling_for_x11.rst:146
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 ""

98
sphinx/templates/development/compiling/compiling_with_mono.pot Normal file
View File

@@ -0,0 +1,98 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/compiling_with_mono.rst:4
msgid "Compiling with Mono"
msgstr ""
#: ../../docs/development/compiling/compiling_with_mono.rst:9
msgid "Requirements"
msgstr ""
#: ../../docs/development/compiling/compiling_with_mono.rst:11
msgid "Mono 5.2.0+ (mono-complete)"
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
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:52
msgid "Example (x11)"
msgstr ""
#: ../../docs/development/compiling/compiling_with_mono.rst:68
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 ""

142
sphinx/templates/development/compiling/cross-compiling_for_ios_on_linux.pot Normal file
View File

@@ -0,0 +1,142 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:27
msgid "Requirements"
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 <http://fuse.sourceforge.net>`__ for mounting and umounting the dmg image."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:36
msgid "`darling-dmg <https://github.com/darlinghq/darling-dmg>`__, which needs to be built from source. The procedure for that is explained below."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:40
msgid "For building darling-dmg, you'll need the development packages of the following libraries: fuse, icu, openssl, zlib, bzip2."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:43
msgid "`cctools-port <https://github.com/tpoechtrager/cctools-port>`__ for the needed build tools. The procedure for building is quite peculiar and is described below."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:47
msgid "This also has some extra dependencies: automake, autogen, libtool."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:50
msgid "Configuring the environment"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:53
msgid "darling-dmg"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:55
msgid "Clone the repository on your machine:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:61
msgid "Build it:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:73
msgid "Preparing the SDK"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:75
msgid "Mount the XCode image:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:84
msgid "Extract the iOS SDK:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:93
msgid "Pack the SDK:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:101
msgid "Toolchain"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:103
msgid "Build cctools:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:111
msgid "Copy the tools to a nicer place. Note that the SCons scripts for building will look under ``usr/bin`` inside the directory you provide for the toolchain binaries, so you must copy to such subdirectory, akin to the following commands:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:121
msgid "Now you should have the iOS toolchain binaries in ``/home/user/iostoolchain/usr/bin``."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:125
msgid "Compiling Godot for iPhone"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:127
msgid "Once you've done the above steps, you should keep two things in your environment: the built toolchain and the iPhoneOS SDK directory. Those can stay anywhere you want since you have to provide their paths to the SCons build command."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:132
msgid "For the iPhone platform to be detected, you need the ``OSXCROSS_IOS`` environment variable defined to anything."
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:139
msgid "Now you can compile for iPhone using SCons like the standard Godot way, with some additional arguments to provide the correct paths:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:148
msgid "Producing fat binaries"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:150
msgid "Apple requires a fat binary with both architectures (``armv7`` and ``arm64``) in a single file. To do this, use the ``arm-apple-darwin11-lipo`` executable. The following example assumes you are in the root Godot source directory:"
msgstr ""
#: ../../docs/development/compiling/cross-compiling_for_ios_on_linux.rst:159
msgid "Then you will have an iOS fat binary in ``bin/godot.iphone.opt.debug.fat``."
msgstr ""

62
sphinx/templates/development/compiling/getting_source.pot Normal file
View File

@@ -0,0 +1,62 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

22
sphinx/templates/development/compiling/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/compiling/index.rst:2
msgid "Compiling"
msgstr ""

202
sphinx/templates/development/compiling/introduction_to_the_buildsystem.pot Normal file
View File

@@ -0,0 +1,202 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 <http://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:41
msgid "Setup"
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:134
msgid "Tools"
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 "Export templates"
msgstr ""
#: ../../docs/development/compiling/introduction_to_the_buildsystem.rst:191
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:196
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:219
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:223
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 ""

78
sphinx/templates/development/compiling/packaging_godot.pot Normal file
View File

@@ -0,0 +1,78 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

322
sphinx/templates/development/cpp/configuring_an_ide.pot Normal file
View File

@@ -0,0 +1,322 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
msgid "QtCreator"
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:77
msgid "Set the path to your Godot root directory and enter the project name."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:78
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:81
msgid "Click *Finish*."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:82
msgid "Add a line containing ``.`` to *project_name.includes* to get working code completion."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:85
msgid "Build and run"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:87
msgid "Build configuration:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:89
msgid "Click on *Projects* and open the *Build* tab."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:90
msgid "Delete the pre-defined ``make`` build step."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:91
msgid "Click *Add Build Step* -> *Custom Process Step*."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:92
msgid "Type ``scons`` in the *Command* field."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:93
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:95
msgid "Run configuration:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:97
msgid "Open the *Run* tab."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:98
msgid "Point the *Executable* to your compiled Godot binary (e.g: ``%{buildDir}\\bin\\godot.windows.tools.64.exe``)"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:99
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:100
msgid "If you want to run the editor, add ``-e`` to the *Command line arguments* field."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:103
msgid "Xcode"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:106
msgid "Project Setup"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:108
msgid "Create an Xcode external build project anywhere"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:112
msgid "Set the *Build tool* to the path to scons"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:114
msgid "Modify Build Target's Xcode Info Tab:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:116
msgid "Set *Arguments* to something like: platform=osx tools=yes bits=64 target=debug"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:117
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:118
msgid "You may uncheck *Pass build settings in environment*"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:122
msgid "Add a Command Line Target:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:124
msgid "Go to Xcode File > New > Target... and add a new Xcode command line target"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:130
msgid "Name it something so you know not to compile with this target"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:131
msgid "e.g. ``GodotXcodeIndex``"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:132
msgid "Goto the newly created target's *Build Settings* tab and search for *Header Search Paths*"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:133
msgid "Set *Header Search Paths* to an absolute path to Godot's source folder"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:134
msgid "Make it recursive by adding two \\*'s to the end of the path"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:135
msgid "e.g. ``/Users/me/repos/godot-source/\\**``"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:137
msgid "Add Godot Source to the Project:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:139
msgid "Drag and drop godot source into project file browser."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:140
msgid "Uncheck *Create External Build System*"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:144
msgid "Click Next"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:145
msgid "Select *create groups*"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:149
msgid "Check off only your command line target in the *Add to targets* section"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:150
msgid "Click finish. Xcode will now index the files."
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:151
msgid "Grab a cup of coffee... Maybe make something to eat, too"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:152
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:155
msgid "Scheme Setup"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:157
msgid "Edit Build Scheme of External Build Target:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:159
msgid "Open scheme editor of external build target"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:160
msgid "Expand the *Build* menu"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:161
msgid "Goto *Post Actions*"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:162
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:166
msgid "Write a script that gives the binary a name that Xcode will recognize"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:167
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:168
msgid "Build the external build target"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:170
msgid "Edit Run Scheme of External Build Target:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:172
msgid "Open the scheme editor again"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:173
msgid "Click Run"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:177
msgid "Set the *Executable* to the file you linked in your post build action script"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:178
msgid "Check *Debug executable* if it isn't already"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:179
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:182
msgid "Test it:"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:184
msgid "Set a breakpoint in platform/osx/godot_main_osx.mm"
msgstr ""
#: ../../docs/development/cpp/configuring_an_ide.rst:185
msgid "It should break at the point!"
msgstr ""

261
sphinx/templates/development/cpp/core_types.pot Normal file
View File

@@ -0,0 +1,261 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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 just 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 very 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, just 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. Just use it like:"
msgstr ""
#: ../../docs/development/cpp/core_types.rst:113
msgid "DVector is just 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:122
msgid "and"
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 very 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:175
msgid "String"
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 really 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, they are basically just that."
msgstr ""
#: ../../docs/development/cpp/core_types.rst:212
msgid "`core/math <https://github.com/godotengine/godot/blob/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/path_db.h <https://github.com/godotengine/godot/blob/master/core/path_db.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
msgid "`core/rid.h <https://github.com/godotengine/godot/blob/master/core/rid.h>`__"
msgstr ""

278
sphinx/templates/development/cpp/creating_android_modules.pot Normal file
View File

@@ -0,0 +1,278 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/cpp/creating_android_modules.rst:4
msgid "Creating Android modules"
msgstr ""
#: ../../docs/development/cpp/creating_android_modules.rst:7
msgid "Introduction"
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:185
msgid "Resources"
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, just 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, just continue the steps for compiling android :ref:`doc_compiling_for_android`."
msgstr ""
#: ../../docs/development/cpp/creating_android_modules.rst:269
msgid "Using the module"
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 just request the singleton Java object from Globals like this:"
msgstr ""
#: ../../docs/development/cpp/creating_android_modules.rst:301
msgid "Troubleshooting"
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 ""

111
sphinx/templates/development/cpp/custom_audiostreams.pot Normal file
View File

@@ -0,0 +1,111 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/cpp/custom_audiostreams.rst:4
msgid "Custom AudioStreams"
msgstr ""
#: ../../docs/development/cpp/custom_audiostreams.rst:7
msgid "Introduction"
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:23
#: ../../docs/development/cpp/custom_audiostreams.rst:119
#: ../../docs/development/cpp/custom_audiostreams.rst:342
msgid "References:"
msgstr ""
#: ../../docs/development/cpp/custom_audiostreams.rst:25
#: ../../docs/development/cpp/custom_audiostreams.rst:121
#: ../../docs/development/cpp/custom_audiostreams.rst:344
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:345
msgid "`scene/audio/audioplayer.cpp <https://github.com/godotengine/godot/blob/master/scene/audio/audio_player.cpp>`__"
msgstr ""
#: ../../docs/development/cpp/custom_audiostreams.rst:31
msgid "What for?"
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:228
msgid "Resampling"
msgstr ""
#: ../../docs/development/cpp/custom_audiostreams.rst:231
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:235
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:343
msgid "`core/math/audio_frame.h <https://github.com/godotengine/godot/blob/master/core/math/audio_frame.h>`__"
msgstr ""

266
sphinx/templates/development/cpp/custom_modules_in_cpp.pot Normal file
View File

@@ -0,0 +1,266 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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
msgid "Using the module"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:230
msgid "Using your newly created module is very easy, from any script you can now do:"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:242
msgid "And the output will be ``60``."
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:245
msgid "Improving the build system for development"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:247
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:250
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:253
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:258
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:290
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:300
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:303
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:333
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:336
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:344
msgid "Writing custom documentation"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:346
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:352
msgid "There are several steps in order to setup custom docs for the module:"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:354
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:357
msgid "Append the following code snippet to ``config.py``:"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:369
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:375
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:379
msgid "Run command:"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:385
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:395
msgid "Get generated doc file from ``godot/doc/classes/ClassName.xml``"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:397
msgid "Copy this file to ``doc_classes``, optionally edit it, then compile the engine."
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:399
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:403
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:407
msgid "Summing up"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:409
msgid "As you see, it's really easy to develop Godot in C++. Just write your stuff normally and remember to:"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:412
msgid "use ``GDCLASS`` macro for inheritance, so Godot can wrap it"
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:413
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:416
msgid "But this is not all, depending what you do, you will be greeted with some surprises."
msgstr ""
#: ../../docs/development/cpp/custom_modules_in_cpp.rst:419
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:422
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:425
msgid "By this same logic, you can extend the Editor and almost any area of the engine."
msgstr ""

153
sphinx/templates/development/cpp/custom_resource_format_loaders.pot Normal file
View File

@@ -0,0 +1,153 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:4
msgid "Custom Resource Format Loaders"
msgstr ""
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:7
msgid "Introduction"
msgstr ""
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:9
msgid "ResourceFormatLoader is a factory interface for loading file assets. Resources are primary containers. When load is called on the same file path again, the previous loaded Resource will be referenced. Naturally, loaded resources must be stateless."
msgstr ""
#: ../../docs/development/cpp/custom_resource_format_loaders.rst:14
msgid "This guide assumes the reader knows how to create C++ modules and godot data types. If not, refer to this guide :ref:`doc_custom_modules_in_c++`."
msgstr ""
#: ../../docs/development/cpp/custom_resource_format_loaders.rst: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
msgid "References:"
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:25
msgid "What for?"
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 ""

22
sphinx/templates/development/cpp/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/cpp/index.rst:2
msgid "Engine development"
msgstr ""

46
sphinx/templates/development/cpp/inheritance_class_tree.pot Normal file
View File

@@ -0,0 +1,46 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:10
msgid "Reference"
msgstr ""
#: ../../docs/development/cpp/inheritance_class_tree.rst:15
msgid "Control"
msgstr ""
#: ../../docs/development/cpp/inheritance_class_tree.rst:20
msgid "Node2D"
msgstr ""
#: ../../docs/development/cpp/inheritance_class_tree.rst:25
msgid "Spatial"
msgstr ""
#: ../../docs/development/cpp/inheritance_class_tree.rst:29
msgid "Source files: :download:`class_tree.zip <files/class_tree.zip>`."
msgstr ""

46
sphinx/templates/development/cpp/introduction_to_godot_development.pot Normal file
View File

@@ -0,0 +1,46 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

275
sphinx/templates/development/cpp/object_class.pot Normal file
View File

@@ -0,0 +1,275 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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: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
msgid "References:"
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:94
msgid "Constants"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:96
msgid "Classes often have enums such as:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:105
msgid "For these to work when binding to methods, the enum must be declared convertible to int, for this a macro is provided:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:112
msgid "The constants can also be bound inside ``_bind_methods``, by using:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:120
msgid "Properties (set/get)"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:122
msgid "Objects export properties, properties are useful for the following:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:124
msgid "Serializing and deserializing the object."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:125
msgid "Creating a list of editable values for the Object derived class."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:127
msgid "Properties are usually defined by the PropertyInfo() class. Usually constructed as:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:134
msgid "For example:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:140
msgid "This is an integer property, named \"amount\", hint is a range, range goes from 0 to 49 in steps of 1 (integers). It is only usable for the editor (edit value visually) but won't be serialized."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:144
msgid "Another example:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:150
msgid "This is a string property, can take any string but the editor will only allow the defined hint ones. Since no usage flags were specified, the default ones are PROPERTY_USAGE_STORAGE and PROPERTY_USAGE_EDITOR."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:154
msgid "There are plenty of hints and usage flags available in object.h, give them a check."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:157
msgid "Properties can also work like C# properties and be accessed from script using indexing, but this usage is generally discouraged, as using functions is preferred for legibility. Many properties are also bound with categories, such as \"animation/frame\" which also make indexing impossible unless using operator []."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:163
msgid "From ``_bind_methods()``, properties can be created and bound as long as set/get functions exist. Example:"
msgstr ""
#: ../../docs/development/cpp/object_class.rst:170
msgid "This creates the property using the setter and the getter."
msgstr ""
#: ../../docs/development/cpp/object_class.rst: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 very small binary size is ideal, such as HTML5 or consoles (with low memory footprint)."
msgstr ""
#: ../../docs/development/cpp/object_class.rst:211
msgid "Signals"
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:233
msgid "References"
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 ""

111
sphinx/templates/development/cpp/variant_class.pot Normal file
View File

@@ -0,0 +1,111 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/cpp/variant_class.rst:4
msgid "Variant class"
msgstr ""
#: ../../docs/development/cpp/variant_class.rst:7
msgid "About"
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:38
#: ../../docs/development/cpp/variant_class.rst:57
msgid "References:"
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 ""

22
sphinx/templates/development/file_formats/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/development/file_formats/index.rst:2
msgid "Godot file formats"
msgstr ""

198
sphinx/templates/development/file_formats/tscn.pot Normal file
View File

@@ -0,0 +1,198 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:27
msgid "Nodes"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:28
msgid "Connections"
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 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:65
msgid "Resources"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:66
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:70
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:76
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:82
msgid "External Resources"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:84
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:87
msgid "A path"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:88
msgid "A type"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:89
msgid "An ID"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:91
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:95
msgid "Some example external resources are:"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:104
msgid "Internal Resources"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:106
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 very 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:119
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:124
msgid "Unfortunately, documentation on the formats for these subresources is completely absent, and while some can be found through inspecting resources of saved files, but others can only be found by looking through Godot's source."
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:130
msgid "The Scene Tree"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:132
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:136
msgid "Other valid keywords include:"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:138
msgid "instance"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:139
msgid "instance_placeholder"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:140
msgid "owner"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:141
msgid "index (if two nodes have the same name)"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:142
msgid "groups"
msgstr ""
#: ../../docs/development/file_formats/tscn.rst:144
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:157
msgid "Similar to the internal resource, the content for each node is currently undocumented. Fortunately it is very easy to find out because you can simply save a file with that node in it. Some example nodes are:"
msgstr ""

146
sphinx/templates/getting_started/editor/command_line_tutorial.pot Normal file
View File

@@ -0,0 +1,146 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:51
msgid "Creating a project from the command line is simple, just navigate the shell to the desired place and just make project.godot file exist, even if empty."
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:61
msgid "That alone makes for an empty Godot project."
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:64
msgid "Running the editor"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:66
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:74
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:82
msgid "Erasing a scene"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:84
msgid "Godot is friends with your filesystem, and will not create extra metadata files, simply use ``rm`` to erase a 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:93
msgid "Running the game"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:95
msgid "To run the game, simply execute Godot within the project directory or subdirectory."
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:102
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:110
msgid "Debugging"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:112
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:125
msgid "Exporting"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:127
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:136
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, just 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:142
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:146
msgid "Running a script"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:148
msgid "It is possible to run a simple .gd script from the command line. This feature is especially useful in very large projects, for batch conversion of assets or custom import/export."
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:152
msgid "The script must inherit from SceneTree or MainLoop."
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:154
msgid "Here is a simple example of how it works:"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:165
msgid "And how to run it:"
msgstr ""
#: ../../docs/getting_started/editor/command_line_tutorial.rst:172
msgid "If no project.godot exists at the path, current path is assumed to be the current working directory (unless ``-path`` is specified)."
msgstr ""

98
sphinx/templates/getting_started/editor/external_editor.pot Normal file
View File

@@ -0,0 +1,98 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 "Editor"
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 ""

22
sphinx/templates/getting_started/editor/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/editor/index.rst:2
msgid "Editor manual"
msgstr ""

402
sphinx/templates/getting_started/editor/unity_to_godot.pot Normal file
View File

@@ -0,0 +1,402 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:13
msgid "Differences"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:16
msgid "Unity"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:16
msgid "Godot"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:18
msgid "License"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:18
msgid "Proprietary, closed, free license with revenue caps and usage restrictions"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:18
msgid "MIT license, free and fully open source without any restriction"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:20
msgid "OS (editor)"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:20
msgid "Windows, macOS, Linux (unofficial and unsupported)"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:20
msgid "Windows, X11 (Linux, \\*BSD), Haiku, macOS"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:22
msgid "OS (export)"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Desktop: Windows, Linux/SteamOS, macOS"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Mobile: Android, iOS, Windows Phone, Tizen,"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Web: WebAssembly or asm.js"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Consoles: PS4, PS Vita, Xbox One, Xbox 360, Wii U, Nintendo 3DS"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "VR: Oculus Rift, SteamVR, Google Cardboard, Playstation VR, Gear VR, HoloLens"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "TV: Android TV, Samsung SMART TV, tvOS"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Desktop: Windows, X11, macOS"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Mobile: Android, iOS,"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Web: WebAssembly"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:29
msgid "Scene system"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Component/Scene (GameObject > Component)"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Prefabs"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:29
msgid "Scene tree and nodes, allowing scenes to be nested and/or inherit other scenes"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:32
msgid "Third-party tools"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:32
msgid "Visual Studio or SharpEditor"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Android SDK for Android export"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "External editors are possible"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:35
msgid "Killer features"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Huge community"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Large assets store"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Scene System"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Animation Pipeline"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Easy to write Shaders"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:0
msgid "Debug on Device"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:45
msgid "The editor"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:47
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:53
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:55
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 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:57
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:59
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:61
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:63
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:65
msgid "Running the project and closing it is very 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:66
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:67
msgid "The editor is more stable, because the game runs in a separate process."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:69
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:72
msgid "The scene system"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:74
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:76
msgid "Unity's scene system consist in embedding all the required assets in a scene, and link them together by setting components and scripts to them."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:78
msgid "Godot's scene system is different: it actually consists in a tree made of nodes. Each node serves a purpose: Sprite, Mesh, Light... Basically, this is similar to Unity scene system. However, each node can have multiple children, which make 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:80
msgid "For example, think of a platformer level. You would compose it with multiple elements:"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:82
msgid "Bricks"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:83
msgid "Coins"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:84
msgid "The player"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:85
msgid "The enemies"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:88
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 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:90
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:92
msgid "First, a scene for the Player alone."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:94
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:96
msgid "Second, a scene for the Enemy."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:98
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:100
msgid "Lastly, the Level scene."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:102
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:104
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:108
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:110
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:112
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:113
msgid "Second, it allows the extraction a subtree of scene to make it a scene of its own, which answers to 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:116
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:120
msgid "Project organization"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:124
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:126
msgid "However, we often observe a common architecture for Unity projects, which consists in 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:128
msgid "As described before, Godot scene system allows splitting scenes in 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:132
msgid "Where are my prefabs?"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:134
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:136
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 in 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:140
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 and 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 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 it once in the 'template' scene."
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:145
msgid "Glossary correspondence"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:147
msgid "GameObject -> Node Add a component -> Inheriting Prefab -> Externalized branch"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:153
msgid "Scripting: GDScript, C# and Visual Script"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:156
msgid "Design"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:158
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:160
msgid "Godot provides its own scripting language, :ref:`GDScript <doc_scripting>` as well as support for :ref:`Visual Script <toc-learn-scripting-visual_script>` and :ref:`C# <doc_c_sharp>`. GDScript borrows its syntax from Python, but is not related to it. If you wonder about the reasoning for a custom scripting language, please read :ref:`GDScript <doc_gdscript>` and `FAQ <faq>`_ pages. GDScript is strongly attached to the Godot API, but it 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:162
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:164
msgid "In Godot, you can only attach one script per node. You can use either an external GDScript file, or include it 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:166
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:167
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:169
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:172
msgid "Connections : groups and signals"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:174
msgid "You can control nodes by accessing them using a script, and call 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:176
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:180
msgid "Using Godot in C++"
msgstr ""
#: ../../docs/getting_started/editor/unity_to_godot.rst:182
msgid "Just 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:184
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 ""

146
sphinx/templates/getting_started/scripting/c_sharp/c_sharp_basics.pot Normal file
View File

@@ -0,0 +1,146 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:4
msgid "Introduction"
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.2 .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 (at least version 5.2), as well as 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 "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:34
msgid "Configuring an external editor"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:36
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:45
msgid "Creating a C# script"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:47
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:51
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:56
msgid "Project setup and workflow"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:58
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:63
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:66
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:77
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:80
msgid "Example"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:82
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:109
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:113
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:117
msgid "General differences between C# and GDScript"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:119
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:123
msgid "For more, see the :ref:`doc_c_sharp_differences` page."
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:126
msgid "Current gotchas and known issues"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:128
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:131
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:132
msgid "Writing editor plugins and tool scripts in C# is not yet supported"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:133
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:136
msgid "Performance of C# in Godot"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_basics.rst:138
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 ""

385
sphinx/templates/getting_started/scripting/c_sharp/c_sharp_differences.pot Normal file
View File

@@ -0,0 +1,385 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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:55
msgid "Singletons"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:57
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:65
msgid "String"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:67
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:75
msgid "There are a few differences though:"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:77
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:81
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:92
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:103
msgid "Basis"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:105
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:109
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:124
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:137
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:156
msgid "The following methods were converted to properties with their respective names changed:"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:112
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:127
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:140
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:151
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:159
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:178
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:221
msgid "GDScript"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:112
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:127
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:140
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:151
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:159
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:178
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:221
msgid "C#"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:114
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:131
msgid "get_scale()"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:114
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:131
msgid "Scale"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:118
msgid "Transform2D"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:120
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:129
msgid "get_origin()"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:129
msgid "Origin"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:130
msgid "get_rotation()"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:130
msgid "Rotation"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:135
msgid "Plane"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:142
msgid "center()"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:142
msgid "Center"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:146
msgid "Rect2"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:148
msgid "The following fields were converted to properties with their respective names changed:"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:153
msgid "end"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:153
msgid "End"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:161
msgid "get_area()"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:161
msgid "Area"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:165
msgid "Quat"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:167
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:172
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:180
msgid "Array"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:174
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:180
msgid "object[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:181
msgid "PoolIntArray"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:181
msgid "int[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:182
msgid "PoolByteArray"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:182
msgid "byte[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:183
msgid "PoolFloatArray"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:183
msgid "float[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:184
msgid "PoolStringArray"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:184
msgid "String[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:185
msgid "PoolColorArray"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:185
msgid "Color[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:186
msgid "PoolVector2Array"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:186
msgid "Vector2[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:187
msgid "PoolVector3Array"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:187
msgid "Vector3[]"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:190
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:193
msgid "Dictionary"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:195
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:197
msgid "Use ``Dictionary<object, object>``."
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:200
msgid "Variant"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:202
msgid "``System.Object`` (``object``) is used in place of ``Variant``."
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:205
msgid "Communicating with other scripting languages"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:207
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:213
msgid "Other differences"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:215
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:218
msgid "Other differences:"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:223
msgid "Color8"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:223
msgid "Color.Color8"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:224
msgid "is_inf"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:224
msgid "float.IsInfinity"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:225
msgid "is_nan"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:225
msgid "float.IsNaN"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
msgid "dict2inst"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:226
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:227
msgid "? TODO"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:227
msgid "inst2dict"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
msgid "load"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_differences.rst:228
msgid "GD.load which is the same as ResourceLoader.load"
msgstr ""

98
sphinx/templates/getting_started/scripting/c_sharp/c_sharp_features.pot Normal file
View File

@@ -0,0 +1,98 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 provied 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:61
msgid "Signals"
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:63
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:65
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:75
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:95
msgid "Emitting signals is done with the ``EmitSignal`` method."
msgstr ""
#: ../../docs/getting_started/scripting/c_sharp/c_sharp_features.rst:105
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:107
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 ""

22
sphinx/templates/getting_started/scripting/c_sharp/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/c_sharp/index.rst:2
msgid "C#"
msgstr ""

312
sphinx/templates/getting_started/scripting/gdscript/gdscript_advanced.pot Normal file
View File

@@ -0,0 +1,312 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:7
msgid "About"
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 very simple 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 very 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:106
msgid "Pointers & referencing:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:108
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:113
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:119
msgid "C++:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:135
msgid "Java:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:153
msgid "GDScript:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:165
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:173
msgid "Arrays"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:175
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:202
msgid "And in GDScript:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:211
msgid "In dynamically typed languages, arrays can also double as other datatypes, such as lists:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:221
msgid "Or unordered sets:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:230
msgid "Dictionaries"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:232
msgid "Dictionaries are a very 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:238
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 very 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:244
msgid "Example of Dictionary:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:251
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:260
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 very 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:390
msgid "And backwards looping is done through a negative counter:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:396
msgid "becomes"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:403
msgid "While"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:405
msgid "while() loops are the same everywhere:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:416
msgid "Custom iterators"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:417
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:449
msgid "And it can be used like any other iterator:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:457
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:461
msgid "Duck typing"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:463
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:468
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:479
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:487
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:496
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:502
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:505
msgid "In this case, it translates to:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:507
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:509
msgid "Yes, we should call it Hulk typing instead."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_advanced.rst:511
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:522
msgid "Then, simply define that method and anything the rock touches can be smashed."
msgstr ""

1237
sphinx/templates/getting_started/scripting/gdscript/gdscript_basics.pot Normal file
View File

File diff suppressed because it is too large Load Diff

377
sphinx/templates/getting_started/scripting/gdscript/gdscript_format_string.pot Normal file
View File

@@ -0,0 +1,377 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:33
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:37
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:44
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:48
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:51
msgid "A quick example in GDScript::"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:62
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:67
msgid "Multiple placeholders"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:69
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:79
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:84
msgid "Format specifiers"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:86
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:93
msgid "Placeholder types"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:95
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:99
msgid "``s``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:99
msgid "**Simple** conversion to String by the same method as implicit String conversion."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:102
msgid "``c``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:102
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:105
msgid "``d``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:105
msgid "A **decimal integral** number. Expects an integral or real number (will be floored)."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:108
msgid "``o``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:108
msgid "An **octal integral** number. Expects an integral or real number (will be floored)."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:111
msgid "``x``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:111
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:114
msgid "``X``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:114
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:117
msgid "``f``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:117
msgid "A **decimal real** number. Expects an integral or real number."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:122
msgid "Placeholder modifiers"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:124
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:128
msgid "``+``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:128
msgid "In number specifiers, **show + sign** if positive."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:130
msgid "Integer"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:130
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:134
msgid "``.``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:134
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:137
msgid "``-``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:137
msgid "**Pad to the right** rather than the left."
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:139
msgid "``*``"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:139
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:145
msgid "Padding"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:147
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:152
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:158
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:164
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:176
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:185
msgid "Dynamic padding"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:187
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:198
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:206
msgid "Escape sequence"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:208
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:217
msgid "Format method examples"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:219
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:224
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
msgid "**Type**"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:224
msgid "**Style**"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:224
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:257
msgid "**Example**"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:224
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:244
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:257
msgid "**Result**"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:226
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:228
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:230
msgid "Dictionary"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:226
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:232
msgid "key"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:226
msgid "\"Hi, {name} v{version}!\".format({\"name\":\"Godette\", \"version\":\"3.0\"})"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:226
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:228
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:230
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:232
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:234
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:236
msgid "Hi, Godette v3.0!"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:228
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:234
msgid "index"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:228
msgid "\"Hi, {0} v{1}!\".format({\"0\":\"Godette\", \"1\":\"3.0\"})"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:230
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:236
msgid "mix"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:230
msgid "\"Hi, {0} v{version}!\".format({\"0\":\"Godette\", \"version\":\"3.0\"})"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:232
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:234
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:236
msgid "Array"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:232
msgid "\"Hi, {name} v{version}!\".format([[\"version\":\"3.0\"], [\"name\":\"Godette\"])"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:234
msgid "\"Hi, {0} v{1}!\".format([\"Godette\",\"3.0\"])"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:236
msgid "\"Hi, {name} v{0}!\".format([3.0, [\"name\":\"Godette\"]])"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:239
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:246
msgid "Infix (default)"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:246
msgid "\"Hi, {0} v{1}\".format([\"Godette\", \"3.0\"], \"{_}\")"
msgstr ""
#: ../../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
msgid "Hi, Godette v3.0"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
msgid "Postfix"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:248
msgid "\"Hi, 0% v1%\".format([\"Godette\", \"3.0\"], \"_%\")"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
msgid "Prefix"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:250
msgid "\"Hi, %0 v%1\".format([\"Godette\", \"3.0\"], \"%_\")"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:253
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:259
msgid "\"Hi, {0} v{version}\".format({0:\"Godette\", \"version\":\"%0.2f\" % 3.114})"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_format_string.rst:259
msgid "Hi, Godette v3.11"
msgstr ""

166
sphinx/templates/getting_started/scripting/gdscript/gdscript_styleguide.pot Normal file
View File

@@ -0,0 +1,166 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:4
msgid "GDScript Style Guide"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:7
msgid "Description"
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
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:183
msgid "Signals"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:185
msgid "Use past tense:"
msgstr ""
#: ../../docs/getting_started/scripting/gdscript/gdscript_styleguide.rst:193
msgid "Constants"
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 ""

22
sphinx/templates/getting_started/scripting/gdscript/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/gdscript/index.rst:2
msgid "GDScript"
msgstr ""

22
sphinx/templates/getting_started/scripting/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/index.rst:2
msgid "Scripting"
msgstr ""

134
sphinx/templates/getting_started/scripting/visual_script/getting_started.pot Normal file
View File

@@ -0,0 +1,134 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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: Just 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 ""

22
sphinx/templates/getting_started/scripting/visual_script/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/scripting/visual_script/index.rst:2
msgid "VisualScript"
msgstr ""

534
sphinx/templates/getting_started/scripting/visual_script/nodes_purposes.pot Normal file
View File

@@ -0,0 +1,534 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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, just 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 *Connnections*: 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, it's easy to understand the logic within a function by just 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
msgid "Connections"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:60
msgid "Connecting is a relatively simple process. Just 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, just 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:131
msgid "Variables"
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 (@TODO, document this). 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:164
msgid "Signals"
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 just 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:211
msgid "Constants"
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:228
msgid "Data"
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. Just 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 just 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 just 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:288
msgid "SceneTree"
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 just drag the desired resource from the filesystem dock to the canvas."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:306
msgid "Resource Path"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:308
msgid "This node is a simple helper to get a string with a path to a resource you can pick. It's useful in functions that load things from disk."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:313
msgid "Comment"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:315
msgid "A Comment node works as a node you can resize to put around other nodes. It will not try to get focus or be brought to top when selecting it. It can also be used to write text on it."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:322
msgid "Flow Control"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:324
msgid "Flow control nodes allow the execution to take different branches, usually depending on a given condition."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:331
msgid "Condition"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:333
msgid "This is a simple node that checks a bool port. If true, it will go via the \"true\" sequence port. If false, the second. After going for either of them, it goes via the \"done\" port. Leaving sequence ports disconnected is fine if not all of them are used."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:339
msgid "Iterator"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:341
msgid "Some data types in Godot (ie, arrays, dictionaries) are iterable. This means that a bit of code can run for each element that it has."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:344
msgid "The Iterator node goes through all elements and, for each of them, it goes via the \"each\" sequence port, making the element available in the \"elem\" data port."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:347
msgid "When done, it goes via the \"exit\" sequence port."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:351
msgid "Return"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:353
msgid "Some functions can return values. In general for virtual ones, Godot will add the Return node for you. A return node forces the function to end."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:358
msgid "Sequence"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:360
msgid "This node is useful mostly for organizing your graph. It calls its sequence ports in order."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:364
msgid "TypeCast"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:366
msgid "This is a very useful and commonly used node. You can use it to cast arguments or other objects to the type you desire. Afterwards, you can even drag the object output to get full completion."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:372
msgid "It is also possible to cast to a script, which will allow complete script properties and functions:"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:378
msgid "Switch"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:380
msgid "The Switch node is similar to the Condition node, but it matches many values at the same time."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:384
msgid "While"
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:391
msgid "Functions"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:393
msgid "Functions are simple helpers, most of the time deterministic. They take some arguments as input and return an output. They are almost never sequenced."
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:398
msgid "Built-In"
msgstr ""
#: ../../docs/getting_started/scripting/visual_script/nodes_purposes.rst:400
msgid "There is a list of built in helpers. The list is almost identical to the one from GDScript (@TODO, link to gdscript methods?). Most of them are mathematical functions, but others can be very useful helpers. Just 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 very 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:472
msgid "Operators"
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. Just 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 ""

54
sphinx/templates/getting_started/scripting/visual_script/what_is_visual_scripting.pot Normal file
View File

@@ -0,0 +1,54 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 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 ""

102
sphinx/templates/getting_started/step_by_step/animations.pot Normal file
View File

@@ -0,0 +1,102 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/animations.rst:4
msgid "Animations"
msgstr ""
#: ../../docs/getting_started/step_by_step/animations.rst:7
msgid "Introduction"
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 ""

122
sphinx/templates/getting_started/step_by_step/filesystem.pot Normal file
View File

@@ -0,0 +1,122 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/filesystem.rst:4
msgid "File system"
msgstr ""
#: ../../docs/getting_started/step_by_step/filesystem.rst:7
msgid "Introduction"
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
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
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 very 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 going the hardest 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 just 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 ""

190
sphinx/templates/getting_started/step_by_step/godot_design_philosophy.pot Normal file
View File

@@ -0,0 +1,190 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:46
msgid "|image0|"
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:54
msgid "|image1|"
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:68
msgid "|image2|"
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:88
msgid "|image3|"
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:99
msgid "|image4|"
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:151
msgid "|image5|"
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 ""

22
sphinx/templates/getting_started/step_by_step/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/index.rst:2
msgid "Step by step"
msgstr ""

118
sphinx/templates/getting_started/step_by_step/instancing.pot Normal file
View File

@@ -0,0 +1,118 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/instancing.rst:4
msgid "Instancing"
msgstr ""
#: ../../docs/getting_started/step_by_step/instancing.rst:7
msgid "Introduction"
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 just 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 very useful when you want to create many copies of the same object."
msgstr ""

102
sphinx/templates/getting_started/step_by_step/instancing_continued.pot Normal file
View File

@@ -0,0 +1,102 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 "It's pretty easy to come up with a diagram like this for almost any kind of game. Just 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 just go on to the next tutorial!"
msgstr ""

230
sphinx/templates/getting_started/step_by_step/intro_to_the_editor_interface.pot Normal file
View File

@@ -0,0 +1,230 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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
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
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
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
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
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
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
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
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
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
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
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 ""

126
sphinx/templates/getting_started/step_by_step/resources.pot Normal file
View File

@@ -0,0 +1,126 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/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 just 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 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:91
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:101
msgid "Loading scenes"
msgstr ""
#: ../../docs/getting_started/step_by_step/resources.rst:102
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:106
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:116
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:120
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:129
msgid "Freeing resources"
msgstr ""
#: ../../docs/getting_started/step_by_step/resources.rst:131
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:138
msgid "Scripting"
msgstr ""
#: ../../docs/getting_started/step_by_step/resources.rst:140
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 ""

163
sphinx/templates/getting_started/step_by_step/scene_tree.pot Normal file
View File

@@ -0,0 +1,163 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/scene_tree.rst:4
#: ../../docs/getting_started/step_by_step/scene_tree.rst:42
msgid "SceneTree"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:7
msgid "Introduction"
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 really 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 really low level and when making games in Godot, writing your own MainLoop does not even make sense."
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:44
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:47
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:50
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:55
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:58
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:61
msgid "It contains information about the groups, and has means to call all nodes in a group, or get a list of them."
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:63
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:66
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:72
msgid "Root viewport"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:74
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:89
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:94
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:99
msgid "Scene tree"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:101
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:104
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:109
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:115
msgid "Tree order"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:117
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:125
msgid "\"Becoming active\" by entering the *Scene Tree*"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:127
msgid "A scene is loaded from disk or created by scripting."
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:128
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 grand-child of it."
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:131
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:134
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:137
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:142
msgid "Changing current scene"
msgstr ""
#: ../../docs/getting_started/step_by_step/scene_tree.rst:144
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:162
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 ""

234
sphinx/templates/getting_started/step_by_step/scenes_and_nodes.pot Normal file
View File

@@ -0,0 +1,234 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:7
msgid "Introduction"
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
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 very 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
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 ""

322
sphinx/templates/getting_started/step_by_step/scripting.pot Normal file
View File

@@ -0,0 +1,322 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/scripting.rst:4
msgid "Scripting"
msgstr ""
#: ../../docs/getting_started/step_by_step/scripting.rst:7
msgid "Introduction"
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 very 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
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
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
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
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 just 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:314
msgid "Run the scene and press the button. You should get the following result:"
msgstr ""
#: ../../docs/getting_started/step_by_step/scripting.rst:318
msgid "Why, hello there! Congratulations on scripting your first scene."
msgstr ""
#: ../../docs/getting_started/step_by_step/scripting.rst:322
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:340
msgid "Also, remember that nodes are referenced by name, not by type."
msgstr ""
#: ../../docs/getting_started/step_by_step/scripting.rst:344
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:348
msgid "The code approach also enables this with a 4th ``Array`` parameter that is empty be default. Feel free to read up on the ``Object.connect`` method for more information."
msgstr ""

166
sphinx/templates/getting_started/step_by_step/scripting_continued.pot Normal file
View File

@@ -0,0 +1,166 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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, just 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. Just 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:"
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 ""

158
sphinx/templates/getting_started/step_by_step/singletons_autoload.pot Normal file
View File

@@ -0,0 +1,158 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:4
msgid "Singletons (AutoLoad)"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:7
msgid "Introduction"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:9
msgid "Scene singletons are very 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 very 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:54
msgid "Or even simpler using the name directly:"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:61
msgid "Custom scene switcher"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:63
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:69
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:72
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:79
msgid "global.gd"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:81
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:86
msgid "Save the script as `global.gd`:"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:90
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:97
msgid "Now, whenever you run any of your scenes, the script is always loaded."
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:99
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:104
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:117
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:154
msgid "As mentioned in the comments above, we really 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:162
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:172
msgid "and"
msgstr ""
#: ../../docs/getting_started/step_by_step/singletons_autoload.rst:181
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:184
msgid "To load scenes with a progress bar, check out the next tutorial, :ref:`doc_background_loading`"
msgstr ""

66
sphinx/templates/getting_started/step_by_step/splash_screen.pot Normal file
View File

@@ -0,0 +1,66 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 really 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
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, just 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 ""

498
sphinx/templates/getting_started/step_by_step/ui_code_a_life_bar.pot Normal file
View File

@@ -0,0 +1,498 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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:87
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:89
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:90
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:95
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:97
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:99
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:103
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:106
msgid "Set up the Lifebar with the Player's max\\_health"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:108
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:114
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:121
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:125
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:136
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:142
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:146
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:150
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:156
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:160
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:162
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:167
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:169
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 very 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:178
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:187
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:191
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:196
msgid "The first section lists custom signals defined in ``player.GD``:"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:198
msgid "``died`` is emitted when the character just 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:200
msgid "``health_changed`` is emitted when the character got hit."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:204
msgid "We're connecting to the health\\_changed signal"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:206
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:216
msgid "The Connect Signal window with the GUI node selected"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:220
msgid "You can optionally connect nodes from the code. But doing it from the editor has two advantages:"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:222
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:223
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:225
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:237
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:244
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:246
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:257
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:260
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:265
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:267
msgid "The name makes it very 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:268
msgid "We will reuse this method a bit later"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:270
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:277
msgid "This method needs to:"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:279
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:281
msgid "set the ``TextureProgress``'s ``value`` to ``new_value``"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:291
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:295
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:302
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:306
msgid "Animate the loss of life with the Tween node"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:308
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:315
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:319
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:322
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:323
msgid "The property's identifier as a string"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:324
msgid "The starting value"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:325
msgid "The end value"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:326
msgid "The animation's duration in seconds"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:327
msgid "The type of the transition"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:328
msgid "The easing to use in combination with the equation."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:330
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:334
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:340
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:350
msgid "Let's break down the call:"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:356
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:364
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:374
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:379
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:390
msgid "Although we could animate the `health` property on the `Player`, we really 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:393
msgid "Assign the animated\\_health to the LifeBar"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:395
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:398
msgid "So far, the update\\_health method looks like this:"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:407
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:420
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:422
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:428
msgid "The animation is smooth but the number is broken"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:430
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:442
msgid "Try the game again to see a nice blocky animation."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:446
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:450
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 just 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:458
msgid "Fade the bar when the Player dies"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:460
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:465
msgid "First, the ``GUI`` needs to connect to the ``Player``'s ``died`` signal to know when it just 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:470
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:474
msgid "The signal should already have the Enemy connected to it"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:476
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:484
msgid "You should get these values in the Connecting Signal window"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:488
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:490
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:496
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:498
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:502
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:515
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:519
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:526
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:539
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:543
msgid "The final result. Congratulations for getting there!"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_code_a_life_bar.rst:547
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 ""

520
sphinx/templates/getting_started/step_by_step/ui_game_user_interface.pot Normal file
View File

@@ -0,0 +1,520 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:613
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 "Breaking down the UI"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:27
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:31
msgid "The life and energy counters on the left"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:32
msgid "The life and energy bars"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:33
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:39
msgid "The bomb and rupee counters on the right"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:35
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:38
msgid "The life and energy bars on the left"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:41
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:50
msgid "We get a clean UI layout with only 4 containers"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:52
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:57
msgid "Create the base GUI"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:59
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 just that in a moment."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:66
msgid "For now, let's start with a few containers."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:68
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:72
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:78
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:86
msgid "You should have 4 containers that look like this"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:90
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:96
msgid "Create the bars' base"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:98
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:104
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:115
msgid "A ``NinePatchRect`` named ``Background``"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:116
msgid "A ``TextureRect`` named ``Title``"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:117
msgid "And a ``Label`` named ``Number``"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:119
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:123
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:126
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:132
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:135
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:144
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:152
msgid "If you select both nodes, you should see something like this"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:154
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:161
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:170
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:173
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:186
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:190
msgid "Replace the Label's font"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:192
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:198
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:206
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:218
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:220
msgid "With this, we just 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:224
msgid "Add the progress bar"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:226
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:229
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:237
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:241
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:245
msgid "Design the bomb and rupee counters"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:247
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:250
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:255
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:264
msgid "Here's how your node tree should look so far"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:266
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:276
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:278
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:286
msgid "The Number node aligned to the left and centre"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:288
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:296
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:304
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:307
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:314
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:323
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:327
msgid "Turn the bar and counter into reusable UI components"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:329
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:335
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:344
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:352
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:362
msgid "With no extra changes, our Bar is ready to use"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:365
msgid "Use Scene Inheritance to create the remaining elements"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:367
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:375
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:378
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:387
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:392
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:398
msgid "Inherit the Bar Scene to build the LifeBar"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:400
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:408
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:410
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:419
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:428
msgid "Design the EnergyBar"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:430
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:433
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:439
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:444
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:453
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:456
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:464
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:468
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:473
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:480
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:482
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:486
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:493
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:501
msgid "The Count looks better now it's a bit smaller"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:505
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:512
msgid "Prepare the bomb and rupee counters"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:514
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:521
msgid "The bomb counter is the same as the original Counter scene"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:523
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:536
msgid "The rupee counter should look about like this"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:539
msgid "Add the UI components to the final GUI"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:541
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:549
msgid "The LifeBar and the EnergyBar align automatically"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:551
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:556
msgid "The nodes resize to take all the available vertical space"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:558
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:567
msgid "Now both counters have a decent size"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:571
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:574
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:585
msgid "The 2 bars align perfectly"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:589
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:594
msgid "Place the GUI onto the game's mockup"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:596
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:599
msgid "Head to the FileSystem dock and open ``LevelMockup.tscn``."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_game_user_interface.rst:601
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:608
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:617
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 ""

402
sphinx/templates/getting_started/step_by_step/ui_introduction_to_the_ui_system.pot Normal file
View File

@@ -0,0 +1,402 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 `Build your first game UI in Godot <#>`__."
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. To learn more about them, check the guide about `Advanced UI nodes and Themes <img/#>`__."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:57
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:60
msgid "Label: for displaying text"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:61
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:63
msgid "TextureProgress: for lifebars, loading bars, horizontal, vertical or radial"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:65
msgid "NinePatchRect: for scalable panels"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:66
msgid "TextureButton: to create buttons"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:70
msgid "The 5 most common Control nodes for UI design"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:73
msgid "TextureRect"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:75
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:79
msgid "``Scale On Expand (compat)`` scales the texture to fit the node’s bounding rectangle, only if ``expand`` property is ``true``; otherwise, it behaves like ``Keep`` mode. Default mode for backwards compatibility."
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:80
msgid "``Scale`` scales the texture to fit the node’s bounding rectangle"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:81
msgid "``Tile`` makes the texture repeat, but it won't scale"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:82
msgid "``Keep`` and ``Keep Centered`` force the texture to remain at its original size, in the top left corner or the center of the frame respectively"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:85
msgid "``Keep Aspect`` and ``Keep Aspect Centered`` scales the texture but force it to remain its original aspect ratio, in the top left corner or the center of the frame respectively"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:86
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:88
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:93
msgid "TextureRect modulated with a red color"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:96
msgid "TextureButton"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:98
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:105
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:115
msgid "TextureButton and its 5 texture slots"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:118
msgid "TextureProgress"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:120
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:124
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:129
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:139
msgid "TextureProgress bar, two thirds filled"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:142
msgid "Label"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:144
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:153
msgid "Picture of a Label"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:156
msgid "NinePatchRect"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:158
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 very 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:165
msgid "NinePatchRect scaled with the min\\_size property"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:168
msgid "There are two workflows to build responsive UIs"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:170
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:172
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:173
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:175
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:177
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:181
msgid "Place UI elements precisely with anchors"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:183
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:190
msgid "The anchor property"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:193
msgid "How to change the anchor"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:195
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:204
msgid "The layout menu in the viewport"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:207
msgid "Anchors are relative to the parent container"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:209
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:219
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:224
msgid "Margins change with the anchor"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:226
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:236
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:238
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:247
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:249
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:259
msgid "3 UI elements in an HBoxContainer, they align horizontally"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:261
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:267
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:270
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:274
msgid "Arrange control nodes automatically with containers"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:276
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:282
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:287
msgid "The 5 most useful containers"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:289
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:292
msgid "MarginContainer, to add margins around part of the UI"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:293
msgid "CenterContainer, to center its children in its bounding box"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:294
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:296
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:298
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:306
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:309
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:318
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:320
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:329
msgid "The HBoxContainer horizontally aligns UI elements"
msgstr ""
#: ../../docs/getting_started/step_by_step/ui_introduction_to_the_ui_system.rst:331
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:338
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:349
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:351
msgid "Godot's UI system is complex, and has a lot more to offer. To learn how to design more advanced interface, read `Design advanced UI with other Control nodes <img/#>`__."
msgstr ""

319
sphinx/templates/getting_started/step_by_step/ui_main_menu.pot Normal file
View File

@@ -0,0 +1,319 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

776
sphinx/templates/getting_started/step_by_step/your_first_game.pot Normal file
View File

@@ -0,0 +1,776 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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
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 very 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 just 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 just 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:809
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:815
msgid "HUD"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:817
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:823
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:827
msgid "The HUD displays the following information:"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:829
msgid "Score, changed by ``ScoreTimer``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:830
msgid "A message, such as \"Game Over\" or \"Get Ready!\""
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:831
msgid "A \"Start\" button to begin the game."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:833
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:837
msgid "Create the following as children of the ``HUD`` node:"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:839
msgid ":ref:`Label <class_Label>` named ``ScoreLabel``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:840
msgid ":ref:`Label <class_Label>` named ``MessageLabel``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:841
msgid ":ref:`Button <class_Button>` named ``StartButton``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:842
msgid ":ref:`Timer <class_Timer>` named ``MessageTimer``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:844
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:851
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:856
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:860
msgid "ScoreLabel"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:862
msgid "``Layout``: \"Center Top\""
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:863
#: ../../docs/getting_started/step_by_step/your_first_game.rst:876
#: ../../docs/getting_started/step_by_step/your_first_game.rst:889
msgid "``Margin``:"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:865
msgid "Left: ``-25``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:866
msgid "Top: ``0``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:867
msgid "Right: ``25``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:868
msgid "Bottom: ``100``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:870
msgid "Text: ``0``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:873
msgid "MessageLabel"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:875
msgid "``Layout``: \"Center Bottom\""
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:878
msgid "Left: ``-100``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:879
msgid "Top: ``-200``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:880
msgid "Right: ``100``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:881
msgid "Bottom: ``-100``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:883
msgid "Text: ``Dodge the Creeps!``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:886
msgid "StartButton"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:888
msgid "``Layout``: \"Center\""
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:891
msgid "Left: ``-60``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:892
msgid "Top: ``70``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:893
msgid "Right: ``60``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:894
msgid "Bottom: ``150``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:896
msgid "Text: ``Start``"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:898
msgid "The default font for ``Control`` nodes is very 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:903
msgid "Under \"Custom Fonts\", choose \"New DynamicFont\""
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:907
msgid "Click on the \"DynamicFont\" you just 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:913
msgid "Now add this script to ``HUD``:"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:930
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:953
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:984
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:1002
msgid "This function is called in ``Main`` whenever the score changes."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1004
msgid "Connect the ``timeout()`` signal of ``MessageTimer`` and the ``pressed()`` signal of ``StartButton``."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1034
msgid "Connecting HUD to Main"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1036
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:1043
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:1046
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:1049
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:1064
msgid "In ``game_over()`` we need to call the corresponding ``HUD`` function:"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1076
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:1089
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:1093
msgid "Finishing Up"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1095
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:1100
msgid "Background"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1102
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:1109
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:1113
msgid "Sound Effects"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1115
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:1120
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:1125
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:1128
msgid "Finally, add ``$DeathSound.play()`` in the ``game_over()`` function."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1131
msgid "Particles"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1133
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:1137
msgid "There are a very 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:1143
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:1148
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:1152
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:1157
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:1162
msgid "See :ref:`Particles2D <class_Particles2D>` for more details on using particle effects."
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1166
msgid "Project Files"
msgstr ""
#: ../../docs/getting_started/step_by_step/your_first_game.rst:1168
msgid "You can find a completed version of this project here: https://github.com/kidscancode/Godot3_dodge/releases"
msgstr ""

106
sphinx/templates/getting_started/workflow/assets/import_process.pot Normal file
View File

@@ -0,0 +1,106 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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. Just select in the filesystem dock the relevant resource:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/import_process.rst:31
msgid "And, after adjusting the parameters, just 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, just 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 ""

126
sphinx/templates/getting_started/workflow/assets/importing_audio_samples.pot Normal file
View File

@@ -0,0 +1,126 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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, requre 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 ""

312
sphinx/templates/getting_started/workflow/assets/importing_images.pot Normal file
View File

@@ -0,0 +1,312 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 copression 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 "Description"
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
#: ../../docs/getting_started/workflow/assets/importing_images.rst:54
#: ../../docs/getting_started/workflow/assets/importing_images.rst:54
msgid "|bad| Large"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_images.rst:52
#: ../../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
msgid "Performance"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_images.rst:56
#: ../../docs/getting_started/workflow/assets/importing_images.rst:56
#: ../../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
#: ../../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
#: ../../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
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 automaticlaly."
msgstr ""

469
sphinx/templates/getting_started/workflow/assets/importing_scenes.pot Normal file
View File

@@ -0,0 +1,469 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 very 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 really 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 "Import workflows"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:55
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:58
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:59
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:60
msgid "External animations: Allowing saved animations to be modified and merged when sources change."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:61
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:62
msgid "Single Scene: A single scene file with everything built in."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:66
msgid "As different developers have different needs, this import process is highly customizable."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:69
msgid "Import Options"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:71
msgid "The importer has several options, which will be discussed below:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:76
msgid "Nodes:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:79
msgid "Root Type"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:81
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:84
msgid "Root Name"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:86
msgid "Allows setting a specific name to the generated root node."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:89
msgid "Custom Script"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:91
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:95
msgid "Create a script that basically looks like this:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:106
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:111
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:130
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:185
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:225
msgid "Storage"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:113
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:117
msgid "Of course, instancing such imported scenes in other places manually works too."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:121
msgid "Materials"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:124
msgid "Location"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:126
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:132
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:136
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:140
msgid "Keep on Reimport"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:142
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:147
msgid "Compress"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:149
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:162
msgid "These are:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:153
msgid "Transform Matrix (Location, rotation, and scale) : 32-bit float to 16-bit signed integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:154
msgid "Vertices : 32-bit float to 16-bit signed integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:155
msgid "Normals : 32-bit float to 32-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:156
msgid "Tangents : 32-bit float to 32-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:157
msgid "Vertex Colors : 32-bit float to 32-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:158
msgid "UV : 32-bit float to 32-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:159
msgid "UV2 : 32-bit float to 32-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:160
msgid "Vertex weights : 32-bit float to 16-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:161
msgid "Armature bones : 32-bit float to 16-bit unsigned integer."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:162
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:166
msgid "Additional info:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:165
msgid "UV2 = The second UV channel for detail textures and baked lightmap textures."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:166
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:168
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:174
msgid "Meshes"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:177
msgid "Ensure Tangents"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:179
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:187
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:190
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:194
msgid "External Files"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:196
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:200
msgid "Animation Options"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:202
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:209
msgid "Import of animations is enabled by default."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:212
msgid "FPS"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:214
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:219
msgid "Filter Script"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:221
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:227
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:232
msgid "Optimizer"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:234
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:238
msgid "Clips"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:240
msgid "It is possible to specify multiple animations from a single timeline as clips. Just 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:244
msgid "Scene Inheritance"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:246
msgid "In many cases, it may be desired to do modifications to the imported scene. By default, this is not really 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:249
msgid "It is possible, however, to do local modifications by using *Scene Inheritance*. Just try to open the imported scene and the following dialog will appear:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:254
msgid "In inherited scenes, the only limitations for modifications are:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:256
msgid "Nodes can't be removed (but can be added anywhere)."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:257
msgid "Sub-Resources can't be edited (save them externally as described above for this)"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:259
msgid "Other than that, everything is allowed!"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:262
msgid "Import Hints"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:264
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:266
msgid "Adding collision detection to objects:"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:267
msgid "Setting objects as navigation meshes"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:268
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:270
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:275
msgid "Remove nodes (-noimp)"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:277
msgid "Node names that have this suffix will be removed at import time, mo matter what their type is. They will not appear in the imported scene."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:281
msgid "Create collisions (-col, -colonly, -convcolonly)"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:283
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:286
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:289
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:293
msgid "Option \"-convcolonly\" will create :ref:`class_convexpolygonshape` instead of :ref:`class_concavepolygonshape`."
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:295
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:302
msgid "Single arrow will create :ref:`class_rayshape`"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:303
msgid "Cube will create :ref:`class_boxshape`"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:304
msgid "Image will create :ref:`class_planeshape`"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:305
msgid "Sphere (and other non-listed) will create :ref:`class_sphereshape`"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:307
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:311
msgid "Create navigatopm (-navmesh)"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:313
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:317
msgid "Rigid Body (-rigid)"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_scenes.rst:319
msgid "Creates a rigid body from this mesh."
msgstr ""

170
sphinx/templates/getting_started/workflow/assets/importing_translations.pot Normal file
View File

@@ -0,0 +1,170 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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:48
#: ../../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:50
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:50
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:52
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:52
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:52
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
msgid "id"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
msgid "en"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
msgid "es"
msgstr ""
#: ../../docs/getting_started/workflow/assets/importing_translations.rst:61
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 ""

22
sphinx/templates/getting_started/workflow/assets/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/assets/index.rst:2
msgid "Assets workflow"
msgstr ""

106
sphinx/templates/getting_started/workflow/export/changing_application_icon_for_windows.pot Normal file
View File

@@ -0,0 +1,106 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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** exectuable."
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 deskop 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 ""

294
sphinx/templates/getting_started/workflow/export/customizing_html5_shell.pot Normal file
View File

@@ -0,0 +1,294 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 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>`_."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:15
msgid "Placeholder substitution"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:17
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:21
msgid "Placeholder"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:21
msgid "substituted by"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:23
msgid "``$GODOT_BASENAME``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:23
msgid "Basename of exported files without suffixes, e.g. ``game`` when exporting ``game.html``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:26
msgid "``$GODOT_DEBUG_ENABLED``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:26
msgid "``true`` if debugging, ``false`` otherwise"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:28
msgid "``$GODOT_HEAD_INCLUDE``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:28
msgid "Custom string to include just before the end of the HTML ``<head>`` element"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:32
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:36
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:39
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:42
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:48
msgid "The ``Engine`` object"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:50
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:53
msgid "The object itself has only two methods, ``load()`` and ``unload()``."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:56
msgid "``Engine.load(basePath)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:58
msgid "Loads the engine from the passed base path."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:60
msgid "Returns a promise that resolves once the engine is loaded."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:63
msgid "``Engine.unload()``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:65
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:69
msgid "Starting an ``Engine`` instance"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:71
msgid "The more interesting interface is accessed by instantiating ``Engine`` using the ``new`` operator:"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:78
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:84
msgid "``engine.init(basePath)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:86
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:89
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:93
msgid "``engine.preloadFile(file, fileName)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:95
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:98
msgid "If ``file`` is a string, the file will be loaded from that URL and the file name will be retained. If ``file`` is an ``ArrayBuffer`` or a view on one, the buffer will available as a file under the name given by ``fileName``."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:102
msgid "Returns a promise that resolves once the file is preloaded."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:105
msgid "``engine.start(arg1, arg2, …)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:107
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:112
msgid "Returns a promise that resolves once the engine started."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:115
msgid "``engine.startGame(mainPack)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:117
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:120
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:123
msgid "Returns a promise that resolves once the game started."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:126
msgid "Configuring start-up behaviour"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:128
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:132
msgid "``engine.setUnloadAfterInit(enabled)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:134
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:139
msgid "Defaults to ``true``."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:142
msgid "``engine.setCanvas(canvasElem)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:144
msgid "By default, the first canvas element on the page is used for rendering. By calling this method, another canvas can be specifed."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:148
msgid "``engine.setCanvasResizedOnStart(enabled)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:150
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:154
msgid "``engine.setLocale(locale)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:156
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:163
msgid "``engine.setExecutableName(execName)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:165
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:169
msgid "Customizing the presentation"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:171
msgid "The following methods are used to implement the presentation:"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:174
msgid "``engine.setProgressFunc(func)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:176
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 specifices the total number of bytes to load."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:188
msgid "If the total is 0, it couldn't be calculated. Possible reasons include:"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:191
msgid "Files are delivered with server-side chunked compression"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:192
msgid "Files are delivered with server-side compression on Chromium"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:193
msgid "Not all file downloads have started yet (usually on servers without multi-threading)"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:196
msgid "``engine.setStdoutFunc(func)``, ``engine.setStderrFunc(func)``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:198
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:209
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:212
msgid "By default, ``console.log()`` and ``console.warn()`` are used respecively."
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:215
msgid "Accessing the Emscripten ``Module``"
msgstr ""
#: ../../docs/getting_started/workflow/export/customizing_html5_shell.rst:217
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 ""

94
sphinx/templates/getting_started/workflow/export/exporting_for_android.pot Normal file
View File

@@ -0,0 +1,94 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 http://developer.android.com/sdk/index.html"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_android.rst:16
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 ""

154
sphinx/templates/getting_started/workflow/export/exporting_for_ios.pot Normal file
View File

@@ -0,0 +1,154 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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
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
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 ""

34
sphinx/templates/getting_started/workflow/export/exporting_for_pc.pot Normal file
View File

@@ -0,0 +1,34 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

134
sphinx/templates/getting_started/workflow/export/exporting_for_uwp.pot Normal file
View File

@@ -0,0 +1,134 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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://msdn.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 ""

222
sphinx/templates/getting_started/workflow/export/exporting_for_web.pot Normal file
View File

@@ -0,0 +1,222 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 <http://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."
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:13
msgid "Limitations"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:15
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:20
msgid "Exported ``.html`` file must not be reused"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:22
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:27
msgid "Using cookies for data persistence"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:29
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:34
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:39
msgid "Full screen and mouse capture"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:41
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:47
msgid "For the same reason, the full screen project setting is ignored."
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:50
msgid "HTTPClient"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:52
msgid "The ``HTTPClient`` implementation for the HTML5 platform has several restrictions:"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:55
msgid "Accessing or changing the ``StreamPeer`` is not possible"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:56
msgid "Blocking mode is not available"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:57
msgid "No chunked responses"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:58
msgid "Host verification cannot be disabled"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:59
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:62
msgid "Unimplemented functionality"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:64
msgid "The following functionality is currently unavailable on the HTML5 platform:"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:66
msgid "Threads"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:67
msgid "GDNative"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:68
msgid "Clipboard synchronisation between engine and operating system"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:69
msgid "Networking other than ``HTTPClient``"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:71
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:76
msgid "Starting exported games from the local file system"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:78
msgid "Many browsers will not load exported projects when **opened locally** per ``file://`` protocol. To get around this, use a local server."
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:81
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:86
msgid "Serving the files"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:88
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:92
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:96
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:101
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:109
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:113
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:119
msgid "Export options"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:121
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:125
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:128
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:132
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:139
msgid "Calling JavaScript from script"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:141
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:152
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:155
msgid "JavaScript ``number`` is returned as GDScript :ref:`class_float`"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:156
msgid "JavaScript ``boolean`` is returned as GDScript :ref:`class_bool`"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:157
msgid "JavaScript ``string`` is returned as GDScript :ref:`class_String`"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:158
msgid "JavaScript ``ArrayBuffer``, ``TypedArray`` and ``DataView`` are returned as GDScript :ref:`class_PoolByteArray`"
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:167
msgid "Any other JavaScript value is returned as ``null``."
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:169
msgid "Calling ``JavaScript.eval`` on platforms other than HTML5 will also return ``null``."
msgstr ""
#: ../../docs/getting_started/workflow/export/exporting_for_web.rst:172
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 ""

170
sphinx/templates/getting_started/workflow/export/exporting_projects.pot Normal file
View File

@@ -0,0 +1,170 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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. Just 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 just 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 ""
#: ../../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
msgid "To open the export menu, just 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 ""
#: ../../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
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 just 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 ""

258
sphinx/templates/getting_started/workflow/export/feature_tags.pot Normal file
View File

@@ -0,0 +1,258 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/export/feature_tags.rst:4
msgid "Feature Tags"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:7
msgid "Introduction"
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:32
msgid "**Description**"
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 "**JavaScript**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:36
msgid "Running on JavaScript (HTML5)"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:38
msgid "**OSX**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:38
msgid "Running on macOS"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:40
msgid "**iOS**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:40
msgid "Running on iOS"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:42
msgid "**UWP**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:42
msgid "Running on UWP"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:44
msgid "**Windows**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:44
msgid "Running on Windows"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:46
msgid "**X11**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:46
msgid "Running on X11"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:48
msgid "**debug**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:48
msgid "Running on a debug build"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:50
msgid "**release**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:50
msgid "Running on a release build"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:52
msgid "**32**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:52
msgid "Running on a 32-bit build"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:54
msgid "**64**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:54
msgid "Running on a 64-bit build"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:56
msgid "**mobile**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:56
msgid "Host OS is a mobile platform"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:58
msgid "**pc**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:58
msgid "Host OS is a PC platform (desktop/laptop)"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:60
msgid "**web**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:60
msgid "Host OS is a Web browser"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:62
msgid "**etc**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:62
msgid "Textures using ETC1 compression are supported"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:64
msgid "**etc2**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:64
msgid "Textures using ETC2 compression are supported"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:66
msgid "**s3tc**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:66
msgid "Textures using S3TC (DXT/BC) compression are supported"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:68
msgid "**pvrtc**"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:68
msgid "Textures using PVRTC compression are supported"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:72
msgid "Custom features"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:74
msgid "It is possible to add custom features to a build, just use the relevant field in the *export preset* used to generate it:"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:80
msgid "Overriding project settings"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:82
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:85
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:90
msgid "After overriding, a new field is added for this specific configuration:"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:95
msgid "Default overrides"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:97
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:103
msgid "Customizing Build"
msgstr ""
#: ../../docs/getting_started/workflow/export/feature_tags.rst:105
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 ""

22
sphinx/templates/getting_started/workflow/export/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/export/index.rst:2
msgid "Export"
msgstr ""

58
sphinx/templates/getting_started/workflow/export/one-click_deploy.pot Normal file
View File

@@ -0,0 +1,58 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../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 ""

22
sphinx/templates/getting_started/workflow/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/index.rst:2
msgid "Project workflow"
msgstr ""

22
sphinx/templates/getting_started/workflow/project_setup/index.pot Normal file
View File

@@ -0,0 +1,22 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/project_setup/index.rst:2
msgid "Project setup"
msgstr ""

70
sphinx/templates/getting_started/workflow/project_setup/project_organization.pot Normal file
View File

@@ -0,0 +1,70 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:4
msgid "Project organization"
msgstr ""
#: ../../docs/getting_started/workflow/project_setup/project_organization.rst:7
msgid "Introduction"
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 very 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 ""

66
sphinx/templates/index.pot Normal file
View File

@@ -0,0 +1,66 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\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 ""
#: ../../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 ""
#: ../../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. It means that the documentation team can always use your feedback and help to improve the tutorials and class reference. If you do not manage to 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>`_, or discuss with us on the ``#documentation`` channel on `Discord <https://godotengine.org/community>`_!"
msgstr ""
#: ../../docs/index.rst:34
msgid "The main documentation for the site is organized into the following sections:"
msgstr ""
#: ../../docs/index.rst:36
msgid "General"
msgstr ""
#: ../../docs/index.rst:44
msgid "Getting started"
msgstr ""
#: ../../docs/index.rst:55
msgid "Tutorials"
msgstr ""
#: ../../docs/index.rst:78
msgid "Development"
msgstr ""
#: ../../docs/index.rst:88
msgid "Community"
msgstr ""

130
sphinx/templates/tutorials/2d/2d_movement.pot Normal file
View File

@@ -0,0 +1,130 @@
# SOME DESCRIPTIVE TITLE.
# 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.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Godot Engine latest\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-04-10 12:22+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../../docs/tutorials/2d/2d_movement.rst:4
msgid "2D Movement Overview"
msgstr ""
#: ../../docs/tutorials/2d/2d_movement.rst:7
msgid "Introduction"
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
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 just 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 very 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 ""

Some files were not shown because too many files have changed in this diff Show More