-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removed faulty function update after get_property_list. #63712
Conversation
8bc06ad
to
0dfffe9
Compare
f87320d
to
a677eae
Compare
I cannot compile for mono, can anybody confirm that c# scripts look okay innthe inspector both for rool an non tool scripts with inheritance? |
To compile mono you need to rebase diff --git a/modules/mono/csharp_script.cpp b/modules/mono/csharp_script.cpp
index 0e3c17557c..62463e787a 100644
--- a/modules/mono/csharp_script.cpp
+++ b/modules/mono/csharp_script.cpp
@@ -1806,7 +1806,6 @@ void CSharpInstance::get_property_list(List<PropertyInfo> *p_properties) const {
}
#ifdef TOOLS_ENABLED
- Ref<Script> script = get_script();
if (script->is_valid()) {
props.push_front(script->get_class_category());
} This is probably what you intended to do, you were shadowing the |
Thanks, will fix that one! |
1838a40
to
92675e9
Compare
Managed to get mono running and fixed the inspector for mono too. It now looks good both for inherited, tool and non-tool scripts. :) |
92675e9
to
0ad894e
Compare
Ah, ok. Will fix the ordering. |
0ad894e
to
589c4fd
Compare
Reveresed the properties addition for C#. |
Checked on the artifact from actions, MoreCode: @export_category("Category 1")
@export_group("Group A", "group_a")
@export var group_a_var_a: float
@export var group_a_var_b: float
@export_group("Group B", "group_b")
@export var group_b_var_a: float
@export var group_b_var_b: float
@export_group("Group C", "group_c")
@export_subgroup("Subgroup A", "group_c_a")
@export var group_c_a_var_a: float
@export var group_c_a_var_b: float
@export_subgroup("Subgroup B", "group_c_b")
@export var group_c_b_var_a: float
@export var group_c_b_var_b: float |
Thanks for the note. I forgot to test those new features. Will see to it. |
They seem to only work in tool scripts now. Which is very weird, because they are parsed together with other annotations. Double-checked, and it works correctly in alpha 13 and current master. Edit: I guess in non-tool scripts script-defined categories and groups are stripped for some reason? And |
@object71 I figured how to fix the grouping annotations properly, you need to add a case in Something like this seems to be enough: for (int i = 0; i < c->members.size(); i++) {
const GDScriptParser::ClassNode::Member &member = c->members[i];
switch (member.type) {
// ...
case GDScriptParser::ClassNode::Member::GROUP: {
members_cache.push_back(member.annotation->export_info);
} break;
default:
break; // Nothing.
}
} Unlike regular variable members they don't have default values, but this doesn't seem to crash anything. Worst case scenario, some usages of |
I've tested some chaotic stuff with the aforementioned fix, and it seems to work as expected. For example, defining a category at the top of your script would hide the base script category, effectively overriding it. Pretty sweet! godot.windows.tools.64_2022-08-03_20-26-40.mp4There is a bug, though — when you change the exports on the base class, the inspector for the extending class does not react to these changes. You need to reload the scene to see the changes properly. This is probably outside of the scope for this particular PR, however. Code looks way better now, and IMO makes sense. I'd like a review from @vnen on this. |
The function tried to rearrange properties but that lead to problems with duplication or deleted properties. Implemented the logic that that function did inside the get_property_list both for tool scripts and non-tool scripts.
Thanks for the great suggestions and fixes. I added them in the latest version. Yeah I noticed the thing where it requires a reload of the scene to catch up some variables but it seems to be due to no call to update for the cached variables and I think it would be out of the scope of this PR. It is complicated enough as it is. |
a3038d4
to
0e1f7e9
Compare
I want this properly reviewed by @reduz but I expect this might take time to merge given the scope of the changes. In the meantime, I was wondering if we should revert #58443 to fix the arguably "worse" regression in |
OR! We could merge it for alpha 14 and let the public testing commence 😛 Up to you, but either way we have a rather prominent issue(s), whether we keep it as is or revert it. |
Well I wouldn't merge a core change without reduz even looking at it. Especially not as a follow-up to another core change which I merged without his review, which he then said was hacky, and which introduced a regression :) |
To be fair, he said it was okay to merge it, just needed comments, and he called the method itself hacky, and the method was added in 2020, and I agree that it's a big hack. |
Well that's settled 😄 |
Thanks! |
Can someone check if this breaks #62936? |
@bfeber I don't see why it would, the logic related to |
It does break it, just tested and compared the GitHub Actions builds. |
For future reference, the discussion continued in #63997. |
|
||
#ifdef TOOLS_ENABLED | ||
Ref<Script> script = get_script(); | ||
if (script->is_valid() && pcount > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @object71 do you remember wy you use x->valid()
in stead off x.valid()
?
->
makes my GDExtension crash so before making a PR I want to check if it was intentional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might need both (Ref::is_valid
and Script::is_valid
). The first checks if the object actually has a script attached to it. The second checks if the script itself is in a valid state. The code is currently missing the first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It indeed should be script.is_valid()
as it's the reference which needs to be validated before dereferencing it down below in script->get_class_category()
.
script.is_valid()
will call:
godot/core/object/ref_counted.h
Line 201 in a83eb16
inline bool is_valid() const { return reference != nullptr; } |
script->is_valid()
will dereference the stored reference
pointer (possibly nullptr
):
godot/core/object/ref_counted.h
Lines 104 to 106 in a83eb16
_FORCE_INLINE_ T *operator->() const { | |
return reference; | |
} |
and call (possibly crashing):
godot/core/object/script_language.h
Line 150 in a83eb16
virtual bool is_valid() const = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "possibly crashing" ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "possibly crashing" ?
@Gallilus I mean if the Ref<Script> script
's privateScript *reference
member is indeed nullptr
then script->is_valid()
is equivalent to nullptr->is_valid()
. And dereferencing nullptr
is an undefined behavior, might result in a crash.
Hence before any script->...
calls it should be ensured (e.g. by calling script.is_valid()
) that it can be dereferenced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may sound silly but I'm not jet a regular in C++ conversations.
With dereference you mean going true the pointer in the object to do stuff.
Not deleting it from memory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I had a .ptr() in my code so ...
MyClass my_object = memnew(MyClass);
Ref<MyClass > reference_1 = *my_object;
Ref<MyClass > reference_2a = reference_1;
Ref<MyClass > reference_2b = reference_1.ptr();
if (refrence_2b.is_valid()){
// Is reference_2 a or b valid?
// Will reference.is_valid() && refrence->is_valid() catch this problem?
}
The function tried to rearrange properties but that lead to problems with duplication or deleted properties. Implemented the logic that that function did inside the get_property_list both for tool scripts and non-tool scripts.
Fixes #63668
There shouldn't be an update function that rearranges properties in the first place. If there was a requirement for properties to be split into categories based on the class inheritance this should've initially been implemented into GDScript or GDScriptInstance function for getting properties.
NOT TESTED on GDExtension and C# scripts but it should work.