Previous wording said that @GDScript referred to entries that could be accessed in any script. Although with common sense we could imagine that it is only refering to GDScript specific pieces of code, the wording is a little unclear.
In general there are small changes to the wording which makes it more clear and concise.
Wording change
Tried to match the wording up with my last change which should make it a bit easier to parse at a glance what the docs mean by "from any script"
Changed language from "not specific to" to "which work in any language"
After consulting multiple people the new wording seems easier to parse, even for non coders
Update doc/classes/@GlobalScope.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Update modules/gdscript/doc_classes/@GDScript.xml
Co-Authored-By: Micky <66727710+Mickeon@users.noreply.github.com>
Co-authored-by: jordi <creptthrust@gmail.com>
Co-authored-by: K. S. Ernest (iFire) Lee <ernest.lee@chibifire.com>
Co-authored-by: Mack <86566939+Macksaur@users.noreply.github.com>
Allows setting any arbitrary hint, hint string, and usage flags.
Useful for more complex hints or potential future hints not
available as a dedicated annotation.
This reverts commit c7f68a27ec.
We still think GDScript files need UIDs to allow safe refactoring,
but we're still debating what form those should take exactly.
So far there seems to be agreement that it shouldn't be done via an
annotation as implemented here, so we're reverting this one for now,
to revisit the feature in a future PR.
This commit also adds means to manually disable warnings
in `code` tags where it's a false positive with the new
`skip-lint` attribute.
Warnings are now enabled on CI to prevent future errors.
Also:
* changed `[b]true[/b]` to `[code]true[/code]`
* use `[i]` for mathematical constant "e"
* use `[b]` for button text & menu item text
* improve markups about "tap1" and "tap2" in AudioEffectDelay
We don't use that info for anything, and it generates unnecessary diffs
every time we bump the minor version (and CI failures if we forget to
sync some files from opt-in modules (mono, text_server_fb).
Which allows editable data associated with a particular class instead of
the instance. Scripts with static variables are kept in memory
indefinitely unless the `@static_unload` annotation is used or the
`static_unload()` method is called on the GDScript.
If the custom function `_static_init()` exists it will be called when
the class is loaded, after the static variables are set.
