Rename KinematicCollision2D and 3D to CharacterCollision2D or 3D for the sake of consistency

[securas]

Describe the project you are working on

Currently, the collision of a Character2D or 3D node is described by a KinematicCollision2D or 3D object, respectively. These should be renamed to match the new naming scheme.

Alternatively, CharacterBody2D and 3D should be renamed to KinematicBody2D and 3D, respectively.

Describe the problem or limitation you are having in your project

N/A

Describe the feature / enhancement and how it helps to overcome the problem or limitation

N/A

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

N/A

If this enhancement will not be used often, can it be worked around with a few lines of script?

N/A

Is there a reason why this should be core and not an add-on in the asset library?

N/A

[Zireael07]

IIRC already proposed but it's too late for that?

[securas]

What do you mean by too late?

[Zireael07]

4.0 is already in RC phase. The team is postponing any non-critical fixes/stuff to 4.1 instead

[securas]

That’s fine. If this cannot be handled in this version, maybe a later version, if any. it’s not a critical issue, I think.

[AThousandShips]

Related: #6047

[Zireael07]

@AThousandShips thanks. I'm bad at searching discussions, apparently

[KoBeWi]

KinematicCollision2D is returned by move_and_collide() in PhysicsBody2D, so CharacterCollision is wrong.

[securas]

KinematicCollision2D is returned by move_and_slide() in PhysicsBody2D, so CharacterCollision is wrong.

Perhaps you mean move_and_collide from PhysicsBody.
Although that is true, KinematicCollision is is also returned from get_slide_collision(int x) and get_last_slide_collision() from CharacterBody.

[Shadowblitz16]

Maybe this #5003 can be done to 2D as well?
Then we can have consistency

[felinusfish]

I'm here to ask for this proposal to be moved to 4.3 @YuriSizov

The term "Character" is causing too much confusion for people who were used to 3.x, wondering if their CharacterBody is the correct node to use in certain use cases because they can no longer find the KinematicBody and all it is doing is teaching beginners that "CharacterBody is for players, NPCs and enemies" when its use case expands beyond this. This is further reinforced by the base script you are provided by the CharacterBody which provides beginners with a player movement script.

All that this rename has done is cause frustration and misdirection and I (and many others) believe that there needs to be a return to the "Kinematic" name and the description should be used to describe the fact that it can be used for such things as handling player characters.

[AThousandShips]

This level of massive compatibility breakage won't happen in 4.x, this kind of breaking change can only occur if there's some seriously not working features, and that simply isn't the case here, it's confusing, but it's nowhere near breaking

There's nothing objectively or functionally wrong with the current naming, and nothing is broken by it, the only issue is confusion or lack of consistency, neither of those are good arguments for major compatibility breakage

See here

[felinusfish]

Whilst I agree that there is nothing "functionally wrong," objectively I disagree as causing significant confusion and distress is a massive issue. If this rename comes much, much later, all it does is cause MORE confusion because 3.x has KinematicBody, 4.x has CharacterBody, and if 5.x goes back to KinematicBody (which it likely would) all it does is cause an INSANE amount of confusion to people who just want to make games. This node rename is better now than later because the longer it is delayed, the greater the confusion which will be caused by FURTHER renames in the years to come.

[AThousandShips]

First of all you're missing that this change isn't valid, see #6293 (comment), but also that's not how it works, please read the link I sent, we won't do this kind of compatibility change for something that isn't a serious bug 🙂

[felinusfish]

How is the change for renaming CharacterBody to KinematicBody invalid? And why are you trying to create this idea that exceptions are an impossible ask? I do not believe it is healthy to confuse users on purpose and ignore the fact that "Character" is a terrible name for the node in question.

[AThousandShips]

Well because then KinematicCollision would be confusing as it's used by other things as well (as the comment I linked to pointed out) 🙂

But please be constructive and reasonable and don't make unfounded accusations like that we are somehow confusing users on purpose... Saying "we can't do this" doesn't mean we're doing something on purpose, that's disingenuous

No one is ignoring anything, so please be constructive and reasonable, you are ignoring the clear points and rules about compatibility and no one is ignoring you.

Have a good day 🙂

[securas]

I raised this proposal mainly to highlight the absurdity of the unnecessary and unjustified change of the name of a node that was established before version 2.x.

But I don’t make the rules. The devs made the change and then made rules stating that you can’t change the name. This is not without some irony.

Nevertheless, my proposal remains valid and the reasons are, in my opinion, sustained. KinematicCollisons currently have a name that is unrelatable with other nodes. Renaming to CharacterCollision or even PhysicsCollision would relate them to existing classes. CharacterCollision would be better because those are usable nodes.

[AThousandShips]

The devs made the change and then made rules stating that you can’t change the name. This is not without some irony.

No, that rule was not made after the change...

[securas]

The devs made the change and then made rules stating that you can’t change the name. This is not without some irony.

No, that rule was not made after the change...

Then the change broke the rules

[AThousandShips]

Please read the link, we can break compatibility in major versions, that's how it works, please be reasonable and constructive

Now let's all stay constructive instead of making these kinds of unfounded statements

[securas]

Of course. My proposal is to change the name and I would also add to change the rules. Breaking compatibility has historically not been a significant hindrance to the development of the engine. There are multiple examples of this, even in 4.x.

[AThousandShips]

Then please open a proposal for that as it's outside the scope of this 🙂, let's stay on topic

But without a change to the rules this simply isn't an option for 4.x, even ignoring the actual arguments about this change being more confusing

Have a nice day 🙂

[securas]

Has with other changes that broke compatibility, I see no need to change a rule that is so easily broken. Instead, I would like to ask you to please stay on the topic of this proposal. Please make constructive remarks or provide reasonable alternatives.

[YuriSizov]

I'm here to ask for this proposal to be moved to 4.3 @YuriSizov

@Fishvap With all due respect, this is not going to happen.

The changes discussed here are over 2 years old (merged in June of 2021), Godot 4.0 has been out for almost a year with about half a year of public testing preceding that. At this point, this is an established terminology for this version of the engine. Changing it now is only going to further confusion and would only demonstrate how easily we are ready to break such fundamental features affecting almost any given project.

We could have this discussion nevertheless if there was a fully functioning physics team, with a plan and a vision where such a change would fit. If we had that we could discuss potentially breaking plans because we would have people to work on a smooth transition process, and, more importantly, people committed to the idea and confident that such a change is necessary going forward.

But we don't have that. We had it 2 years ago, and through a lengthy discussion and a lot of considerations we have arrived to the state as you have it now. As mentioned above, nothing is broken that can be fixed by a name change. And everything else can be fixed with time and experience, can be taught. Accepting that this kind of change is not possible is one of the first steps towards accepting these names and spreading knowledge about these nodes with confidence.

As for the milestone itself, it is set to 5.0 to indicate that the change is not feasible in the near future, that such an idea doesn't fit the 4.x branch of the engine. It is not, by any means, a commitment to do the suggested change in Godot 5.0. Simply because there is no Godot 5.0, not even in some distant plans. It may happen in 5 years, in 10 years, or never. All we can say for now is that this change can only be discussed then, when we are confident that there is going to be a major release that would allow us to majorly break something for the next iteration of the engine.

For Godot 4 this ship has sailed.

[securas]

Thanks for the comment. I should say that I was not expecting a different outcome. But it would be constructive to this discussion to provide the rationale behind the change in 4.0

That reason would perhaps be the better and definitive response rather than stating that its just not going to happen.

[YuriSizov]

@securas The rationale is provided by the proposal suggesting the change and by the PR implementing that proposal.

The short of it is — there are many schemes for naming and separating functionality available elsewhere, and out of all of them this is what felt the most sensible for Godot. For the long of it you will have to read the entire discussion. Look specifically for comments by reduz and pouleyKetchoupp for more or less the final official position.

You may disagree with the justification, of course, but I can't add anything more to it.