The resource path holds the original path which can be used to convert
a dictionary to instance consistently both within editor and exported projects
as the original path is automatically remapped from `gd` to `gdc` or `gde` in
exported projects.
Make sure the instance is valid before trying to access the script in
after an error happened. If the instance is not valid it's possible that
the script is invalid as well.
Fix#29623
Use `GDScriptInstance` to iterate through all members directly instead.
This is similar to how `dict2inst` works and makes the serialization
behaviour more consistent.
This makes sure that the classes internally represented with an
underscore (_) prefix, such as singletons, are still properly checked
for inheritance in the ClassDB.
There's no need to subtract 1 from the assignment usages because it's
not incremented anywhere else.
Also put back the assignment with operators because they should not
count as usage if the argument is on the left side.
In some errors, there were closing quotation marks but no opening (e. g. "Unable to iterate on object of type " +
Variant::get_type_name(container->get_type()) + "'."
Some situations caused the parser node type to not being update when
trying to resolve the type, returning invalid data and breaking the
parsing when it shouldn't. This patch fix the behavior.
This fades out messages originating from the editor to make messages
printed by the project stand out more.
This also tweaks wording in some editor messages for consistency.
Tiny addition I personally found useful - this allows us to `var my_ref := weakref(null)` for nullable weak ref (with type hint!). When trying to test if `my_ref` is holding valid reference, we can just `if my_ref.get_ref():` instead of `if my_ref and my_ref.get_ref():` everywhere.
Before this patch, assert() only took the condition to assert on:
assert(item_data)
Now, it can optionally take a string that will be printed upon failure:
assert(item_data, item_name + " has no item data in ItemDatabase")
This makes it easier to immediately see what the issue is by being
able to write informative failure messages.
Thanks to @wiped1 for sharing their patch, upon which this is based.
Closes#17082
If you somehow end up with a Singleton.gd that looks like this:
extends Node
class_name Singleton
func foo():
pass
You will get an error when using it in another file:
extends Node2D
func _init():
# Parser Error: Non-static function "foo" can only be called from an instance.
Singleton.foo()
This error is confusing. This patch ensures that an error on the class_name line will be produced:
Parse Error: The class "Singleton" conflicts with the AutoLoad singleton of the same name, and is therefore redundant. Remove the class_name declaration to fix this error.
Fixes#28187.
The PR did not use the ScriptCodeCompletionOption system introduced
later on, and somehow this did not generate a merge conflict even
though neighboring code was changed.
Obeyed CLANG format rules
Obeying CLANG format rules attempt 2
Obeying CLANG format rules attempt 3
Clean up
Fixed runaway while loop
Removed int initialization
VarArg methods have the return type Object in the API json for GDNative. This
can cause undefined behavior in some language bindings due to lack of
documentation on VarArg methods' behavior.
This changes the MethodInfo of:
- CSharpScript::_new
- GDScript::_new
- PluginScript::_new
The last remaining ERR_EXPLAIN call is in FreeType code and makes sense as is
(conditionally defines the error message).
There are a few ERR_EXPLAINC calls for C-strings where String is not included
which can stay as is to avoid adding additional _MSGC macros just for that.
Part of #31244.
So far we left most temporary files lying around, so this attempts to
fix that.
I added a helper method to DirAccess to factor out the boilerplate of
creating a DirAccess, checking if the file exists, remove it or print
an error on failure.
This action will show help for target symbol in godot editor and bring the godot editor window to foreground
Improved markdown documentation for symbols.
Only level one inner classes would be resolved currently but it sould cover most real world use case
Improve documation parseing for const values
Improve documation format for native symbols
Improved uri and workspace path translatation on windows platform.
The smart resolvation is much faster than builtin's in the server side.
The smart resolve mode is still disabled as default as the clients might be slow with a planty of completion items.
This might be especially usefull since godot script doesn't support ** or ^ as operators, so beginners might search for the exponential function, when what they really need is the pow function.
This is exactly what happened to me and since I couldn't find helpfull information in the documentation I had to look it up online, where I found the answer on a helpfull [reddit thread](https://www.reddit.com/r/godot/comments/3mvwz0/how_do_i_do_exponents_in_godot/).
@akien-mga told me how to reference methods here:
godotengine#30909
