-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Fix typed array export #73256
Fix typed array export #73256
Conversation
Yes, but for all intents and purposes, this is a missing feature, not a bug. So it won't be too bad if we address this in 4.1.
Reduz gave it a cursory look before, and said
|
I wouldn't call it a missing feature. We do support node export and array export, they are just broken when used together. |
Thanks for doing this, I didn't have time to work on my PR but I'll be testing you branch today! The array assigning fix was broken by the changes made to |
scene/resources/packed_scene.cpp
Outdated
if (Engine::get_singleton()->is_editor_hint()) { | ||
// If editor, just set the metadata and be it | ||
node->set(prop_name, prop_variant); | ||
continue; | ||
} |
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.
Why does it need to be special cased here? The only difference seems to be not using the META_POINTER_PROPERTY_BASE
prefix, does it break Node arrays?
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 will assign the raw array of NodePaths. META_POINTER_PROPERTY_BASE
doesn't seem to work here. The condition can't be moved elsewhere and removing it crashes, so it's likely the only way.
scene/resources/packed_scene.cpp
Outdated
if (string_property.contains("/indices/")) { | ||
const Vector<String> properties = string_property.split("/"); | ||
Array array = dnp.base->get(properties[0]); | ||
|
||
if (array.size() >= properties[2].to_int()) { | ||
array.push_back(other); | ||
} else { | ||
array.set(properties[2].to_int(), other); | ||
} |
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.
Is it possible for a non-Array property path to include /indices/
too, and possibly trigger this logic in an unexpected way and crash?
Or can an Array property include /
in the first place, leading to the "/indices/
" + itos(k)suffix being at different indices when splitting by
/`?
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.
Is it possible for a non-Array property path to include /indices/ too, and possibly trigger this logic in an unexpected way and crash?
Yes and no. This code only runs for "deferred NodePath properties", i.e. properties stored as NodePath that are assigned a node after the scene is complete. This limits severely what properties are affected by this code. Users can't use /
in their properties without using _get_property_list()
, so it's extremely unlikely that this logic is triggered when it shouldn't. And even if it does, assigning non-Array Variant will result in empty array, I think. So it shouldn't crash.
Or can an Array property include / in the first place, leading to the "/indices/" + itos(k)suffix being at different indices when splitting by/`?
The /indices/
properties are created further above, near your first comment. Wrong /
are only possible if someone uses it wrongly.
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.
Just left some comments for things which may warrant more eyes on them. I didn't check the existing code to see if what I point out are valid potential problems, I'm just trying to make sure we don't cut corners as PackedScene is very sensitive.
Given the current timetable and the risks from this PR, let's keep it for 4.1 and consider for a 4.0.x cherry-pick once merged and well tested. In the meantime, it would be good to add a note in the relevant documentation to point to the missing feature. |
I would appreciate the code is commented a bit more because given its hacky, its hard to understand exactly what is going on. Additionally there are some unanswered comments in the review. |
@KoBeWi Bump :) |
Co-authored-by: Guilherme Sousa <guilherme.sousa1994@gmail.com>
I checked the code in detail and Node properties were already hacky. This PR just extends the hack to support arrays. The changes are pretty safe, as they only affect the "deferred NodePath" properties. I rebased/fixed the PR and added some comments. EDIT: |
Thanks! |
Does this also fix it for C#? |
Tested 4.1 Dev snapshot, upon assigning sprite2d node onto an Array of type Sprite2D, got this error:
|
IIRC NodePath is a separate issue |
Okay, I was under the assumption this PR fixed issue with dragging nodes into an exported typed array variable @Zireael07. So what does it fixed actually? |
This IS what the PR fixed, but somehow it's broken again on master. |
I opened #76378 |
Skipping this from being cherry-picked for now, as there seem to be problems uncovered by this PR. Once those are addressed, we can cherry-pick in a 4.0.x release. For now, this should be available for testing in 4.1 dev snapshots, if you want to provide feedback and help catch all the bugs. |
The uncovered bugs are corner-case, while this PR fixes a very requested feature. Also the only so far discovered regression is fixed by #76378 |
We would prefer to test the changes with 4.1 builds before picking it for a patch release that doesn't get much testing before publishing. |
It seems like it's not working on (at least my) Android export. If I |
@thornySoap Open a new issue, with a minimal reproduction project. |
Regarding the cherry-pick, see my comment here: #76378 (comment). We recommend updating to 4.1 if this issue greatly affects you. |
Borrowed from #67454
Fixes #62916
The issue has multiple duplicates, so I think it's better to have it fixed sooner than later. I rebased the PR and applied my comments. I also removed references to
_editor_prop_ptr_indices
, because it doesn't seem to be used anywhere (leftover from some old code?).The code overall needs checking probably, I mostly copied the PR and made it work (it just needed a fix in array assigning).