Godot: Change default Node2d select-area size

[fluidvolt]

Hello, everyone! I've been enjoying Godot and am very impressed and loving it. Thanks to all those putting their hard work into it. I searched through the issues and it seems no-one's requested this in particular. I hope so, anyway!

So, onto the problem/feature request: it seems certain nodes (I think it's node2d and everything that inherits it that has no specific size attribute -- kinematic body, area2d, etc.) have a default select-area size of 64x64 px in the editor. This is the area that you can select objects in the editor, and it seems there's no way to change this size.

(The player root node shown above is a kinematic body, but again, it seems it's many nodes with this default, non-change-able size) As you can see above, in a low resolution game where every object is based on 16x16 tile-size, this makes selecting and arranging objects in the editor difficult (though the drop-down select tool helps). It would be super helpful to be able to set these node select-areas to something that fits the game you're making -- 16x16 in this case.

The feature, then: would it be possible to add a field in project settings marked, maybe, "set default node select size", and you could set a width/height there? That way if you're working on a game based around 16x16 tile-size you could type that in, and all of these kinds of nodes would have that size, allowing you to move and select and align things with no problem. Or maybe even just a way to set this kind of thing on a node-by-node basis, though I think just having a default you could set would be helpful enough!

Thanks again in advance, and I hope I'm doing this right.

[neikeq]

You can override Rect2 CanvasItem::_get_item_rect() in your node script.

I assume the node is a _CollisionObject2D_ or any other node with a _Sprite_ as child. If that's the case you can do this:

func _get_item_rect():
    return get_node("my_sprite").get_item_rect() # Notice this call does not start with _

Your script must have tools enabled.

[fluidvolt]

Wow, I had no idea Godot even had this kind of functionality! This definitely helps, thanks so much.

Do you all think being able to set the default node rect would still be useful? Since I'm going to change every object item_rect in this game to this one size I still think it would be super helpful to be able to set them all at once, to be able to set a custom default. What do you all think?

[bojidar-bg]

I think that "More options is more options", and that there should be a setting about the default Node2D item rect in Project Settings (engine.cfg).

[akien-mga]

Not critical for the upcoming 2.1, so moving to the next milestone. (As much as I'd like seeing this fixed soon :D)

[neikeq]

What category in project settings should we add this option to?

[vnen]

IMO this is not really useful as a project setting. You can have many nodes in the scene and want each of them to have a different bounding rectangle, so the option won't help so much.

[neikeq]

So what's the consensus? :P

[bojidar-bg]

Then a property on the Node2D class?

[Nearoo]

Yes, a property would probably be the best solution - however, since you can't edit properties of a node visually, I would suggest that, instead of setting a rect directly inside the properties editor, the user should be able to define a child node of which the size would be taken. If he wants to make the rect have a custom size he can always add another Node2D for that - though I imagine that most of the time the user will want to have the selectable rect of a scene to have the size of one of the scenes children anyways.

[Zylann]

Why not calculate the size of the rectangle so it fits the contents? Every other engine does that.

[bojidar-bg]

@Zylann That would make a level's root node size so big, we would have to lock it to be actually able to do stuff. Also, in case of particles/raycasts, you don't really want it, I think.

[Zylann]

@bojidar-bg then select children first? I find this unconvenient very often as well (but that's an option anyways). How are other engines dealing with this?

[Zylann]

Another use case: https://godotengine.org/qa/14352/make-resize-handles-for-nodes-have-the-same-shape-the-object

@bojidar-bg about level size, in addition to my previous comment, note that if it's a Node there are no wrapping handles needed (levels often don't need to be under a Node2D. And even if they do, the issue is the same as Tilemaps or terrains / or wrapping doesn't make sense for the root node of edited scene).

[akien-mga]

I think this was improved in the current master branch, could you check and confirm?

[reduz]

@Zylann the way it works makes it pretty difficult to do this, might need some serious redesign. In any case, kicking to 3.1, won't be done now.

[atomicstan]

I found this behavior very confusing and I actually wanted to report it as a bug. IMO select-area size should be based on a sprite in such situations. A default value would not work on sprites with different sizes.

[DleanJeans]

What's the progress on this?
And also what's the workaround now? get_item_rect() is no where to be found.

[RebelliousX]

get_item_rect() and get_item_and_children_rect() are removed from Godot v3? See issue #4738.
I would like to know if there are any alternatives.

[groud]

They are. They are definitely a bad practice and should not be used in game code. First because it's a recursive function that explores the whole tree, and second because it returns values that have nothing to do with the sprite size.
But I think I should be able to find a good solution for the original issue :)

[RebelliousX]

@groud Well, it depends on how you use them! You are right that they are not suitable to run every frame, and I don't think anybody was doing that either.

They are very useful, at least get_item_and_children_rect() which can be used for many useful things, like displaying a border frame around all children when selecting the children, or in my case, to find the middle of the width so a label can be placed in the middle. Also calculating label's width with all its text to keep it in the middle..

Please see issue #4738

After some search, I found that you made these undocumented functions and they start with _edit. That is horrible.

[groud]

They start with _edit because they are editor-only functions, that's why they are undocumented.
For your use cases, once again those functions are not meant to do that. Centering a label can be done with the margin/anchors. And if you need to calculate a children's rect, you should not use this function as Node2D returns a rectangle of 64x64 which is inconsistent.

What you are trying to achieve is a dirty workaround, we're not going to add those function again as they as using them is a bad practice. If you need to implement this behaviour again, just code it yourself, it's probably 4 lines of code.

[Zylann]

@RebelliousX although such a thing can be useful for both editor and game, it STILL is TWO different things, because of their usage. Typical example is, Node2D has no size, it's a point. So ingame it would give you zero. However, in editor, it can give a different size because of editing UX.

[RebelliousX]

@groud What is inconsistent really is any random guy can remove functional code if they fail to see its usefulness. And this is a major issue with Godot regardless of this issue.

@Zylann Good point, but what needs to be done is thinking of a better solution than removing existing functions. Meh, it is not the end of the world really.

[groud]

I perfectly understand why this is useful, but it's definitely a bad practice. I decided to remove it from the core as people might complain later on about it being slow or not acting as intended.

And stop with the ad-hominem attacks, it's not worth it. I'm not a "random guy" neither are you.

[RebelliousX]

Never meant to attack you or anyone personally, just stated a fact about an issue with Godot. And truth to be told, what I said applies to me too. So no offense was directed to you.

That aside, we need to think of what can be done for a better solution.

[bkanber]

Is there a way to do this now (in 3.0)? I'm also working with 16x16 and 32x32 sprites and this is certainly a bit annoying. Whether or not it's a bug, it is a usability issue and makes aspects of the editor unintuitive. A "container size" prop would be nice.

[groud]

I think the best solution is to implement a system that "shrinks" the selectable area of a node when it is either a linked scene or if its children are not selectable. I'll work on that ASAP.