Mark underscored properties as internal

[raulsntos]

These properties look like they were intended to be internal but they were missing the PROPERTY_USAGE_INTERNAL flag.

• PackedScene::_bundled
• PortableCompressedTexture2D::_data
• ImporterMesh::_data

[AThousandShips]

These cases make sense to me, and I trust the C# side with respect to any possible compatibility, unsure how these are handled there (as this doesn't affect GDScript in any major way, beyond hiding it)

How does this affect extensions? Does the flag affect anything or is the _ already the controlling factor?

CC @dsnopek

[raulsntos]

C# also only hides them, so it doesn't break compatibility.

How does this affect extensions? Does the flag affect anything or is the _ already the controlling factor?

Yes, these properties are already excluded from extension_api.json because they are prefixed by _ (see #64429). Also, AFAIK godot-cpp doesn't generate properties anyway.

[AThousandShips]

Can confirm the API dump skips them already, and it doesn't touch the getter or setter so it won't change anything, so looks good all around

[Mickeon]

While I do agree in principle, I would be very careful with _bundled. It has been "public" for a really, really long time (even in 3.x).
Documented roughly, it's technically functional, and it's the main thing the reader will see when looking at PackedScene's documentation. Someone, somewhere out there is relying on this property, which will... not be unexposed, per say, but will suddenly look like it has disappeared.

In my opinion it should be deprecated in favour of using SceneState, instead.

However, if SceneState is "less" comfortable to access than the dictionary representation, this property has some reason to be exposed.

[AThousandShips]

I'd say documenting it was a mistake and it should either have been called bundled or not been documented, the impact should be minimal and I'd say to maybe just move the description of _bundled to the main description of the class if we consider it critical to not lose that information

[Calinou]

OptimizedTranslation also has those properties which don't any make sense when viewed in the inspector:

Should these be marked as internal?

Testing project: test_csv_translation.zip

[raulsntos]

@Calinou If you just want to hide them in the inspector we can use PROPERTY_USAGE_NO_EDITOR. If you also want to hide them from scripting, then we would also use PROPERTY_USAGE_INTERNAL.

However, these properties are added with _get_property_list which means they are already somewhat internal, since properties added this way aren't documented in the class reference and they won't be generated for the C# bindings. So marking them internal probably doesn't do much.

[akien-mga]

Thanks!

[BlueCube3310]

This PR causes a regression on the master branch as subresources of nodes are no longer saved, adding either the PROPERTY_USAGE_STORAGE or PROPERTY_USAGE_NO_EDITOR flag seems to fix it.

[Zireael07]

... and another regression where FBX/GLTF don't instance

[Mickeon]

I think it's really funny that the best way to have people test PRs is to force them to in a dev build, like throwing spaghetti at the wall to see if they stick.