* Moved icon spec to itemised list
The icon specifications should not be considered a recommendation, but rather a requirement. Either way, the details of its ratio and size should be included with each form entry is described - as that is the natural place to look for it.
* Update community/asset_library/submitting_to_assetlib.rst
Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
* [Instancing with signals] Updated to 4.0
Basically started with changing `instance()` to `instantiate()`
Was a good chance to also upgrade the badly named `b` variables into proper intuitive names.
It's a good tutorial, short and to the point, though kinda abstract so I don't think there is anything more to add (if I put an image above the final codeblock, on how to add a signal via UI, it would ruin the abstraction imo)
* Made the signal location a bit more obvious
* Updated signal emission to 4.0 syntax
Interesting that emit_signal did work, backwards compatibility ftw!
`emit_signal()` its less intuitive as you must know a "magical function" of Godot instead of using the obvious variable, and also takes string argument lmao
The last code which would make the tutorial incompatible for 4.0 was this. I ran it locally on my 2D project to ensure it works.
Basically to replace the yield one-shot timer, I used this https://docs.godotengine.org/en/latest/classes/class_scenetreetimer.html
Fixes https://github.com/godotengine/godot-docs/issues/6234
@Calinou Related to this: If I do an upgrade/polish of the 2D tutorial [like I did with 3.0](https://github.com/godotengine/godot-docs/pull/6243) where I upload more **.webp** images and clarify and ref hyperlink here and there, would it be accepted soon, or delayed until after .webp support? Asking because it will take a day or two (I already have the images which is the hard part), and if that upgrade is merged in 4+ months, I would rather schedule my priorities in another way
* Clearification of what an action actually is.
There was no definition of an action itself. I also simplified the sentence, "An InputEvent may or may not represent a predefined action" to say that actions are not required but useful (combining with the next sentence).
Without the definition, I had thought actions were pre-defined input *conditions* (input states, rather than the input itself, since an action must have it's input defined). That mess of inquiry can be read here: https://www.reddit.com/r/godot/comments/xfvmg8/can_we_define_our_own_inputanalysis_for_inputmap/ Skip to first part of my last post to see the wording that corrected my understanding of what actions were.
This is my first-ever proposal. Thank you for the opportunity to contribute to the docs and help everyone understand things a little easier.
-- Kevin
* Streamline “Building the manual with Sphinx”
The goal of this commit is to make the instructions in “Building the
manual with Sphinx” easier to follow. It does so by
1. Removing items from the prerequisites list that would get installed by
requirements.txt anyway.
2. Adding items to the prerequisites list that were missing.
3. Making it possible to follow the instructions by reading them from
top to bottom without jumping around.
4. Putting the meat of the instructions into an ordered list (this will
make it easier for readers to not lose their place).
* Minor English fix for “Building the manual with Sphinx”
* [Dodge The Creeps] Explicit add child node clarification
Added explicit "add child node" instead of "add animated sprite 2d node as a child"
Also added Ctrl+A shortcut so users get slowly familiarized with the optimal workflow
* Project Manager Polishing
The logic behind this commit is my own experience as a newbie, where I had the project with the label opened, and on the "download this and just import it with project manager" part, i did not know how to open the project manager, and spent like 5 minutes before just closing and re-opening Godot
Co-authored-by: Max Hilbrunner <mhilbrunner@users.noreply.github.com>
It is impossible to instantiate a Light2D node, and a DirectionalLight2D node has no texture (so this tutorial doesn't work with it at all)
Feel free to deny this commit, because I am a newbie and don't know if it was possible to instantiate a Light2D node in 3.x either (if it was possible, the tutorial should stay as is, and this pull request should be closed)
Placed it above the code, instead of below. It was bad because "This function" yet it's the code above, so it wasn't even "the above function" lol
Now, the code explanation is above the code, like the rest of the docs, and the eye rolls linearly instead of "what is this" then reading below "aaah!" and reading above again lol
All the code has 1 line in ready(), then suddenly at the "finished/full" script, it has a very old version which doesn't even compile (final argument gives error)
Also, changed "check autostart property" to "enable autostart property" so it's more clear
This commit simplfies many sentences and rewords many sentences to make
them sound more natural. In some places, this commit rewords sentences
to make their structure more parallel. The goal of all of these changes
is to make the content guidelines easier to understand.
Before this commit, the paragraph at the bottom of “Guidelines and
principles” said pretty much the same thing that the paragraph at the
bottom of “Limiting cognitive load” said. This commit combines those two
paragraphs to reduce redundancy.
get_editor_interface().get_editor_main_control() no longer exists. `get_editor_main_control()` has been replaced with `get_editor_main_screen()`.
I changed all the occurrences in code, as well as adapted the text describing this accordingly.
