나에게 너무 지루하지만 동사로 사용되는 instance 를 instantiate 로 수정하는 사람에게 Godspeed.

16116

Sprite.set_region(val) -> Sprite.set_region_enabled(val)
Sprite.is_region() -> Sprite.is_region_enabled()

TileMap.set_y_sort_mode(val) -> TileMap.set_y_sort_enabled(val)
TileMap.is_y_sort_mode_enabled() -> TileMap.is_y_sort_enabled()

rect_min_size
Control.set_custom_minimum_size(값) -> Control.set_rect_min_size(값)
Control.get_custom_minimum_size() -> Control.get_rect_min_size

Control 클래스에는 get/set이 모두 변수와 동일한 이름을 가져야 하는 더 많은 것들이 있습니다. 변수 이름을 알 때마다 도크를 확인하는 것은 성가신 일입니다.

TileMap 클래스에는 해당 속성과 일치하지 않는 getter 및 setter 메서드가 많이 있습니다. 사실 나는 그 클래스에 있는 대부분의 getter와 setter의 이름을 바꾸는 것이 좋습니다. 그래서 그들은 다른 클래스의 이름뿐만 아니라 속성에도 동의합니다.

Animation.track_remove_key_at_position은 다음과 같아야 합니다.
Animation.track_remove_key_at_time

행동 양식

• OS : execute 는 두 가지 다른 방법으로 분할되어야 합니다. 하나는 차단이고 다른 하나는 비차단입니다.
  예: 이름: execute / exec_process (차단) 및 spawn_process (비차단) #19302

LineEdit에는 "text_changed"에 대한 new_text 매개변수가 있지만 TextEdit에는 없습니다.

https://github.com/godotengine/godot/blob/master/scene/gui/text_edit.cpp#L6104
https://github.com/godotengine/godot/blob/master/scene/gui/line_edit.cpp#L1466

VBoxContainer/HBoxContainer/GridContainer가 간단한 VBox/HBox/Grid로 이름이 바뀌었으면 합니다...

그리고 나중에 pos->position 처럼 너무 짧아서 다시 이름이 바뀝니다. :D

그들은 조금 길다 당신이 옳다.

나는 Godot가 현재 그 메소드 이름에 두 가지 다른 명명 규칙을 가지고 있다는 것을 알아차렸습니다.

때로는 [action][object]() 형식과 같은 C# 또는 Java와 같은 언어의 API에서 찾을 수 있는 일반적인 규칙을 따릅니다.

• Mesh.GetBlendShapeName()
• AnimationPlayer.GetCurrentAnimation()
• Button.GetButtonIcon()

그러나 다른 곳에서는 다음과 같이 [prefix][action][object]() 의 다른 규칙을 따릅니다.

• Mesh.SurfaceGetFormat()
• AnimationTreePlayer.NodeGetInputCount()
• CollisionObject.ShapeOwnerGetOwner()

그것들은 많은 것 중 몇 가지 예일 뿐입니다.

우리가 미래에 호환성을 깨는 전면적인 변경을 할 여유가 있다면, 하나의 잘 정의된 명명 규칙을 따르도록 이름을 바꿀 수 있기를 바랍니다.

그러나 다른 곳에서는 다음과 같이 [prefix][action][object]() 의 다른 규칙을 따릅니다.

• Mesh.SurfaceGetFormat()
• AnimationTreePlayer.NodeGetInputCount()
• CollisionObject.ShapeOwnerGetOwner()

나는 모든 사용법을 다시 확인하지 않았지만 내가 본 바에 따르면 이 스타일의 이름 지정은 다소 어색하지만 특정 규칙을 따릅니다. 예를 들어 shape_owner_get 메서드는 다음과 같습니다.

doc/classes/CollisionObject.xml
101:            <method name="shape_owner_get_owner" qualifiers="const">
110:            <method name="shape_owner_get_shape" qualifiers="const">
121:            <method name="shape_owner_get_shape_count" qualifiers="const">
130:            <method name="shape_owner_get_shape_index" qualifiers="const">
141:            <method name="shape_owner_get_transform" qualifiers="const">

"접두사"는 첫 번째 인수를 나타내며 get 뒤의 부분은 실제로 해당 접두사에서 얻게 될 것입니다. 예를 들어 shape_owner_get_shape_index(owner_id, shape_id) 는 개념적으로 get_shape_owner(owner_id)->get_shape_index(shape_id) 와 유사하지만 스크립팅 API에 노출된 ShapeOwner 가 없으므로 이 "바로 가기"입니다.

surface_get 메서드에 대한 동일한 이야기:

doc/classes/ArrayMesh.xml
88:             <method name="surface_get_array_index_len" qualifiers="const">
97:             <method name="surface_get_array_len" qualifiers="const">
106:            <method name="surface_get_arrays" qualifiers="const">
114:            <method name="surface_get_blend_shape_arrays" qualifiers="const">
122:            <method name="surface_get_format" qualifiers="const">
131:            <method name="surface_get_material" qualifiers="const">
140:            <method name="surface_get_name" qualifiers="const">
148:            <method name="surface_get_primitive_type" qualifiers="const">

doc/classes/VisualServer.xml
2363:           <method name="mesh_surface_get_aabb" qualifiers="const">
2374:           <method name="mesh_surface_get_array" qualifiers="const">
2385:           <method name="mesh_surface_get_array_index_len" qualifiers="const">
2396:           <method name="mesh_surface_get_array_len" qualifiers="const">
2407:           <method name="mesh_surface_get_arrays" qualifiers="const">
2418:           <method name="mesh_surface_get_blend_shape_arrays" qualifiers="const">
2429:           <method name="mesh_surface_get_format" qualifiers="const">
2440:           <method name="mesh_surface_get_index_array" qualifiers="const">
2451:           <method name="mesh_surface_get_material" qualifiers="const">
2462:           <method name="mesh_surface_get_primitive_type" qualifiers="const">
2473:           <method name="mesh_surface_get_skeleton_aabb" qualifiers="const">

또는 ATP의 *node_get 메서드:

doc/classes/AnimationTreePlayer.xml
35:             <method name="animation_node_get_animation" qualifiers="const">
44:             <method name="animation_node_get_master_animation" qualifiers="const">
53:             <method name="animation_node_get_position" qualifiers="const">
109:            <method name="blend2_node_get_amount" qualifiers="const">
146:            <method name="blend3_node_get_amount" qualifiers="const">
172:            <method name="blend4_node_get_amount" qualifiers="const">
225:            <method name="mix_node_get_amount" qualifiers="const">
255:            <method name="node_get_input_count" qualifiers="const">
264:            <method name="node_get_input_source" qualifiers="const">
275:            <method name="node_get_position" qualifiers="const">
284:            <method name="node_get_type" qualifiers="const">
315:            <method name="oneshot_node_get_autorestart_delay" qualifiers="const">
324:            <method name="oneshot_node_get_autorestart_random_delay" qualifiers="const">
333:            <method name="oneshot_node_get_fadein_time" qualifiers="const">
342:            <method name="oneshot_node_get_fadeout_time" qualifiers="const">
478:            <method name="timescale_node_get_scale" qualifiers="const">
523:            <method name="transition_node_get_current" qualifiers="const">
532:            <method name="transition_node_get_input_count" qualifiers="const">
541:            <method name="transition_node_get_xfade_time" qualifiers="const">

지금까지 제공된 대부분의 제안으로 OP를 업데이트했습니다.

VBoxContainer/HBoxContainer/GridContainer의 이름을 단순 VBox/HBox/Grid로 변경하고 싶습니다.

나는 확신하지 못합니다. Godot에서 우리는 모든 것에 명확한 이름을 부여하려고 노력합니다. 예를 들어 Grid 는 그것이 컨테이너라고 말하지 않습니다. VBox 및 HBox 상자가 정의상 컨테이너라고 주장할 수 있지만 Container 와 동일하지 않은 BoxContainer 가 있으므로 제 생각에는 자세한 내용은 여전히 ​​보증됩니다.

LineEdit에는 "text_changed"에 대한 new_text 매개변수가 있지만 TextEdit에는 없습니다.

TextEdit에 new_text 를 추가하는 것은 유용하지 않을 것 같습니다. LineEdit에서는 변경된 텍스트가 아니라 LineEdit의 전체 텍스트를 포함하므로 LineEdit의 text_changed 에는 없어야 한다고 주장합니다. 그러나 새 문자를 눌렀을 때 여러 줄 TextEdit의 전체 텍스트로 작업을 수행하는 것보다 입력 시 LineEdit의 전체 텍스트를 사용하려는 경우가 더 일반적입니다.

@akien-mga

모든 사용법을 다시 확인하지는 않았지만 이 스타일의 이름 지정 방식은 다소 어색하지만 특정 규칙을 따릅니다.

자체 명명 규칙이라는 사실을 알고 있습니다. 그러나 이것은 여전히 ​​Godot 외부에서 일반적으로 사용되는 것이 아니며, 때로는 BlendShape 와 같은 동일한 단어가 두 가지 다른 명명 규칙을 따르는 메소드에서 사용되기 때문에 약간 혼란스럽습니다.

개인적으로 일관성을 위해 모두 GetPrefix* 및 SetPrefix* 을 바꾸고 싶지만 다른 사람들은 이에 대해 다른 의견을 가질 수 있습니다.

방법이 #16757에서 변경되었습니다. 인수 순서가 더 합리적이지만 3.0과 3.1 사이의 API 호환성을 깨뜨립니다(#19648).

#9128을 다시 올립니다. 3D의 translation 대 2D의 position 는 이상한 비유사입니다.
그것은 3.0 이전에 나이를 먹었지만 3.0이 나간 후 폐쇄되었습니다.

OS.execute 는 posix_spawn 사용해야 합니다.

다른 하나는 제어 노드에 대해 "여백"의 이름을 "오프셋"으로 바꾸는 것일 수 있습니다.
여백은 오른쪽에서 음수이므로 특히 StyleBox와 비교할 때 사람들을 오도합니다.

@groud 오프셋이 너무 일반적이라고 생각하지만 여백은 처음 도입될 때 오른쪽에 부정적인 방향이 없었기 때문에 올바른 단어로 사용되었습니다.

@groud 오프셋이 너무 일반적이라고 생각하지만 여백은 좋은 용어였습니다(처음 도입했을 때 음수가

음, 마진은 이제 음수이므로 오해의 소지가 있습니다. 오프셋은 일반적이지만 더 의미가 있습니다. 나는 그것이 제어 노드의 컨텍스트에 있기 때문에 일반적이라는 것이 문제라고 생각하지 않습니다.
어쨌든 나는 더 나은 제안에 열려 있습니다. 이러한 속성 이름 변경이 이미 제안되었기 때문에 이 아이디어를 여기에 삭제하고 싶었습니다. 예를 들어 여기 를 참조

상자/큐브의 크기 이름이 일관되지 않습니다.
충돌에 대한 BoxShape는 범위를 사용합니다.
CubeMesh는 x, y 및 z가 각각 크기의 절반인 크기 속성을 가지고 있습니다.
CSGBox에는 CubeMesh의 x, y, z 크기와 같이 정의된 Width, Height 및 Depth 속성이 있습니다.

크기 속성 외에 "Cube"가 사용되는 경우도 있고 "Box"가 사용되는 경우도 있습니다. CubeMesh의 x, y 및 z는 독립적으로 설정할 수 있고 따라서 상자이기도 하므로 모든 것에 "Box"를 사용하는 것이 합리적입니다.

정확히 운영 체제가 아닌 HTML5 및 UWP를 대상으로 사용하므로 OS 이름을 Platform(PlatformWindows, PlatformUnix,...)으로 바꾸는 것을 제안합니다.
OS/디스플레이 분할에도 의미가 있습니다.

이 #20228부터 Label.clip_text 는 더 이상 필요하지 않습니다. Button.clip_text도 마찬가지라고 생각합니다.

Camera2D에는 현재 offset (일반 오프셋 및 V와 H로 분할된 것)라는 두 개의 서로 다른 속성이 있으며 완전히 다른 두 가지입니다. 이것은 정말 혼란스럽습니다.

행동 양식

- Dictionary : erase_checked 를 제거해야 합니다(이 메서드는 스크립트에 노출되지 않음).
- Dictionary : erase 는 bool 를 반환하도록 변경되어 지정된 키가 있는 쌍이 제거되었는지 여부를 결정해야 합니다( erase_checked 구현 참조).

20945

@neikeq 이것은 이제 IMO에서 수행할 수 있으며 Dictionary.erase 의 반환 값을 void 에서 bool 하면 프로젝트가 중단되지 않습니다.

@akien-mga 하지만 GDNative API 호환성을 깨뜨릴 것입니다. 그렇지 않습니까?

@akien-mga 앞으로 호환성이 깨지지 않습니까? 잠재적으로 3.1 스크립트가 3.0과 같은 이전 버전에서 작동하지 않도록 변경할 수 있습니까?

예 @neikeq, 3.1 스크립트가 이미 3.0와 호환되지 않는 ( class_name , 새로운 선택적 매개 변수 또는 새로운 속성 / 메소드, 새로운 클래스 등과 API 변경의 톤). 우리는 이전 버전이 아닌 이전 버전과의 호환성만 처리합니다.

알 겠어요! 그렇다면 지금 변경하겠습니다.

목록에 하나를 추가할 수 있다면 LineEdit 및 TextEdit 제어 노드는 서로 일관성 있는 API를 사용함으로써 실제로 이점을 얻을 수 있으므로 (대부분) 상호 교환 가능하게 사용할 수 있습니다. 지금은 한 노드를 보고 있으면 다른 노드에 대해 혼란스러워질 정도로 함께 작업하려고 하는 것이 엉망진창처럼 느껴집니다.

@eska014 또한 scons 옵션은 이미 platform 입니다. 일관성을 유지하는 것이 합리적입니다.

프로젝트 설정 display/window/size/test_width 및 test_height 이름을 window_width 및 window_height 로 변경해야 합니다. 또한 width 및 height 설정의 이름을 바꾸는 것을 고려해야 합니다. 아마도 render_width 및 render_height 입니다.

카메라의 근거리 및 원거리 속성은 setter/getter와 이름이 다릅니다(예: set_znear/set_zfar). 이것은 변경되어야 합니까?

znear 및 zfar 가 혼동됩니다. 그것은 세계 공간의 Z 축과 아무 관련이 없습니다. 클리핑 평면을 제어하기 때문에 clip_near 및 clip_far 또는 near 및 far 로 변경할 수 있습니다.

예, 이 문제를 해결하는 두 가지 방법이 있습니다.

바이너리 리소스 확장을 없애거나 진지하게 논의해야 합니다. (RES_BASE_EXTENSION)

gdscript_function.cpp 와 gdscript_functions.cpp 는 이름이 매우 비슷하여 계속 혼동됩니다. 이름을 바꿀 가치가 있습니까? @vnen

https://github.com/godotengine/godot/pull/21425 를 변경하여 "decimals"의 이름을 "step_decimals"로 변경하고 "decimals"를 별칭으로 유지했습니다. 병합되었다고 가정하면 다음 호환성 손상에서 "소수점"을 제거할 수 있습니다. 그렇지 않은 경우 이름만 바꾸면 됩니다.

@mysticfall 제 생각에는 불필요한 경우 메서드 이름에 "get"이라는 단어를 사용하지 않는 것이 좋습니다.

때때로 당신은 속성이 get과 set을 모두 할 수 있기를 원하지만 액세스를 제어하기를 원합니다. C#에서 속성을 사용하면 마치 필드인 것처럼 읽고 할당하여 이 작업을 수행하고 액세스를 제어할 수 있습니다.

 var thing = CollisionObject.ShapeOwner;
 CollisionObject.ShapeOwner = thing;

그러나 GDScript에서 속성은 사물(?)이 아닙니다. get이라는 단어 없이 메소드 이름을 가질 수도 있습니다. 대부분의 메소드는 무언가를 반환하므로 set-ness보다 암시적 get-ness가 더 좋습니다. GDScript에는 속성이 있으므로 더 자주 사용하는 것이 좋습니다. 이에 대한 문서를 찾을 수 없습니다. setget 하여 GDScript 내부에서 수행하는 방법에 대한 문서를 찾았지만 C++를 통해 추가하는 것은 어떻습니까?

간단히 말해서, 일관성이 없는 위치에 "get"이 있는 것이 좋지 않다는 데 동의하지만, 제 생각에 이상적인 솔루션 은 현재 GDScript 속성 "get"을 제거하고 "set"을 유지할 수 있습니다. .

@aaronfranke GDScript에는 속성이 있습니다. 엔진 클래스가 getter 및 setter(또는 getter만)를 정의하고 속성으로 GDScript에 노출할 수 있기 때문입니다. 즉, 1) 이름을 더 명확하게 만들고 2) getter와 setter를 구별하기 때문에 메서드에서 get 및 set 를 제거하는 것에 반대합니다. 예를 들어 Mesh.SurfaceFormat() 는 "형식을 가져오는" 메서드가 아니라 "표면 형식을 지정하는" 메서드처럼 들립니다. 또한 이들 중 대부분(전부는 아닐지라도)을 무시하고 속성으로 대신 사용할 수 있습니다.

이제 gdscript_function.cpp 및 gdscript_functions.cpp 대해 그다지 신경 쓰지 않습니다. 하나는 GDScriptFunction 클래스를 가지고 있고, 다른 하나는 GDScript 함수의 정의를 포함합니다. 어느 것이 어느 것인지 항상 명확합니다. 또한 주요 변경 사항이 아니므로 여기에서 필요하지 않습니다.

예, GDScript에는 속성이 있습니다. C# 속성은 GDScript가 속성을 가져오는 ClassDB에서 생성됩니다.

RigidBody 에는 몇 가지 메서드가 있으며 일관성을 위해 매개변수를 바꿔야 하는 관련 클래스입니다.

• RigidBody.add_force(force, position) ~ add_force(position, force)
• PhysicsDirectBodyState.add_force(force, position) ~ add_force(position, force)
• PhysicsServer.body_add_force(force, position) ~ add_force(position, force)

클래스 및 메소드 목록

@TGRCdev add_force 를 (위치, 힘)으로 변경하는 것보다 apply_impulse 를 (힘, 위치)로 변경하는 것을 훨씬 선호합니다. 힘의 위치는 선택적 매개변수이므로 끝에 가야 합니다. 그러나 모든 힘과 충동에는 힘 벡터가 있어야 합니다.

@aaronfrank 페어 포인트. 이 경우 필요한 스왑 목록은 다음과 같습니다.

• RigidBody.apply_impulse(position, impulse) ~ apply_impulse(impulse, position)
• RigidBody2D.add_force(position, force) ~ add_force(force, position)
• RigidBody2D.apply_impulse(position, impulse) ~ apply_impulse(impulse, position)
• PhysicsDirectBodyState.apply_impulse(position, impulse) ~ apply_impulse(impulse, position)
• Physics2DDirectBodyState.add_force(position, force) ~ add_force(force, position)
• Physics2DDirectBodyState.apply_impulse(position, impulse) ~ apply_impulse(impulse, position)
• PhysicsServer.body_apply_impulse(position, impulse) ~ body_apply_impulse(impulse, position)
• Physics2DServer.body_add_force(position, force) ~ body_add_force(force, position)
• Physics2DServer.body_apply_impulse(position, impulse) ~ body_apply_impulse(impulse, position)

@aaronfranke Get- 또는 Set- 접두사를 사용하는 것은 C#에서 피하는 것이 더 나은 일종의 '자바주의'라는 데 동의합니다.

내 주요 관심사는 shape_owner_get_shape 또는 node_get_input_count 와 같은 경우와 같이 '도메인 접두사'를 사용하는 것이었습니다. 따라서 Get- 또는 Set- 없이 적절한 C# 속성으로 다시 구현할 수 있다면

참고로 저는 Godot의 C# API 속성에 일치하는 getter 및 setter 집합이 있다는 것이 항상 이상하다고 생각했습니다. 예를 들어 Node.Name 및 Node.GetName() / Node.SetName() .

나에게는 다소 중복되는 느낌이 들지만 그러한 규칙을 유지하는 이유가 있다면 어쨌든 NodeInputCount 및 GetNodeInputCount() / SetNodeInputCount() 모두 얻을 수 있다고 가정합니다. 제안된 대로 node_get_input_count 이름을 변경합니다.

여러분, Godot API에 초점을 맞춘 이번 호 외의 C# API 및 일반적인 규칙에 대한 논의를 계속하십시오. Godot API(C++, C 및 GDScript)는 다른 언어에 대한 개선 사항이 아닌 한 C#을 위해 조정되지 않습니다.

@akien-mga node_get_input_count 이름을 get_node_input_count 와 같은 이름으로 바꿀 수 있는지에 대해 논의하는 것은 C# 고유의 문제가 아니라고 생각합니다.

아니요, C# 관련 내용은 이 문제에 포함되어서는 안 됩니다. 필요한 경우 C# 관련 호환성 손상에 대한 또 다른 문제가 있을 수 있습니다(이미 여러 IINM이 있지만).

Spatial의 이름을 Node3D로 바꾸는 것은 어떻습니까? 나는 항상 그것을 이상하게 여겼습니다.

@KoBeWi Godot가 현재 사용하는 명명 체계는 2D 항목의 경우 "Thing2D"이고 3D 항목의 경우 "Thing"이므로 나머지 2D 코드와 상당히 일치합니다. 물론 "Spatial"이라고 하는 논리적인 것은 "2D"를 제거하는 패턴에 따라 "Node"이지만 그 이름은 이미 취한 것입니다.

현재 Godot가 사용하는 명명 체계는 2D 항목의 경우 "Thing2D"이고 3D 항목의 경우 "Thing"입니다.

그래서 모든 3D를 "Thing3D"로 변경할 수 있습니까? 그것도 내 마음을 넘어 갔지만 과잉처럼 들립니다.
어쨌든, 나는 단지 제안했다. 별로 중요하지 않은 것 같습니다. 또한 Spatial2D는 Spatial보다 훨씬 나쁩니다.

따라서 String.right()는 주어진 위치에서 n개의 오른쪽 문자를 반환합니다. 오른쪽부터 n자만 반환하면 더 직관적이지 않을까요?

"abcdef".right(2)
"cdef" 대신 "ef"를 반환합니다. IMO가 더 좋을 것입니다.

나는 같은 것을 기대했다.

Python에는 대부분의 사용자가 GDScript를 Python과 비교하는 것과 동일한 방법이 있습니다. 바꾸면 더 헷갈릴 것 같습니다.

@KoBeWi 동의합니다. 현재 구현과 하위 문자열 간의 차이점을 알 수 없습니다.

Godot substr 는 오른쪽에 있는 모든 것을 원하면 문자열의 크기를 나타내도록 합니다.

@Zylann 대부분의 구현에서는 두 번째 매개변수를 생략할 수 있습니다. 나는 이것을 Godot 측의 문제라고 생각합니다. 게다가, 나는 substr 가 다른 이름을 가진 새 메소드보다 두 번째 매개변수를 선택사항으로 만들도록 합니다.

@Zylann @neikeq 이것은 길이 지정과 길이 지정을 모두 가질 수 있는 방법은 없습니다.

@aaronfranke 음, 하지만 기본 인수가 존재합니다. 0 또는 -1은 길이가 지정되지 않은 것으로 간주될 수 있습니다.

제거해야 get_selected_id() 에서 OptionButton 현재 그것은 항상 -1을 반환한다. https://github.com/godotengine/godot/pull/21837 을 병합한 후 get_selected_id() 는 get_selected() 와 동일한 결과를 반환합니다.

매번 true를 반환하는 많은 트윈 메서드가 있으며 아마도 무효화되어야 합니다.

WindowDialog.get_close_button()
ConfirmationDialog.get_cancel() -> ConfirmationDialog.get_cancel_button()
AcceptDialog.get_ok() -> AcceptDialog.get_ok_button()

Tree 노드에는 get_selected() 함수가 있으며 포커스가 있는 TreeItem을 반환하는 것으로 보입니다. 포커스와 선택은 다른 것이기 때문에 get_active() 와 같이 이름을 바꾸는 것이 좋습니다.

InputMap의 load_from_globals() 는 load_from_project_settings() 이어야 합니다.

더 나은 개요를 제공하기 위해 OP에 통합된 모든 제안에 :tada: 반응을 추가하겠습니다.

global_rotate 는 rotate_global , rotate_object_local 는 rotate_local 로 이름을 바꿔야 일관성이 유지되고 모든 회전 방법이 "회전"으로 시작됩니다.

global_rotate의 이름은 rotate_global로, rotate_object_local은 일관성을 위해 rotate_local로 이름을 변경해야 하며 모든 회전 방법이 "rotate"로 시작하도록 해야 합니다.

글쎄, 다른 한편으로 나는 자동 완성 제안에서 global_position, global_scale 및 global_transform과 같은 전역 관련 함수가 서로 옆에 있다는 것을 좋아합니다. 두 솔루션 모두 IMHO가 의미가 있습니다.

아마도 tree_exiting 는 tree_exited 로 이름을 바꿀 수 있습니다. 지금쯤이면 약간의 혼란을 야기할 것 같습니다. #22840을 참조하십시오.

@groud 이미 tree_exited 시그널이 있는거 맞죠?

@groud 이미 tree_exited 신호가 있죠?

젠장, 당신 말이 맞아. #22840의 요청이 유효한 것 같습니다.

MenuItems.MENU_MAX 는 LineEdit 및 TextEdit 에서 사용되지 않습니다. 제거해야 합니까?

Tabs.ALIGN_MAX https://github.com/godotengine/godot/blob/master/scene/gui/tabs.cpp#L750에 대해 동일

Position3D 및 Position2D 노드는 약간 모호합니다. 설명을 읽지 않고 Spatial 및 Node2D와 비슷하지만 회전이나 크기 조정이 없다고 가정할 수 있습니다. PositionHint 및 PositionHint2D 또는 Gizmo 같은 다른 단어로 이름을 바꿔야 합니다. 편집기에만 있는 기즈모이거나 다음과 같기 때문에 AxisMarker 작은 축 마커.

Gizmo 로 이름을 바꾸면 더 일반적인 용도로 사용할 수 있습니다.

Control 트리의 동일한 노드는 ReferenceRect 이므로 ReferenceAxis/2D 작동할 수 있습니다.

지금 이 문제를 좋아합니다. 나중에 파손이 실제로 발생하면 싫어할 수 있습니다 ;)

겸손한 Array 수업을 위한 몇 가지 제안:

• duplicate → copy 또는 clone . 저는 이 개념을 "복제"라고 부르는 언어를 모릅니다. copy 는 Python 과 C++ 에서 호출되는 것이므로 Godot에게는 자연스러운 선택이 될 것입니다. clone 는 Java 및 JavaScript 에서 가져온 것이며 조금 더 정확할 수 있습니다.
• invert → reverse . 문서에서는 심지어 그것을 "반대"라고 설명하므로 실제로 변명의 여지가 없습니다.
• remove 대 erase 는 혼란스럽습니다. 제안: remove_at 및 remove_value .

마지막 두 개는 모든 Pool*Array 클래스에도 적용됩니다.

참고: 복제 → 복사/복제는 사전에도 적용됩니다.

Rect2 :

• clip → intersection

AABB 에는 intersection 메서드가 있지만 clip 는 없습니다. 클리핑은 일반적으로 btw 클래스에서 구현되지 않은 무언가를 잘라내는 것을 의미합니다. 문서에서는 다음과 같이 설명합니다.

Returns the intersection of this Rect2 and b.

이름을 바꿀 수도 있습니다.

• intersects → overlaps
  실제 intersection 작업과 혼동되지 않도록:

Returns true if the Rect2 overlaps with another.

grabber_area -> slider_progress
slider -> slider_background

겸손한 Array 클래스에 대한 몇 가지 제안:
복제 → 복사 또는 복제.
...
참고: 복제 → 복사/복제는 사전에도 적용됩니다.

및 노드 및 리소스(기본적으로 모든 스크립트 노출 데이터 구조 개체, afaik).

나는 "Clone"이라는 단어를 선호하는데, 그것이 하는 일에 대해 더 명확하다고 생각합니다.

아침! @ akien-MGA 우리는 이름을 바꿀 수없는 instance 에 new 대신 instantiate ? PackedScene 에 Object 와 같은 인터페이스를 사용하는 것은 특히 플러그인 생성을 위한 일부 상용구를 제거하지만 아마도 더 일반적입니다. @willnationsdev 어떻게 생각하세요? 나는 당신이 전에 이것을 겪었다는 것을 알고 있습니다.

이미 어딘가에 이에 대한 이야기가 있었다면 죄송합니다. 훑어봐도 찾을 수 없습니다.

grabber_area -> slider_progress
slider -> slider_background

또는 그냥:
grabber_area -> progress
slider -> background ?

이것이 논의되었는지는 모르겠지만 AnimationPlayer 에는 root_node with set_root & get_root 있으며 아마도 set/get_root_node

CanvasItem.visible 을 CanvasItem.is_visible (및 사용되는 다른 모든 위치)로 바꾸시겠습니까? 모든(또는 대부분, 아마도 내가 놓친) bool 속성과 일치하도록?

이름 바꾸기 Tween.tween_completed 에 Tween.tween_finished ? Animation.animation_finished 처럼? 일반적으로 선호 _finished 이상 _completed ? started/finished 가 started/completed 보다 더 긴밀한 관계를 갖고 있는 것 같습니다. - 경쟁 스포츠에서 편향됨: start/finish - 아마도 :D

JavaScript 클래스 이름을 HTML5 또는 다른 이름으로 바꾸는 것을 고려하십시오.
이 클래스는 단일 메소드를 가지며 Script 에서 확장되지 않으며 다른 플랫폼에서 사용되지 않습니다.

JavaScript 는 향후 JavaScript 언어 바인딩의 클래스 이름으로 사용할 수 있습니다.

@clayjohn이 지적했듯이 CanvasItem 셰이더의 WORLD_MATRIX 는 실제로 모델 뷰 행렬입니다. @reduz 는 4.0에서 이를 실제 모델 및 뷰 매트릭스(예: CANVAS_MATRIX 및 ITEM_MATRIX 대체해야 한다는 데 동의합니다.

이름을 변경 고려 Array.invert 에 Array.reverse . Invert는 거꾸로 또는 "상호" 유형의 것과 비슷합니다. https://docs.godotengine.org/en/latest/classes/class_color.html#class -color-method-inverted 참조

CanvasItem.visibility_changed() 신호를 CanvasItem.visibility_changed(visibility: bool) , 즉. 가시성 상태를 보냅니다. 이것으로 충분할 것이므로 CanvasItem.hide() 신호를 제거하십시오.

Resource::notify_change_to_owners , Resource::{un}register_owner
GridMap 및 CollisionShape에서만 사용되며 나머지 코드는 "changed" 신호를 사용합니다.

Rect2 : has_no_area 이름을 has_area 로 바꿔야 조건문에서 반대를 검사하는 이중 부정 논리를 방지할 수 있습니다. AABB : has_no_surface 에도 동일하게 적용됩니다.

@lupoDharkael이 말한 것을 기반으로 Godot에는 이중 부정이 사용되는 여러 곳이 있습니다. "Condition !Math::is_nan(x) is false"와 같은 오류는 혼란스럽습니다.

parse_input_event(입력 이벤트 이벤트)
게임에 InputEvent를 제공합니다. 코드에서 입력 이벤트를 인위적으로 트리거하는 데 사용할 수 있습니다.

구문 분석이 오해의 소지가 있고 구문 분석이 수신 및 처리되지만 설명은 입력을 보내거나 트리거하는 것을 나타냅니다.

#24153에 따라 - CanvasLayer 는 레이어를 사용하여 노드를 그릴 레이어를 설명합니다. 그러나 거의 모든 다른 2D 노드는 동일한 것을 설명하기 위해 "Z 인덱스"( z_index )라는 용어를 사용합니다. @swarnimarun이 제안한 https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 레이어 이름 개선.

OS.has_feature() / Platform.has_feature()가 OS에 대해 독점적으로 전달하지 않기 때문에 ProjectSettings와 같은 것에서 더 합리적입니까?

set_cell_item은 GridMap과 TileMap을 통합하기 위해 set_cell로 이름을 바꿀 수 있습니까?

set_cell_item은 GridMap과 TileMap을 통합하기 위해 set_cell로 이름을 바꿀 수 있습니까?

생각해 보니 GridMaps에도 set_cellv 가 있어야 하지 않을까요?

ARVR인터페이스:

• ar_is_anchor_detection_enabled -> anchor_detection 또는 유사
• interface_is_initialized -> is_initialized 또는 is_interface_initialized

애니메이션 플레이어:

• play_backwards play 에는 선택적 bool이 있으므로 play_backwards 를 제거할 수 있습니다.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

• disabled 부울을 enabled 부울로 변경합니다.

뼈2D:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards play 에는 선택적 bool이 있으므로 play_backwards 를 제거할 수 있습니다.

적어도 #6866이 구현되지 않는 한 가독성에 좋지 않습니다. 명명된 매개변수를 지원하므로 C#에서는 문제가 되지 않습니다.

id_pressed( int ID ) 및 id_focused( int ID ) ID는 소문자여야 합니다.

^^
그 변경은 실제로 어떤 호환성도 깨뜨리지 않을 것입니다. 아마도 별도의 문제가 발생할 수 있습니다.

^^
그 변경은 실제로 어떤 호환성도 깨뜨리지 않을 것입니다. 아마도 별도의 문제가 발생할 수 있습니다.

좋아요!

28746 - Node.replace_by 는 이름으로 혼동될 수 있습니다. 정확히 무엇이 더 나은 이름이 될 수 있는지 확실하지 않습니다.

@bojidar-bg 아마도 replace_self 또는 swap_by ? 그러나 어떤 종류의 혼란을 피하는 유일한 방법은 적절하게 문서화하는 것이라고 생각합니다.

나는이있는 경우 Node2D 포함 부착 된 스크립트를 class_name MyNode2D 의 get_class() 메소드가 리턴 Node2D 대신 MyNode2D . 이것은 의도적일 수 있지만 혼란스럽고 오해의 소지가 있습니다.

편집: https://github.com/godotengine/godot/issues/26980

@aaronfranke get_native_class() 아마도? 그런 다음 스크립트 이름이 있는 경우 get_script().global_name 에서 스크립트 이름을 가져올 수 있습니다.

make_convex_from_brothers()
형제 노드는 어디에서나 사용되는 단어이기 때문에 "형제"를 "형제"로 변경해야 한다고 생각합니다.

ARVR위치 추적기: get_type() -> get_tracker_type()

• get_tracker_type() 가 더 명시적입니다. - get_type() 가 get_class() 와 혼동될 수 있습니다.

• GetType() 는 여기에 언급된 것처럼 C#에서 이미 다른 용도로 사용되었습니다.

그것은 반환 TrackerType , 또한이 get_hand() 있는 반환 TrackerHand 이 또한 변경 될 수 있도록, get_tracker_hand() 원하는 경우 일관성.

ARVRPositionalTracker 열거형 TrackerHand: TRACKER_LEFT_HAND -> TRACKER_HAND_LEFT (및 오른손). 또는 TRACKER_HAND_UNKNOWN -> TRACKER_UNKNOWN_HAND , 일관성이 있는 한.

Node.NOTIFICATION_TRANSLATION_CHANGED 는 아마도 NOTIFICATION_LOCALE_CHANGED 가 되어야 합니다. "translation"은 "언어"가 아니라 "위치"를 의미하기 위해 공간 노드에서 사용되기 때문입니다.

set_as_toplevel() 는 set_as_top_level() 로 이름을 바꿀 수 있지만 그 동작 을 살펴봐야 합니다 .

이 변경 사항이 중단될 수 있으므로 TouchScreenButton은 4.0에서 확인해야 합니다. https://github.com/godotengine/godot/issues/28814

CanvasItem 방법:

RID get_canvas_item() 상수
VisualServer에서 이 항목에 대해 사용하는 캔버스 항목 RID를 반환합니다.

이름을 get_rid() 로 변경해야 합니다.

get_canvas_item() 는 이미 CanvasItem 노드에 있기 때문에 혼란스럽습니다. 또한 CollisionObject , Resource 와 같은 다른 클래스에 이미 유사한 get_rid() 메서드가 있으므로 일관성을 보장합니다.

Label 을 TextLabel 로 변경해야 합니까? 이제 여러 번 텍스트 개체를 내려 놓고 이름을 잊어버렸기 때문에 "텍스트"를 검색하면 RichTextLabel 나타납니다. TextLabel 는 여전히 텍스트이지만 리치가 없기 때문에 RichTextLabel 와 더 일관성이 있습니다.

참고로 Unity에는 Text 와 TextMesh 있는데 저는 개인적으로 레이블이 아닌 텍스트라고 부릅니다.

Tree 와 GraphNode 가 TreeView 와 GraphEditNode 로 바뀌는 것도 궁금합니다.
Tree 경우 그 이유는 글로벌 GUI 노드 IMO의 이름이 너무 광범위하기 때문입니다. 다른 모든 GUI 프레임워크는 TreeView 합니다.
GraphNode 경우 최근에 실제 그래프 구조와 관련된 몇 가지 프로토타입 작업을 했고 Node 또는 GraphNode 를 사용할 수 없었기 때문에 상당히 성가셨습니다.

@Zylann 그래프 노드는 그래프(트리가 아님)에 대한 시각적/컨트롤이므로 GraphContainer가 더 나을 수 있습니다. GraphNode에 대해 잘 모르겠습니다.

우리는이 있으시면 lerpf / lerpv / lerpc 대신 Color/Vector2/3.linear_interpolate ? 적어도 이름 바꾸기에서 Color/Vector2/3.linear_interpolate 에 Color/Vector2/3.lerp

#29598 http_escape / http_unescape ~ uri_encode / uri_decode 언급된 대로

우리는이 있으시면 lerpf & lerpv 대신 Vector2/3.linear_interpolate ? 적어도 이름 바꾸기에서 Vector2/3.linear_interpolate 에 Vector2/3.lerp

vector.lerp()로 단축하는 것이 좋습니다. 적어도 https://github.com/godotengine/godot/pull/16106 현재 스크립트에서 lerp() 사용에는 벡터와 색상을 지원하는 스위치가 있습니다.

Vector2.angle_to_point() 이름을 바꿔야 합니다. 이름이 현재 설명과 일치하지 않습니다. 좋은 이름이 무엇인지, 이 기능을 유지할 가치가 있는지 확실하지 않습니다.

원호: #16307

@razcore-art 이 https://github.com/godotengine/godot/pull/20371 에 대한 PR이 이미 열려 있으며 이전 버전과의 호환성을 유지합니다(제 생각에는).

편집: 더 이상 없습니다.

Area 는 3D이므로 실제로 Volume 이어야 합니다. 그리고 Area2D 는 Area 이어야 합니다. 영역은 본질적으로 2D입니다.

GridMap 는 CubeMap 이어야 합니다. 이것에 대해서는 확실하지 않지만 "그리드"는 나에게 2D처럼 들립니다.

CheckButton 컨트롤은 SwitchButton 또는 그 이상이어야 합니다. Checkbox 도 있기 때문에 혼란스럽습니다. 아니면 아예 제거해야 할 수도 있습니다. 내가 말할 수있는 한 어쨌든 Checkbox와 동일한 기능을 제공합니다.

나는 다시 동의합니다: CheckButton, 그리고 나머지는 단지 화장품입니다.

아니면 아예 제거해야 할 수도 있습니다. 내가 말할 수있는 한 어쨌든 Checkbox와 동일한 기능을 제공합니다.

UX-wise, CheckBox 및 CheckButton은 동일한 기능을 가지고 있음에도 불구하고 다른 것입니다.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@Rodeo-McCabe Area 는 2D 대응과의 일관성을 위해 그렇게 호출되며 area 의 정의 중 하나는 a particular extent of space or surface 입니다.
큐브맵은 3D 이미지이며 구문 정확성은 컨텍스트에 있어야 하며 그렇지 않으면 혼란을 가중시킬 수 있습니다.

grabber_area -> slider_progress
slider -> slider_background

또는 그냥:
grabber_area -> progress
slider -> background ?

아마도:
grabber_area -> progress_area 또는 progressed_area
slider -> progress_background ?

큐브맵은 3D 이미지이며 구문 정확성은 컨텍스트에 있어야 하며 그렇지 않으면 혼란을 가중시킬 수 있습니다.

@eon-fair 충분히, 나는 그것을 몰랐다.

Area는 2D 대응물과의 일관성을 위해 그렇게 호출됩니다.

문제는 2D 상대 도 일관성이 없다는 것입니다. 수학에서 면적은 길이 * 높이이며 3차원은 없습니다. 따라서 Area2D라고 하는 것은 의미가 없습니다. 영역이기 때문에 2D 여야 하기 때문입니다. "영역"의 또 다른 수학적 정의는 다음과 같습니다.

선 세트 내에 포함된 표면, 구체적으로: 표면과 측정이 동일한 단위 정사각형의 수

마찬가지로 수학에서 3차원 공간을 "볼륨"이라고 합니다. Area가 실제로 3D 노드라는 것을 알았을 때 처음에는 혼란스러웠습니다. 이것은 게임 엔진이기 때문에 수학 정의를 취해야 합니다.

그 이유는 이해하지만 특히 새로운 사람들에게 이름을 변경하면 특별한 이점이 있는지 모르겠습니다. "볼륨"이 이에 대한 더 적절한 용어일 수 있다는 점에는 동의하지만 3D의 경우 "볼륨"과 2D의 경우 "영역"이 약간 혼란스러울 수 있습니다. 결국 2D 및 3D 변형을 모두 가진 많은 노드의 이름이 "

이름 지정 체계가 처음에 존재한다는 것은( 대부분 이 체계에만

그러나 내가 할 수 있다면 Area2D 을 Area , Area 를 Area3D 바꿀 수 있습니까?

편집: <>로 둘러싸인 텍스트는 <>를 이스케이프하지 않는 한 나타나지 않는 것 같습니다.

@Rodeo-McCabe 노드 명명 의도는 수학이 아닌 인간의 언어로 표현하는 것이라는 인상을 받았습니다. 따라서 "영역"은 기하학적 영역이 아니라 레벨이나 스테이지 내부와 같이 존재해야 하는 장소를 의미합니다. IE - 영역 1.

노드 자체는 지오메트리를 직접 가지고 있지 않거나 그 자체가 지오메트리이기 때문에 나와 같은 다른 사람들은 노드를 생성할 때 영역/볼륨이 어디에 있는지 궁금할 것입니다. 그러면 영역과 볼륨(모양)을 영역에 연결하고 용량?

기하학적 영역과 혼동을 피하기 위해 이름을 바꾸려면 동의어를 사용하는 것이 좋습니다.

그들은 다음과 같이 불릴 수 있습니다.

• 지역2D/3D
• 공간2D/3D
• 영역2D/3D
• 필드2D/3D
• 등.

Btw, 이 트래커가 메서드, 속성 및 신호(노드 아님) 전용이라는 점을 제외하고 @reduz 는 최근에 4.0에서 호환성 손상을 최소화하려는 의도가 있다고 언급했습니다. 따라서 이 거대한 목록은 아마도 우리가 계속 추가하기 전에 핵심 개발자의 검토가 필요할 수 있습니다 영원한 것...

지금의 상태를 최대한 유지하는 것이 목표인 것 같으니, 4.0 이후의 다음 메이저 버전까지 이런 일이 미뤄질 수 있을까요?

이 문제는 핵심 기고자에게 남겨주세요. 여기저기서 대대적인 이름 변경을 제안하는 곳이 아닙니다. 목표는 API를 번거롭게 만드는 실제 불일치를 수정하는 것입니다.

OP에 설명된 변경 사항은 큰 호환성 손상이 아니며 대부분은 4.0에서 수행됩니다. @reduz가 언급한 것은 2.1과 3.0 사이의 "프로젝트를 더 이상 열 수 없습니다" 종류의 호환성 손상입니다(훨씬 더 오디오 및 파티클 시스템이 완전히 다시 작성되고 가져오기 시스템이 변경되는 등 당시에 이름이 바뀌는 것보다 변경되었습니다.

4.0에는 약간의 호환성 손상이 있을 것입니다 . 그렇지 않으면 4.0이라고 부르지 않을 것입니다. 장면과 스크립트에서 사용되는 경우 이름이 변경된 속성, 메서드 및 신호가 올바르게 변환되도록 하는 변환기를 사용하면 합리적이고 이식이 쉬울 것입니다. 어떤 경우에도 토론하는 곳이 아닙니다 :)

Control 의 _set_anchor() 시작 부분도 "_"를 삭제해야 합니다.

PopupMenu의 index_pressed(index) 및 id_pressed(id) 는 잘 작동하지만 id_focused 는 실제로 항목의 ID 대신 인덱스 와 함께 내보내집니다.

아직 문제가 없지만 오늘 Akien에게 제안한 후에 ​​목록에 올릴 가치가 있습니다.

ARVRServer를 리팩터링하여 XRServer라고 합니다. VR과 AR을 모두 나타내는 XR이라는 용어는 아직 널리 사용되지 않았습니다. 그리고 아니요, 저는 MRServer를 사용하지 않을 것입니다 ;)

RayCast에 "Enabled" 대신 "Disabled" 속성이 있어야 합니까? CollisionShape에는 기본적으로 false "비활성화됨"이 있습니다(즉, 기본적으로 활성화되어 있음을 의미함). 대조적으로 RayCast의 "Enabled" 속성은 기본적으로 false 이며 기본적으로 비활성화됩니다.

또는 긍정적인 형식(전체적으로 덜 혼란스럽다고 생각함)을 사용하려면 CollisionShape에 "Disabled" 대신 "Enabled" 속성(기본적으로 true )이 있어야 합니까?

@Calinou 별도의 문제가 필요한지 모르겠지만 일관성이 필요하다면 이러한 부울 값이 항상 Enabled 것을 선호합니다. 무언가를 비활성화하기 위해 부울을 true 로 설정하면 자주 혼란스러워집니다.

@Calinou @Zylann 이중 부정은 혼란스럽고 가능하면 피해야 한다는 데 동의합니다. 대신 "Disabled" 부울을 "Enabled" 부울로 변경해야 합니다. 기본값이 "true"이면 괜찮습니다. #17212와 #21822에서 이 토론을 했습니다.

마우스 및 터치 입력 이벤트의 speed 속성은 Vector2이므로 velocity 로 이름을 변경해야 합니다.

InputMap : get_action_list( String action ) 함수 이름은 그것이 하는 일에 대해 많은 것을 말해주지 않습니다.
주어진 작업과 관련된 EventInputs를 반환하므로 get_action_events(String action)

또한 InputMap 에는 get_actions( ) 라는 또 다른 함수가 있고 두 이름 모두 컨텍스트에서 동일한 것을 의미할 수 있으므로 가능한 혼동을 피하는 데 도움이 될 수 있습니다.

접선적으로 #30736과 관련하여 두 개의 Godot 물리 엔진 이름을 "GodotPhysics2D" 및 "GodotPhysics3D"와 같은 것으로 변경해야 합니다. "GodotPhysics"와 무언가가 깨졌다는 것은 두 가지 매우 다른 것을 의미할 수 있기 때문입니다.

어떤 이름 바꾸기에 대한 Object._init() 에 Object._new() ?

get — _get
get_property_list — _get_property_list
notification — _notification
set — _set

new — _init

_init 실제로 Python의 __init__ 따랐고 new 는 인스턴스가 아니라 클래스의 메서드입니다.

String : empty() -> is_empty() 같은 것이 이 스레드에 적합합니까? 항상 처음에는 문자열을 지우는 기능이라고 생각합니다.

@vortexofdoom 메서드 이름 불일치 및/또는 이름 지정 방법에 대해 이야기하는 경우 그렇습니다.

String 및 NodePath 각각 동일한 작업을 수행하는 empty 및 is_empty 메서드가 있다고 추가할 수 있습니다. 나머지 핵심 내장 유형은 empty 이름을 선호하는 것 같으므로 is_empty 이름을 NodePath 로 바꾸어 모든 기본 제공 유형에서 일관되게 만들 수 있습니다. 내 생각에 심각한 호환성 손상이 잠재적으로 포함될 수 있습니다.

항상 처음에는 문자열을 지우는 기능이라고 생각합니다.

대부분의 메소드는 이를 위해 Godot에서 clear 이름을 사용합니다.

@Xrayez ,

대부분의 메소드는 이를 위해 Godot에서 명확한 이름을 사용합니다.

empty 가 형용사인 동시에 동사라는 사실을 언급하고 is_ 하면 어느 것이 의미하는지 명확해집니다.

해당 bool에 대한 모든 내장 기능에서 is_empty 를 사용하는 것이 좋습니다.

Godot 3.0과 3.1에서는 C#에 Set 메소드가 있었습니다. 그러나 이들은 실제로 생성자와 할당을 사용하는 것과 비교하여 실제 기능을 추가하지 않았지만 코드가 자동으로 실패하도록 허용하므로 더 이상 사용되지 않습니다. 그것들은 주로 내가 Quat에 대한 방법이 이미 존재하기 때문에 시도하고 일관성을 유지하기 위해 추가한 것입니다. 자세한 내용은 #30744를 참조하십시오.

GDScript은 가지고 set_euler 및 set_axis_angle 하지만, 같은 일을 (수행하는 생성자도 있습니다 q.set_axis_angle(myvec3, myval) 교체 할 수 있습니다 q = Quat(myvec3, myval) . 코어는 이러한 방법이있다 Basis의 경우 GDScript에 노출되지 않습니다.

문제는 이에 대해 어떻게 해야 합니까? Quat 집합 메서드는 더 이상 사용되지 않고 생성자를 선호하고 C#과 일관성을 유지해야 합니까, 아니면 수행 중인 작업에 대해 명시적으로 유지하는 것이 가치가 있습니까? 후자의 경우 Basis 메소드도 노출되어야 합니까?

@aaronfranke 나는 기본적으로 다른 어떤 것도 하지 않을 때 그 생성자가 전용 메소드를 가지고 있다는 것이 항상 이상하다는 것을 알았다. 그래서 나는 가능하다면 이전 경로를 택한다.

@aaronfranke 이 문제는 엔진 기능이나 버그가 아니라 API의 이름을 바꾸는 것에 관한 것입니다.

Geometry 의 point_is_inside_triangle() 에서 is_point_in_triangle() , 동일한 클래스에서 bool 도 반환하는 다른 메서드와 일치시킵니다.

TreeItem.get_children() 는 get_first_child() 로 이름을 바꿔야 합니다. 문서는 또한 하위 항목을 반환하지 않는다고 설명해야 합니다. 자식은 get_next() 사용하여 반복됩니다.

#31976에서 작업할 때 섀도우 아틀라스 값이 2의 거듭제곱이어야 한다는 것을 알았습니다(방향성 섀도우와 옴니/스팟 섀도우 모두). 그러나 메서드는 모든 정수 값을 허용합니다. 2의 거듭제곱이 아닌 경우 메서드는 가장 가까운 2의 거듭제곱으로 반올림합니다. 값의 열거형을 허용하도록 해야 프로젝트 설정에서 사용자 친화적인 방식으로 표시될 수 있습니다.

마찬가지로 이방성 필터링 수준은 열거형(2×, 4×, 8×, 16×)이어야 합니다. 여기에서는 2의 거듭제곱 값만 의미가 있기 때문입니다.

VisualServer 의 instance_create2() 는 실제로 instance_create() 와 다른 기능을 설명하도록 변경되어야 합니다.

개체 기준 번역의 경우 Spatial 에는 translate_object_local 가 필요한 Vector3 이 있고 Node2D 에는 move_local_x 및 move_local_y , 수레를 사용합니다. Spatial 및 Node2D 에는 각각 Vector3 및 Vector2 사용하는 메서드가 있어야 하고 translate_local 또는 local_translate 는 translate_object_local 보다 간단한 이름이어야 합니다.

@leonkrause render_width 및 render_height viewport_width 및 viewport_height 또는 canvas_width 및 canvas_height , 캔버스 뷰포트에 사용되는 참조 해상도이며 실제로 렌더링에 영향을 미치지 않습니다.

@akien-mga 목록에 트리 탐색 방법을 추가하는 것을 고려하십시오. 그것들은 이름이 매우 혼란스럽고 잘 문서화되지 않았습니다.

처음 만났을 때 get_child() 및 get_next(), get_prev()가 디렉토리가 작동하는 방식처럼 반복자를 작동한다고 생각했습니다. 나는 그들이 하는 모든 것이 호출될 때마다 동일한 포인터를 생성한다는 것을 알아내기 위해 내 자신의 테스트를 수행해야 했습니다.

get_children()은 get_first_child()로 이름을 바꿔야 합니다.

get_next() 및 get_prev()는 get_next_sibling() 및 get_prev_sibling()으로 이름을 변경해야 합니다.

어떤 이름 바꾸기에 대한 Engine.iterations_per_second 에 Engine.physics_fps 프로젝트 설정과 일관성을 위해?

is_processing :

처리가 활성화된 경우 true를 반환합니다.

can_process :

장면 트리가 일시 중지된 동안 노드가 처리할 수 있으면 true를 반환합니다.

이름을 바꿀 수는 더 좋을 수도 can_process 같은 것으로 can_process_paused 로 회피 혼란에 is_processing 방법.

----
String print( Variant value, String indent="", bool sort_keys=false )

이 방법의 이름을 바꿔야 한다고 생각합니다.

@dalexeev 이름을 무엇으로 변경해야 하며 그 이유는 무엇입니까?

@Calinou 이 메서드는 실제로 화면에 아무 것도 인쇄하지 않습니다. 문자열을 반환합니다. 첫 번째 생각은 JSON.print 가 Node.print_tree 또는 OS.print_all_resources 또는 다른 모든 print* 메서드처럼 작동한다는 것입니다.

이름을 무엇으로 바꿔야 할까요? 잘 모르겠어. JavaScript는 이를 위해 JSON.stringify 를 사용합니다. PHP에는 json_encode 기능이 있습니다. GDScript에는 to_json 와 같은 유사한 기능이 있습니다.

UPD. JSON.serialize 도 가능하지만 문자 수로 보면 JSON.stringify 와 동일합니다. :웃다:

일반적으로 이진 직렬화에 사용되기 때문에 "직렬화"라는 단어에 반대하는 것이 좋습니다. 이러한 출력은 해당 형식을 얻기 위한 추가 단계가 필요합니다.

이 클래스에는 JSON과 Variant 유형 사이를 이동하는 두 가지 방법만 있으므로 무의미하므로 json 라는 단어를 포함하는 방법에 대해 제안합니다.

자, 좋은 이름 이 될 것들에 대해, 기존의 parse 메소드에는 실제로 명확한 반대 단어가 없습니다( 여기 참조 ). encode , create , compose , generate ? encode 가 사용되면 다른 메서드의 이름을 decode 로 바꾸는 것이 좋습니다.

format 및 write 가 parse 의 역수로 사용되는 것을 보았습니다. stringify 는 JavaScript에서 사용되기 때문에 개발자들 사이에서 더 잘 알려진 이점이 있습니다.

format 및 write 가 parse 의 역수로 사용되는 것을 보았습니다. stringify 는 JavaScript에서 사용되기 때문에 개발자들 사이에서 더 잘 알려진 이점이 있습니다.

str2var 는 VariantParser 이고 var2str 는 내부적으로 VariantWriter (예를 들어 #33241 참조, 동일한 용어를 사용하여 설명했습니다).

그래서 저는 write . 일관성이 이깁니다. 😛

@Xrayez print 을 write ? 파이썬에서 파스칼로? :웃음:

https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552에서 제안한 것처럼 clear_color 와 관련된 모든 이름을 background_color ( 프로젝트 설정).

나는 4.0이 더 나은 성능, GI 프로브 개선, 일반적인 과대 광고 등으로 인해 Godot에 새로운 사람들의 큰 물결을 가져올 것으로 예상합니다.

4.0에서 이러한 변경이 이루어지면 공식 "첫 번째 게임" 튜토리얼 외에는 거의 모든 기존 튜토리얼이 더 이상 작동하지 않기 때문에 이 사람들은 하드 랜딩을 받게 될 것입니다.

4.0 이후에 이러한 변경이 이루어지면 4.1에서와 같이 그 사람들에게 매우 울퉁불퉁한 일이 될 것입니다. 그들은 새로운 엔진의 기초를 방금 배웠습니다. 이제 다시 배워야 합니다. 시작은 어렵습니다. 이 과정을 너무 빨리 두 번 반복해야 하면 완전히 포기할 정도로 좌절할 수 있습니다.

따라서 API 변경과 호환성을 깨는 모든 변경 사항이 있는 "3.3" 또는 "3.9" 버전을 4.0 릴리스 이전에 사용하는 것이 말이 되지 않겠습니까?

이것이 올바른 장소인지 아닌지 확실하지 않지만 이것이 문제 이름 바꾸기에 대한 가능한 부분적인 해결책이 될 수 있기 때문에 여기에 설명하겠습니다.
필요한 모든 이름 바꾸기 변경을 수행한 다음 모든 변경에 대한 모든 이전 이름이 있는 GodotOldNames/GodotPre4.0이라는 번역에 새 언어를 추가하지 않겠습니까?
이렇게 하면 누군가가 이전 튜토리얼에 있는 이전 이름을 찾지 못한 경우 GodotPre4.0 으로 언어를 변경할 수 있습니다. 이렇게 하면 새 이름으로 더 쉽게 전환할 수도 있습니다.
이것은 전체 문제를 해결하지 못하지만 #4397과 함께 작동할 수 있습니다.

@Anutrix 이것은 많은 복잡성을 추가합니다(영어가 아닌 언어는 어떻습니까?). 또한 편집기에 표시되는 모든 문자열을 처음부터 현지화할 수 있는 것은 아닙니다.

물리학 " 레이어 ", 렌더링 " 레이어 "

나는 Godot를 배운 첫 몇 주 동안 이 불쌍한 사람 과 똑같은 혼란을 겪었던 것을 기억합니다.

물리학 "레이어", 렌더 "레이어"는 Object Orientated Design에서 온 누군가에게는 의미가 있을 수 있지만 다른 누군가에게는 매우 혼란스럽습니다. "레이어"라는 용어는 페인트의 다중 코팅 또는 직물의 천 코트, 양파(또는 오우거)의 피부 코트, 행성 표면의 퇴적물 코트, ...
레이어(단일 레이어와 반대되는 복수형)는 이러한 모든 경우에 서로 겹쳐져 있음을 의미하는 것 같습니다.

많은 사람들에게 특히 2D 그래픽이나 애니메이션으로 작업할 때 "레이어링"한다는 것은 전경, 배경 및 그 사이 또는 상단에 있는 레이어로 작업하는 것을 의미합니다. 많은 사람들이 레이어를 배경 위의 셀롤로이드 필름으로 생각합니다. 사실 Godot는 다른 많은 게임 엔진과 마찬가지로 이 작업을 수행하기 위해 다양한 "정렬" 방법을 사용합니다.

Physics 개체 또는 Render 개체가 "레이어"를 공유할 수 있는 추상적인 공통점을 호출하지만 동시에 이러한 추상적인 공통점은 시각적 레이어의 스택 모양("정렬")과 아무 관련이 없다는 사실이 이것을 만드는 이유입니다. 일부 사람들에게 너무 혼란스럽습니다.

Physics "Layer", Render "Layer"의 실제 용도와 의미를 이해했을 때 나는 즉시 이것이 Physics Group, Render Group이 아닌 이유가 무엇인지 궁금했습니다. 그것들은 확실히 서로에 대한 어떤 ontop-stackable 관계도 없습니다. 즉, 서로의 순서나 관계가 완전히 관련이 없음을 의미합니다. 레이어 이름을 지정하면 imho는 혼란스러운 사람들, "그룹", 마스크에 대한 "그룹의 영향을 받는" 또는 지금 당장 생각할 수 없는 다른 용어가 더 정확할 것입니다.

AnimationPlayer 메서드
.stop(false) 은 .pause(true) 로 호출되어야 합니다.
그것이 그것이 하는 일이기 때문입니다.

프로젝트 > 프로젝트 설정 > 디스플레이 > 창 > 늘이기 > 모드:

스트레치 모드 "2D" 는 스트레치 모드 "디스플레이" 또는 "범용" 이라고 해야 합니다.
3D 사용 사례에서 잘 작동하지만 모든 2D 사용 사례(픽셀아트 프로젝트와 같은, Godot 2D 프로젝트의 거의 절반이 픽셀아트인 것처럼 보임)에 대해서는 잘 작동하지 않을 때 2D라고 부르는 것이 혼란스럽기 때문입니다.
"디스플레이"는 또한 그것이 실제로 하는 일에 대해 더 설명적일 것입니다. 디스플레이 해상도에서 2D 그래픽, 3D 개체, 2D 메쉬, Line2D 및 다각형이 되는 모든 그래픽을 렌더링합니다.
여기에서 자세히 알아

애니메이션 플레이어, 타이머 및 유사한 노드의 루프, 반복, 원샷이 명확해질 수 있습니다.

반복하고, 반복하고, 일회성이 아닌 것은 모두 같은 것입니다.

내 생각에는
is_a_parent_of()
로 이름을 바꿔야 합니다.
is_parent_of()

@KoBeWi 는 #19801에서 토론을 참조하십시오.

내 생각에는
is_a_parent_of()
로 이름을 바꿔야 합니다.
is_parent_of()

그렇게 생각하지 않습니다. is_parent_of()는 첫 번째 부모만 고려한다고 제안하는 반면 함수는 모든 부모를 재귀적으로 확인합니다.

@groud 이 경우 is_ancestor_of() 라고 해야 합니다. 반대의 경우에도 해당 함수가 있으면 is_descendant_of() 라고 해야 합니다.

@groud 이 경우 is_ancestor_of()라고 해야 합니다. 반대의 경우에도 해당하는 함수가 있으면 is_descendant_of()라고 해야 합니다.

예, 하지만 생각해보면 두 기능을 모두 가질 필요는 많지 않습니다. 차이점은 "호출" 객체와 함수 인수를 전환하는 문제일 뿐입니다. 함수를 is_descendant_of() 와 같은 것으로 간단히 대체할 수 있으며 완료되었습니다.

push_error() 및 push_warning() 을 각각 print_error() 및 print_warning() 로 변경할 수 있습니다. 이렇게 하면 자동 완성 기능 덕분에 더 쉽게 검색할 수 있습니다. :slightly_smiling_face:

@Calinou print_error() 는 printerr() 와 혼동될 수 있습니다.

TreeItem.get_children() 메서드의 이름을 변경하는 것을 고려하십시오. 이름이 반환 값이 될 자식 컬렉션을 의미하므로 실제로 반환되는 첫 번째 자식이고 나머지 항목을 반복해야 할 때 get_next() (#19796에 설명됨).

# 31404 에서

[ rpc() / rset() 로 이름 변경] remote_call() / remote_set() ?
이러한 메서드에는 별칭이 충분한지 확실하지 않은 매우 짧은 이름도 있습니다. 3자 식별자를 정당화하기 위해 스크립트당 이러한 수많은 호출로 멀티플레이어를 정말 많이 해야 합니다(대부분의 게임이 그렇지 않다고 확신합니다).

편집(2020-01-03): 다시 생각해보면 call_deferred() 및 set_deferred() 가 이미 있으므로 call_remote() 및 set_remote() 가 더 합리적일 수 있습니다.

편집: 아래 닫기/다시 열기에 신경 쓰지 마세요. 너무 빨리 클릭했습니다.

다음 방법

OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

메서드와의 일관성을 위해 OS 클래스에서 Input 클래스로 이동해야 합니다.

Input.get_joy_axis_index_from_string
Input.get_joy_axis_string
Input.get_joy_button_index_from_string
Input.get_joy_button_string

TabContainer 는 tab_close 및 tab_hover 신호도 편집해야 합니다.

• LightOccluder2D light_mask -> occluder_light_mask
• CPU파티클 Flags 열거형 -> ParticleFlags
• ARVR위치 추적기 get_type -> get_tracker_type
• ARVR위치 추적기 get_name -> get_tracker_name
• PathFollow2D rotate -> 다른 것
• ArrayMesh ArrayType enum -> 삭제
• Mesh BlendShapeMode enum -> ArrayMesh에 제공

https://github.com/godotengine/godot/issues/15763#issuecomment -568908661의 설명

RichTextLabel의 meta_hover_started 및 meta_hover_ended 신호는 meta_hover_entered 및 meta_hover_exited 대부분의 유사한 명명 규칙과 일치하도록 이름을 바꿔야 합니다. 이것은 나머지 Godot API를 더 밀접하게 모방할 뿐만 아니라 알파벳 정렬로 인해 현재 명명 체계로 인해 순서가 반대로 됩니다. 문서를 읽을 때 방향이 약간 혼란스러울 수 있습니다. 작업의 시간적 흐름이 먼저 입력 한 다음 종료하는 것이기 때문입니다. 그것은 단지 그것을 변경하기 위해 가독성과 일관성을 향상시킵니다.

Texture.size 속성이 없다는 것을 알았습니다. 대신 Texture.get_size() getter를 호출해야 했습니다.

의도한 것인지 아닌지에 대해 Discord에서 물었습니다. 한 가지 제안은 이것이 속성으로 변환되어야 하는지 묻는 질문을 여기에 게시하는 것이었고, 다른 제안은 이에 대한 '세터'가 없기 때문에 get_size()를 사용하는 것이 현재 예상되는 동작이라는 것입니다.

@jmbjr (게터 메서드 대신) 속성으로 노출된 읽기 전용 속성이 있습니까? 읽기 전용 속성을 설정하려고 할 때 기본 제공 오류 처리기를 본 기억이 있습니다. 처음에 GDScript에 노출되었는지 확실하지 않습니다.

예, 읽기 전용 노출 속성을 지원하기 시작하려면 이에 대한 USAGE 플래그가 필요하고 이를 지원하는 GDScript 파서/컴파일러 코드도 추가해야 한다고 생각합니다.

SoftBody 에는 areaAngular_stiffness 가 있으며 area_angular_stiffness 여야 합니다(모든 관련 메서드에 대해 동일).

Input.joy_connection_changed (메소드)는 스크립팅 API에 노출되어서는 안 될 것 같으며, 각 플랫폼의 조이스틱 처리 코드에 의해 내부적으로 호출됩니다.

@akien-mga 그 방법을 처음 보았을 때 Godot를 발견한 직후에 비슷한 생각을 했습니다. 그리고 나서 Kojima가 MetalGearSolid에서 이것과 매우 유사했을 방법을 중심으로 전설적인 게임 플레이를 구축한 방법을 기억하고 생각했습니다. " Godot는 코드 한 줄로 고지마처럼 네 번째 벽을 부술 수 있는 수단까지 제공하는데, 정말 대단해!"

Label 및 RichTextLabel 에 일관성 없는 테마 속성이 있습니다.

Label:
int line_spacing [default: 3]
Color font_color [default: Color( 1, 1, 1, 1 )]

RTL:
int line_separation [default: 1]
Color default_color [default: Color( 1, 1, 1, 1 )]

또한 기본값이 다르기 때문에 같은 글꼴이라도 Label 와 RichTextLabel 에서 높이가 다릅니다.

TextEdit의 request_completion 신호는 과거 시제를 사용하기 위해 completion_requested 로 이름을 바꿀 수 있습니다. 현재 버전은 신호의 callback-y 특성과 달리 다소 필수적으로 들립니다.

물리적 신체 신호와의 또 다른 불일치

지역:

area_shape_entered( int area_id, 면적 면적, int area_shape, int self_shape )
area_shape_exited( int area_id, 면적 면적, int area_shape, int self_shape )
body_shape_entered( int body_id, 노드 바디, int body_shape, int area_shape )
body_shape_exited( int body_id, 노드 바디, int body_shape, int area_shape )

나는 이 마지막 두 개의 area_shape가 self_shape이어야 한다고 생각합니까? 또는 ...

강체:

body_shape_entered( int body_id, 노드 바디, int body_shape, int local_shape )
body_shape_exited( int body_id, 노드 바디, int body_shape, int local_shape )

여기서는 local_shape라고 합니다...

@FrederickDesimpel 내가 아는 한, 인수는 호환성을 손상시키지 않고 이름을 바꿀 수 있습니다. 이에 대한 풀 리퀘스트를 자유롭게 여십시오 :slightly_smiling_face:

변형:

실수 -> 부동
0 -> NULL?

저는 개인적으로 "실제" 이름을 좋아합니다. "float"라는 용어는 특히 32비트 부동 소수점에 자주 사용되지만 Variant의 실수는 double이고 대부분의 엔진은 둘 중 하나일 수 있는 real_t 를 사용합니다.

추신: 우리는 이미 2017년에 다른 방식으로 이름을 변경했습니다.

우리는 이것들의 이름을 바꾸는 것을 고려 했습니까?
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial은 이미 마스터에서 StandardMaterial3D로 이름이 변경되었습니다.

해야 limit_ 에 값 Camera2D A를 변경 Rect2i ? 지금은 단지 4개의 정수입니다.

편집: 드래그 여백을 Rect2 로 변경할 수도 있습니다.

String::begins_with ~ String::starts_with .

진지한 프로그래밍 언어(Java, Python 등)에서처럼.

InputEvent.is_action_pressed to InputEvent.is_action_just_pressed
InputEvent.is_action_released to InputEvent.is_action_just_released

https://github.com/godotengine/godot-proposals/issues/316#issuecomment -589426014

"just"라는 단어가 누락되었지만 event.is_action_...()은 Input.is_action_just...()에 해당합니다.

Node.add_child_below_node() 의 처음 두 인수를 바꿔서 첫 번째 인수가 Node.add_child() 와 같도록 해야 합니다. #19642를 참조하십시오.

_의미론적 공포증 말하기..._

Node2D.draw_circle 는 원이 아닌 디스크를 그리므로 Node2D.draw_disk Node2D.draw_circle 여야 합니까?
Node2D.draw_circle 는 0 에서 TAU 까지 0 draw_arc 대한 바로 가기로 계속 존재할 수 있습니다.

@Goutte 영어에서 "circle"은 속이 빈 원이나 채워진 원을 가리킬 수 있습니다. 현재 이름이 더 검색 가능하다고 생각하므로 변경하지 않겠습니다.

영어에서 "circle"은 속이 빈 원 또는 채워진 원을 나타낼 수 있습니다.

찾을 수없는 아무것도 지원 이 . 이 주장에 대한 출처가 있습니까 아니면 직감입니까?

검색 가능성에 관해서는 여전히 draw_circle 가 있을 수 있으며 디스크가 아닌 단순히 원을 그립니다.

찾을 수없는 아무것도 지원 이 . 이 주장에 대한 출처가 있습니까 아니면 직감입니까?

https://www.merriam-webster.com/dictionary/circle

1b: 닫힌 평면(평면 항목 6의 의미 2b 참조) 곡선 내의 고정된 점에서 모든 점이 등거리(등거리의 의미 1 참조)에 있는 곡선
1c : 이러한 곡선으로 둘러싸인 평면

(1b)는 수학적인 원(둘레), (1c)는 수학적인 원반(표면)입니다.

API 측면에서 보면 draw_rect() , draw_filled_rect() , draw_circle() 및 draw_disk() 보다 draw_rect(bool filled) 및 draw_circle(bool filled) 가 있는 것이 IMO보다 사용자 친화적입니다 draw_disk() (또는 채워진 직사각형의 수학적 이름은 무엇입니까?).

편집: 실제로 draw_circle() 에는 아직 filled 인수가 없습니다. 원(주변)과 원반(채워진 원)을 모두 그리는 데 사용할 수 있도록 하나를 추가해야 한다고 생각합니다.

좋아요. 감사합니다. 대부분의 제 학생들은 프랑스인이고 그들 모두가 이것 때문에 혼란스러워했고 저 역시 마찬가지였습니다. 그들은 Godot를 비난했고 저는 당연히 그들을 놔둘 수 없었습니다.

채워진 직사각형의 수학적 이름은 무엇입니까?

꽤 좋은 질문입니다. 내가 찾을 수 있는 것은 "사각형 영역" 또는 "사각형 내부"뿐이며 어느 것도 적절하지 않습니다. Wiki는 심지어 대부분의 사람들이 _polygon_이라는 용어를 다른 단어를 제공하지 않고 _폴리곤의 내부_를 의미하는 것으로 남용한다고 명시하고 있습니다.

filled 인수가 모호성을 완화하는 데 도움이 될 수 있지만 인수 목록에 넣을 위치를 결정하는 것은 고통스러울 것입니다.

@Goutte 그러나 인수 목록에 넣을 위치를 결정하는 것은 고통스러울 것입니다.

선택적 인수(기본값이 있음)이고 draw_rect 와의 일관성을 위해 끝에 가야 합니다.

제어 노드를 모달 노드라고 하는 경우가 있습니다. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal 대부분 Viewport.get_modal_stack_top() 함수와 관련하여

EditorInterface 의 get_selected_path 및 get_current_path 메서드는 이름과 기능면에서 혼동을 줍니다. 그들은 또한 문서가 부족합니다.

이 메서드는 같은 이름의 FileSystemDock 메서드 위에 있는 얇은 레이어일 뿐입니다.

String FileSystemDock::get_selected_path() const {
    if (path.ends_with("/"))
        return path;
    else
        return path.get_base_dir();
}

String FileSystemDock::get_current_path() const {
    return path;
}

둘 다 하나는 get_*_path 이고 다른 하나는 get_*_dir "선택됨" 또는 "현재"(또는 둘 다에 대해 다른 것)를 적용해야 합니다.

@Goutte 채워진 직사각형의 대안이 솔리드 직사각형이 아닙니까?

2019년 6월 이후에 게시된 제안으로 OP가 업데이트됩니까? 이것이 많은 작업이라는 것을 이해하지만 이러한 유형의 추적기는 기여자가 함께 해결하기에 완벽합니다. 그리고 우리가 더 많은 것들의 이름을 바꾸는 작업을 할 수 있는 때가 이미 온 것 같은데요?

OP를 업데이트한다는 것은 게시된 제안이 팀에서 가치 있는 것으로 받아들인다는 의미이기도 합니다.

@Anutrix "채워진"은 "고체"보다 사용하기에 더 좋은 단어입니다. "고체"는 "액체나 기체가 아님"을 의미할 수 있기 때문입니다.

@pycbouh 문제가 있는 경우 각 문제에 대한 PR을 연결하는 것도 좋은 생각입니다. OP는 이미 이것을 수행하지만 그 아래의 주석에는 적용되지 않습니다.

제기되었는지는 모르겠지만 이 문서에 대해 문서를 엿보기 위해 얼마나 자주 멈추는지 몰랐습니다.

• Array.remove => remove_at (예: C#) 인덱스로 제거
• Array.erase => remove_value 또는 remove (C#처럼) 값으로 제거

(또는 erase 변형)

왜냐하면 지금 erase 와 remove 는 하나는 인덱스에 의한 것이고 다른 하나는 값에 의한 것이라는 점을 제외하고는 나에게 동일하게 의미합니다.

이미 자랐어, 내 나쁜. 눈치채지 못했는데, Github이 스레드를 접고 있는데, 내 Ctrl+F 검색이 그것을 놓쳤습니다 xD
아직 OP에 없음

@Zylann 여기 있습니다: https://github.com/godotengine/godot/issues/16863#issuecomment -441376010

Zylann을 두 번째로, 제거가 색인에 의한 것임을 계속 잊고 있습니다...

ButtonList 열거형은 마우스 버튼이므로 MouseButtonList 로 이름을 바꿔야 합니다.

JoystickList 열거형을 분할해야 합니까? 여기에는 버튼과 축이 모두 포함되어 있으며 JoypadButtonList 및 JoypadAxisList 또는 이와 유사한 것으로 더 합리적일 수 있습니다.

그냥 질문입니다. MouseButton 아닌 이유는 무엇입니까?
버튼 == MouseButton.LEFT인 경우:
보다 잘 읽힌다
버튼 == MouseButtonList.LEFT인 경우:

좋은 생각. 이 경우 KeyList -> Key , MidiMessageList -> MidiMessage 도 있고 조이스틱은 List 제거해야 합니다. .

나는 몇 가지 방법은 / 속성을 사용났습니다 normal_map 다른 사람이 사용하는 반면, normalmap . 우리는 이 중 하나를 해결해야 하지만 둘 다 아닐 수도 있습니다. 나는 normal_map 선호하지만 normalmap 도 괜찮습니다.

GD스크립트

range_lerp() = 지도()
시드 = set_seed()

map()은 아마도 새로운 기능적 프로그래밍 기능을 위해 예약되어 있을 것입니다.

Vector2.tangent() 는 문서에서 Returns a perpendicular vector. 로 설명됩니다. 반환된 벡터가 정규화되면 orthogonal 또는 orthonormal 의 정의입니다. 때문에 Vector2.tangent() 반환 내가 제안이 아닌 정규화 된 벡터는 우리로 이름을 변경한다 Vector2.orthogonal() 또는 Vector2.perpendicular() 사람들이 아마도 수학 용어에 대한 뭔가 이상이있는 경우에도 Vector2.normal() , 하지만 사람들은 normalized() 와 normal() 사이를 혼동할 수 있습니다.

내 말에 일화지만, 이것을 처음으로 찾았을 때 문서에서 나의 첫 번째 검색은 _perpendicular_에 대한 것이었습니다.

.tangent() 를 .perpendicular() 의 별칭으로 유지할 수도 있습니다. 아니요?

orthogonal 라는 이름은 다른 사람들에 비해 흔한 영어 단어가 아니기 때문에 마음에 들지 않습니다. 전에는 tangent 문제가 있는 것을 보지 못했지만 어쨌든 perpendicular 가 더 나은 이름이라고 생각합니다.

예, 직교는 드뭅니다. 나는 .perpendicular()에 투표하지만 compat에 대한 tangent() 별칭을 유지하고 더 짧습니다.

@Zireael07 접선을 구하는 방법이 한

내 procgen 스크립트에서 내가 얼마나 자주 그것을 사용하는지 당신은 놀랄 것입니다 :)

이것이 논쟁을 불러일으킬 줄은 몰랐지만 개인적으로 Vector2.tangent() 를 유지하는 것은 일반적인 수학 용어의 잘못된 사용이기 때문에 반대합니다. Vector2.tangent() 의 곱은 정의상 잘못된 것입니다. 이 스레드의 이름은 다음에 계획된 호환성 중단이므로 호환성을 유지하기 위해 뒤로 구부려야 할 이유가 없습니다. 저는 개인적으로 Vector2.perpendicular() 좋습니다.

제안: find_node() 의 owner 매개변수를 기본적으로 false로 설정합니다.

제안: "선택됨", "집중됨" 및 "없음"의 용어/상태와 관련하여 혼동을 줄이기 위해 Tree 의 메서드/신호 이름을 변경합니다.

Tree::ensure_cursor_is_visible 은 오해의 소지가 있고 ensure_focused_item_visible 또는 ensure_selected_item_visible 와 같이 이름을 바꿔야 한다고 생각합니다.

클래스 참조조차도 다음과 같이 말합니다.

Makes the currently focused cell visible.

This will scroll the tree if necessary. In SELECT_ROW mode, this will not do horizontal scrolling, as all the cells in the selected row is focused logically.

Note: Despite the name of this method, the focus cursor itself is only visible in SELECT_MULTI mode.

Script::get_instance_base_type() 특히 아래의 기본 유형을 반환합니다. 스크립트 클래스의 이름을 지정했으므로 스크립트의 "기본"이 잠재적으로 스크립트의 이름이 될 수 있으므로 get_native_type() 로 이름을 바꾸는 것이 더 합리적입니다. 오해의 소지가 있습니다.

@willnationsdev get_class() https://github.com/godotengine/godot/issues/16863#issuecomment -491421079

@aaronfranke 글쎄요, get_class() 는 "내가 현재 보고 있는 것의 이름이 무엇입니까?"를 나타내는 데 보편적으로 사용됩니다. 따라서 Script 경우 "GDScript" , "CSharpScript" 또는 이와 유사한 것을 다시 받을 것으로 예상합니다. 하지만 예, Script 가 아닌 클래스의 경우 이름이 지정된 경우 실제 스크립트 클래스의 이름을 반환하는 메서드여야 합니다. 그것에 대한 전용 문제도 있습니다. https://github.com/godotengine/godot/issues/21789#issuecomment -618588900

편집: 오, 제 생각에는 get_class() , get_base_class() 및 get_native_class() 가 있는 경우 get_instance_native_class() 가 되기 위해서는 get_instance_base_type() 가 정말 필요합니다. 명명 규칙을 유지하고 스크립트 정보가 아니라 인스턴스임을 명확히 하십시오.

내 생각 autotile_coord (프로퍼티와 메소드)의 TileMap 위해 이름을 변경해야합니다 tile_coord 또는 tile_coordinate 모두 있기 때문에 AUTO_TILE 및 ATLAS_TILE 는 이것을 사용하고 이름은 새로운 사용자에게 혼동을 줄 수 있습니다. 문서도 업데이트가 필요합니다. 문제가 없으면 이 변경을 수행할 수 있습니다.

LineEdit.text 와 동일한 동작을 하므로 LineEdit.text_changed 에서 new_text 인수를 제거하는 것이 좋습니다.

또한 old_text 에 추가하거나 new_text 대신 old_text 를 추가하는 것을 고려하십시오.

https://github.com/godotengine/godot/issues/16863#issuecomment -394745886 관련

"충돌 레이어 ", "VisualInstance 레이어 ", "렌더 레이어 " 등의 이름을 다음으로 변경합니다.
"충돌 그룹 ", "VisualInstance 그룹 ", "렌더 그룹 ", "라이트 그룹 "

왜 그 "레이어"가 쌓이지 않는지에 대한 혼란은 커뮤니티 채널에 미세한 시계처럼 나타납니다.

Maya, Lumberyard 및 Unity에서는 레이어라고 합니다.

다른 사람이 무언가를 한다고 해서 그것이 여전히 원인이 되지 않는다는 것을 의미하지는 않습니다
혼란스럽고 좋은 생각입니다.

2020년 5월 18일 월요일 오후 1:09 Jummit [email protected]이(가) 작성했습니다.

Maya, Lumberyard 및 Unity에서는 레이어라고 합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

아직 아무도 언급하지 않은 것이 놀랍습니다.
Camera2D.zoom
확대/축소가 더 크면 카메라가 축소됩니다. 이는 "확대"가 작동하는 방식이 아니며 직관적이지 않습니다. view_scale 또는 이와 유사한 이름으로 이름을 바꾸는 것이 확실하지 않습니다.

@KoBeWi zoom 의 이름을 바꾸는 대신 값을 늘릴 때 확대되도록 스케일을 반전시켜야 하지 않을까요?

이렇게 하면 속성 이름을 바꾸는 것과 마찬가지로 호환성이 깨집니다. "역척도" 경로로 가면 불행히도 자동으로 고칠 수 없습니다. 그래도 장기적으로 혼란이 덜할 수 있습니다.

@Calinou @KoBeWi 이 확대/축소 속성을 직접 사용하는 유스 케이스가 있습니까, 아니면 모든 사람이 스케일에 적용하기 위해 매번 반전해야 합니까?

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ?

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ?

그럴 수도 있지만 Node2D.get_position_2d() 와 같은 선을 어디에 그

클래스 이름을 Viewport2D로 지정할 수 있지만 Viewport3D를 만들지 않는 한 필요하지 않습니다.

@nathanfranke Transform 의 2가지 유형이 있는 것을 고려할 때 이름만으로는 2D인지 3D인지 알 수 없기 때문에 이 방법을 제안했습니다. (다른 회원이 이미 canvas_ 또는 mouse_ 가지고 있는 동안)

@Zylann 이 방법은 실제로 정말 이상합니다. 라는 속성이 있습니다 canvas_transform 및 global_canvas_transform , 그리고 설명 canvas_transform 이있다 :

모든 자식 CanvasItem의 화면 위치를 변경하는 데 유용한 뷰포트의 캔버스 변환입니다. 이것은 뷰포트의 전역 캔버스 변환에 상대적입니다.

따라서 get_final_transform 가 이 두 변환을 모두 결합할 것으로 예상할 수 있습니다. 그러나 코드를 보면 실제로는 그렇지 않습니다.

이에 대한 코드는 return stretch_transform * global_canvas_transform; 입니다. 나는 stretch_transform 가 무엇을 위한 것인지 알아내려고 노력했지만 전혀 모르고, 노출되지 않았으며 canvas_transform 변경할 때 확실히 설정되지 않았습니다. stretch_transform 사용하지 않는 _stretch_transform 라는 메소드도 있습니다. 그것은으로 불리는 set_size 에 의해 생성 된 값 소요, _stretch_transform 와에 할당을 stretch_transform . canvas_transform_override 도 있습니다. 언급하지도 않았고 노출되지도 않았지만 내부적으로 사용됩니다.

결국 이 수업 전체를 살펴봐야 한다고 생각합니다. 뷰포트에는 4개의 다른 Transform2D 멤버, 4개의 Rect2(i) 멤버, 9개의 Vector2(i) 멤버 및 2개의 Transform(3D) 멤버가 있습니다. 그것은 변환 정보를 저장하는 데이터 구조의 이미 264바이트(단정밀도 부동 소수점 포함)입니다. 모든 포인터를 더하면 아마도 1KB에 더 가깝습니다. Viewport가 이 모든 것을 필요로 할 수도 있지만 지나치게 복잡해 보이고 최소한 주석이 있어야 합니다(이 파일에는 너무 적음).

Node2D/Node3D to_global 및 to_local 를 제거해야 합니까? 저는 #38902에 기초로만 작동하는 방법을 추가하자는 피드백을 주었지만 여기에는 몇 가지 문제가 있습니다.

데모 프로젝트에서 to_local 는 어디에도 사용되지 않으며 $ grep -RIn "to_global" 는 5개의 결과만 반환하며 모두 3D 데모의 GUI에 있으며 다음을 변경하여 데모의 성능을 향상시킬 수 있습니다. 이 때문에 글로벌 변환 캐시 및 사용 xform 를 사용하는 대신 to_global .

간단히 말해서, 이러한 방법에 대한 우려는 일반적으로 사용되지 않는다는 것과 전역 변환을 여러 번 다시 계산하기 때문에 성능이 좋지 않은 코드 작성을 권장한다는 것입니다.

27509

AnimationPlayer 의 animation_started 및 animation_finished 는 다소 직관적이지 않습니다. 첫 번째는 대기열의 모든 애니메이션에 대해 호출되고 후자는 대기열의 맨 끝에 도달할 때만 호출됩니다. 문서에 명확하게 언급되어 있지 않습니다.

특정 애니메이션이 언제 끝나는지 감지하려면 animation_changed 와 animation_finished 를 모두 사용해야 하므로 편리하지 않습니다.

나는 그 문제에서 @txigreman 의 제안을 정말 좋아합니다. 대기열의 단일 애니메이션이 끝날 때마다 animation_finished 하고 새 신호 animation_all_finished 추가할 수 있습니다( Tween '와 유사). s tween_all_completed ) 대기열의 끝에 도달할 때만 실행됩니다.

animation_queue_finished 및/또는 animation_queue_started 어떻습니까?

여기에서 찾을 수 없으므로 제안합니다.
find 및 findn 쌍.

3.2 마지막 안정적인 빌드의 이미지.

대소문자를 구분하는 특성을 언급하기 위해 이름을 바꿀 수 있습니다.

말, find_ignorecase 대신 findn ?

@swarnimarun n 끝나는 대소문자를 구분하지 않는 메서드가 많이 있습니다. 그 중 하나의 이름을 바꾸면 모두 이름을 바꿔야 합니다.

이러한 방법( find / findn 등)은 기본적으로 동일합니다. 대소문자를 구분해야 하는지 여부에 대한 인수를 추가할 수 있습니다.

@Calinou 저는 GDScript를 몇 달 동안 삭제한 후 사용하는 것이 API에 대한 새로운 관점을 제공한다고 말하고 싶습니다.

더 명확할수록 좋습니다. 모든 것에 대한 API를 기억하는 것은 그 자체로 어렵습니다. 함수 이름에 좀 더 장황한 것은 정상적인 변경처럼 보입니다.

@KoBeWi 는 다른 필드를 추가하거나 코드를 읽는 동안(API의 해당 부분을 잊어버린/모른 후) 기억할 필요 없이 함수 이름으로 그것이 하는 일을 말할 수 있다는 점에 매우 감사합니다.

따라서 다른 함수가 다른 인수를 사용하여 첫 번째 함수를 호출하더라도 여전히 다른 함수를 선호합니다.

EditorInterface.get_editor_viewport() => get_editor_main_container()

이 함수는 Viewport 반환하지 않고 2D, 3D, 스크립트 편집기 및 자산 라이브러리를 보유하는 중심 함수인 Control 만 반환합니다. 레코드의 경우 반환된 노드는 VBoxContainer* 이지만 추상화되어 있습니다(그러나 설정 선택에 영향을 미치기 때문에 아는 것이 중요합니다).
문서의 설명이 Viewport 클래스에 연결되어 있기 때문에 문서도 잘못되었습니다. https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class -editorinterface-method-get-editor-viewport

@Zylann 은 컨테이너가 아니므 로 get_editor_main_screen() 이어야 하지만 메인 화면 입니다.

@aaronfranke 는 Container 노드이기도 합니다. 사실^^ 하지만... 메인 화면도 작동할 수 있습니다.

묻고 싶습니다. 이 주제에 대한 제안을 추적하는 사람이 있습니까?

예를 들어, 위에서(https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) JSON.print 메서드의 이름을 바꾸는 것을 제안했습니다. 몇 가지 옵션이 제안되었지만 첫 번째 게시물에는 그 중 아무 것도 표시되지 않았습니다.

유용한 아이디어가 너무 많은 게시물에서 사라질까 걱정됩니다. :웃다:

@dalexeev 최근에 첫 번째 게시물을 업데이트할 때 첫 번째 단계를 수행했지만 아직 모든 댓글을

RichTextLabel 일부 버그를 잠재적으로 수정하는 것이 있습니다. 현재 bbcode_text 및 text 가 있지만 둘 다 내부적으로 동일한 데이터 구조를 사용합니다. 동안 만 불리는 방법이 다른 set_bbcode 뒤로 떨어질 set_text 하면 use_bbcode 사용할 수 없습니다. 그래서 저는 #39148에서 그것들을 제거했습니다. 나는 거기에 몇 가지 다른 포인트를 추가했습니다.

Node의 GetSceneInstanceLoadPlaceholder() 는 매우 잘못된 것처럼 보입니다. 먼저 이름에서 알 수 있듯이 자리 표시자를 반환하지 않지만 bool 및 두 번째로 상속된 구현의 세부 정보가 실제 요구 사항 없이 기본 클래스로 누출됩니다(유형 테스트 노드의 다른 방법으로 가능)

RayShape → SeparationRayShape , 처음에 godotengine/godot-proposals#711에서 제안된 대로.

sort_custom 를 제거하고 sort 를 선택적 Callable로 만드는 것은 어떻습니까?

각각 OS.get_ticks_usec() 및 OS.delay_usec() 위해 OS.get_ticks_msec() 및 OS.delay_msec() 를 제거해야 합니까? 이렇게 하면 동일한 것을 달성하는 두 가지 방법을 피할 수 있습니다. 밀리초 단위의 값이 필요한 경우 곱하거나 1000으로 나눌 수 있습니다.

또한 GDScript와 C++ 모두 정수 리터럴에 구분 기호를 추가할 수 있으므로 큰 값을 더 쉽게 읽을 수 있습니다.

# Since Godot 3.2.
OS.delay_usec(123_456_789)

// Since C++14.
OS::get_singleton()->delay_usec(123'456'789);

또한 GDScript와 C++ 모두 정수 리터럴에 구분 기호를 추가할 수 있으므로 큰 값을 더 쉽게 읽을 수 있습니다.

제거가 발생하면 get_ticks_usec() 설명에 구분 기호가 언급되어야 합니다.

@Calinou 한편으로는 당신이 옳았지만 다른 한편으로는 - 대부분의 경우 그러한 높은 정확도가 필요하지 않습니다.

공간 소재의 '알파 가위'는 표준 '알파 클립'이 되어야 합니다.

@Flavelius 저는 "알파 클립"이라는 용어가 자주 사용되는 것을 본 적이 없습니다. 하지만 "알파 클립"과 "알파 가위"보다 훨씬 더 자주 "알파 테스트"가 사용되는 것을 보았습니다.

변경해야 할 사항이 많습니다! 누군가가 이러한 제안을 구현하기 위해 노력하고 있습니까?

@MCrafterzz 사람들은 정기적으로 이름을 바꾸기 위해 풀 리퀘스트를 엽니다. 이것은 한 번에 모두가 아니라 점진적으로 수행됩니다.

텍스처(Texture2D) 및 이미지

• Texture(Texture2D)의 get_data()는 get_image()로 이름을 지정해야 하고 Image의 get_data()는 get_bytes()로 이름을 지정해야 자체 설명이 가능합니다.

IMO: get_image 예, get_bytes 아니요.

texture.get_image().get_data()

메시 / 메시 인스턴스

• Mesh에서는 다음과 같은 방법으로 Material을 얻거나 설정합니다.
  surface_get_material/surface_set_material
• MeshInstance에서는 다음과 같은 방법으로 가져오거나 설정합니다.
  get_surface_material/set_surface_material

그것은 내가 추측하는 것과 같은 이름이어야합니까?

@Coldragon get_surface_material / set_surface_material 및 surface_material 속성 이어야 합니다.

@Coldragon get_surface_material / set_surface_material 및 surface_material 속성이어야 합니다.

"일반" 설정/가져오기가 아니며 대상 표면에 대한 인덱스가 있습니다(메시 클래스 내부의 벡터임).

Array 부울 값을 더 잘 설명하기 위해 empty() 을 is_empty() 로 변경해야 합니다.

String rfind() 대신 find_last() 를 삭제해야 합니다. 정확히 이름을 바꾸는 것은 아니지만 어떤 이름을 유지할지 논의할 가치가 있습니다.

단일 숫자의 경우 stepify 있습니다. Vector2/Vector3의 경우 snapped 있습니다.

벡터는 각 구성 요소에 대해 stepify 를 호출합니다. 하나의 이름을 선택해야 하지만 어떤 이름을 선택해야 할까요?

Poll: :heart: = 둘 다 stepify 여야 합니다. , :rocket: = 둘 다 snapped 여야 합니다. :-1: = 이름을 바꾸지 마십시오.

AABB 에는 intersection 가 있고 Rect2 에는 clip 있습니다. 그들은 똑같은 일을 합니다. 하나의 이름을 선택해야 하지만 어떤 이름을 선택해야 할까요?

Poll: :heart: = 둘 다 intersection 여야 하고, :rocket: = 둘 다 clip 여야 합니다. :-1: = 이름을 바꾸지 마십시오.

@aaronfranke 예, 이전에 https://github.com/godotengine/godot/issues/16863#issuecomment -449628319에서 intersection 이름을 제안했습니다. 우리는이 intersects 로 이름이 변경 될 수있는 overlaps 에서 Rect2 ,하지만 확실 약 AABB 에 대해 intersects → overlaps 이름을 바꿉니다.

이름이 2의 차이점을 전혀 나타내지 않기 때문에 find_node 및/또는 get_node의 이름을 바꿔야 한다고 생각합니다.
find_node는 자식만 보기 때문에 find_child_node가 아닐까요?
get_node의 대체 이름이 무엇인지 잘 모르겠습니다. 내 첫 번째 생각은 트리의 어느 곳에서나 노드를 가져올 수 있기 때문에 get_tree_node였습니다. 그러나 상대 경로가 있는 장면 트리 외부에서도 사용할 수 있습니다.

get_node 는 좋지만 find_node 이름은 find_child 로 변경될 수 있습니다.

@MuffinManKen get_node 는 귀하가 언급한 바와 같이 주어진 노드와 동일한 트리에 연결되어 있는 한 노드의 일부인지 여부에 관계없이 어디서나 모든 노드를 가져올 수 있기 때문에 완벽하게 이해할 수 있다고 생각합니다. SceneTree 여부.

@Coldragon 나는 확실히 나는 이름 변경과 같은 아니에요 find_node 에 find_child 그 다음 나에게 어떤 이유로 직접 아이들과 함께 만 작동한다는 인상을 준다으로, 중. 대안은 find_descendant 또는 다른 이름으로 부르는 것이지만 너무 장황하고 복잡합니다. find() 로 줄이는 것도 우리가 무엇을 찾고 있는지 명확하지 않기 때문에 의미가 없습니다. 따라서 다른 대안을 찾지 않는 한 find_node 있어야 한다고 생각합니다. API 문서에 대한 동작의 명확한 문서화된 차이점이 있어야 합니다.

Godot 3.1에서 프로젝트가 내보내기 템플릿 바이너리(디버그 또는 릴리스)에서 실행될 때 true 평가되는 standalone 기능 태그 를 추가 했습니다. 반대는 editor 이며, 프로젝트가 편집기 바이너리에서 실행될 때 true 평가됩니다.

그러나 시간이 지남에 따라 standalone 을 runner 로 변경하는 것이 더 짧고 약간 더 자명하기 때문에 더 좋을 것이라고 생각합니다. 어떻게 생각하나요?

exported 또는 release 어떻습니까?

@aaronfranke exported 는 프로젝트를 내보냈음을 의미하지만 반드시 그런 것은 아닙니다. 자산을 미리 가져온 경우 내보내기 템플릿 바이너리 를 사용하여 소스 파일에서 직접 프로젝트를 실행할 수 있습니다.

또한 release 는 이미 릴리스 모드 바이너리에 사용됩니다(디버그 모드 바이너리에 사용되는 debug 와 대조적으로).

runner 이(가) 명확하지 않은 것 같습니다. standalone 괜찮습니다. !OS.get_feature("editor") 만 사용할 수 있으므로 제거하는 것도 괜찮습니다.

!OS.get_feature("editor") 만 사용할 수 있으므로 제거하는 것도 괜찮습니다.

.not 선택기가 없기 때문에 프로젝트 설정을 재정의하는 데 사용할 수 없습니다. 기본 설정과 재정의를 바꾸면 가능하지만 조금 더 복잡하게 느껴집니다.

그렇다면 editor 와 대조되는 app 또는 game 아닌 이유는 무엇입니까? 아니면 더 혼란스러울까요? no-editor 에 대한 기능 플래그가 더 명시적일 수 있습니까?

@willnationsdev game Godot가 게임에만 사용될 수 있음을 의미합니다. 많은 사람들이 게임이 아닌 응용 프로그램에 Godot를 성공적으로 사용하고 있습니다. 그래서 저는 좀 더 포괄적인 용어를 사용하는 것을 선호합니다 :slightly_smiling_face:

또한 설명이 필요 없습니다. 사람들은 이것이 편집기에서 실행되는 프로젝트에 여전히 적용된다고 생각할 수 있습니다(결국 편집기에서 "게임"을 실행하고 있음). app 마찬가지입니다.

"독립"은 어떻습니까?

2020년 7월 25일(토) 오전 5:49 Hugo Locurcio, 알림 @github.com
썼다:

@willnationsdev https://github.com/willnationsdev 게임은 Godot를 의미합니다
게임에만 사용할 수 있으며 그렇지 않은 것으로 판명되었습니다 🙂

또한 사람들이 여전히 그렇게 생각할 수도 있습니다.
편집기에서 실행 중인 프로젝트에 적용됩니다. 앱도 마찬가지입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent 는 나에게도 그다지 자명하게 들리지 않습니다.

에디터 대 독립형은 아마도 표준 이름 지정(최소한 여러 엔진에서 볼 수 있음)이므로 휠 imho를 재발명할 이유가 없습니다.

Get_node는 자손을 얻는 데 국한되지 않으므로 매우
오해의 소지가 있는 이름. 두 가지 방법은 매우 다른 이름을 필요로 합니다.
하는 것은 매우 다릅니다.

2020년 7월 25일(토) 오후 3시 14분 golddotasksquestions, <
[email protected]>은 다음과 같이 썼습니다.

처음에 오랫동안 혼란스러웠던 기억이
find_node 및 get_node. 나는 find_descendant와
get_descendant, 이것이 사실이고 유익한 정보가 될 것이므로 @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
"단순함"은 모든 사람의 차 한잔이 아닐 수도 있지만 imho는 실제로 그렇지 않습니다.
자동 완성 및 약어 "$"가 있으므로 문제가 발생합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

Transform 및 Transform2D 메소드 inverse 및 xform_inv 모두 이름을 변경/제거해야 한다고 생각합니다. 이 메소드가 실제로 하는 일은 사람들이 기대하는 것과 다르기 때문입니다 . 자세한 내용: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521.

RayCast.cast_to 는 RayCast.segment 또는 다른 이름으로 변경되어야 합니다. 방금 누군가가 그것이 기능이 아니라 속성이라는 것을 깨닫는 데 40분이 걸렸다고 말했습니다. 아마도 동사이기도 하기 때문일 것입니다.

RayCast.target 어떻습니까?

@razcore-art 최근 에 레이 캐스팅과 관련된 질문 에 segment 단어를 사용하여 설명했기 때문에 이치 에 맞는 것 같습니다. 그러나 이것은 direction 및 length 로 다시 작성할 수도 있으므로 실제로 세그먼트가 아닌 광선에 더 가까운 것이 될 것입니다. 기하학적으로 말하면(또는 그냥 공존할 수 있는 대체 속성을 제공함) . 문제는 인스펙터에서 쉽게 정규화된 방향 벡터를 설정할 방법이 없다는 것입니다. 나는 적어도 2D를 위한 제안서를 작성했습니다: godotengine/godot-proposals#397, 하지만 아마도 그건 너무 무리일 것입니다.

편집: 더 생각해보면 segment 는 RayCast 노드 측면에서 별로 의미가 없지만 Physics2DDirectSpaceState.intersect_ray() 측면에서는 의미가 있습니다.

RayCast.target 어떻습니까?

@nathanfranke 대상이 Node 또는 NodePath 합니다. 따라서 최소한 RayCast.target_position 수 있습니다. RayCast.cast_position 또는 RayCast.cast_offset . 광선 투사가 회전할 수 있다는 사실을 잊지 마십시오. 이는 전역 좌표에서 실제 투사 위치를 이동할 수 있습니다.

PhysX API는 레이 캐스트 구성을 위한 단위 방향 + 길이에 대한 제 생각을 확인시켜줍니다. 😛

즉, 나는 cast_position 쪽으로 기울고 있습니다 ... 레이 캐스팅이 작동하는 방식을 다시 작성하려면 더 많은 핵심 변경이 필요하기 때문입니다.

@Xrayez 나는 속성의 시작 부분에 "cast"라는 단어를 사용하지 않을 것입니다. 왜냐하면 자연스럽게 명사 "cast"가 아니라 "cast"라는 동사로 읽게 되므로 cast_position 는 그렇지 않을 것입니다. 이것이 메서드가 아니라 속성이라는 것을 모르는 원래 문제를 해결했습니다( cast_position 가 위치로 캐스팅하는 메서드라고 가정하기 쉽습니다). target_position 좋아요.

https://github.com/godotengine/godot/issues/19325#issuecomment -394155128에서:

KEY_BACK 를 KEY_MEDIA_BACK , KEY_FORWARD 를 KEY_MEDIA_FORWARD 변경할 수 있습니다. MEDIA 접두사를 사용할 수 있는 다른 미디어 키가 있을 수 있습니다.

String begins_with() 을 starts_with() 변경하는 것을 고려해야 합니다.

Java, C#, Python, JavaScript 등에서 그렇습니다.

버그스쿼드 편집: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int 는 이름이 소문자로 시작하는 유일한 유형/클래스입니다. (GDScript에서) Bool , Float , Int 로 이름을 바꿔야 한다고 생각합니다. 이렇게 하면 잘못된 유형 구문 강조 표시 문제가 자동으로 수정됩니다.

그리고 bool , float , int 는 @GDScript 페이지의 내장 Python 유사 함수 len 및 str 도 포함됩니다)

str / String : str(x) 와 String(x) 와 같은 결과가 나오는 상황이 비슷합니다.

추가하다. 다음과 같이 표시되어야 합니다.

# `Int` is type.
func get_key() -> Int:
    # `int` is Python-like function.
    return int(config.get_value("sect", "key"))

@dalexeev 그들은 원시 유형이기 때문에 소문자입니다. 이것은 대부분의 다른 언어에서 볼 수 있습니다.
Node 와 같은 클래스는 참조 유형이며 할당 시 복사하지 않습니다.

var a := Node2D()
var b = a
a.position = Vector2(2, 2)
print(b.position) # (2, 2)

오히려, 우리가 이름을 변경 고려해야 String 에 string 부터 String 로 동작합니다 더 유사하게 변경할 수 없으며 int 말보다 Node .

Vector2 , Vector3 등의 경우에도 마찬가지이므로 지금은 이것을 수정합니다.

@nathanfranke 다른 언어에서는 다릅니다. 예를 들어 Kotlin, Haxe, 모든 유형 의 Ada 이름은 대문자로 표시됩니다.

또한 원시성은 조건부 개념입니다. 나에게 String , Color , Vector2 등은 기본 유형입니다. 특히 참조가 아닌 값으로 전달되기 때문입니다.

유일한 장애물은 이전 버전과의 호환성 위반입니다.

String 는 변경할 수 없기 때문에

놀랍게도 GDScript의 문자열은 변경 가능합니다.

var s = "abc"
s[0] = "xyz"
print(s) # xyzbc

Vector2 는 2 float 로 구성되어 있기 때문에 기본 요소가 아닙니다. 그러나 Vector2 및 float 는 기본 제공 변형 유형입니다.

@Zylann 타입명에 반영해야 할 정도로 근본적인 차이인가요?

(저에게 '원시'는 '단품'이 아니라 '단순'입니다.)

나는 이것을 나에게 유리하게 해석하고 싶지는 않지만:

기본 유형의 이름은 대문자로 표시됩니다. :웃다:

내가 이해한 용어는 다음과 같습니다.

| 유형 이름 | 기본형 | 값 유형 | 가변형 | 내장형 |
| -------------- | -------------- | -------------- | -------------- | -------------- |
| 정수 | 예 | 예 | 해당 없음 | 예 |
| 벡터2 | 아니오 | 예 | 해당 없음 | 예 |
| 노드 | 아니오 | 아니오 | 예 | 예 |
| 문자열 | 아니오 | 아니오 | 아니오 | 예 |

어쨌든 이 이름은 변경되지 않습니다. 그것들은 있는 그대로 괜찮고 다양한 언어의 프로그래머들에게 친숙합니다. 이 추적기를 무의미한 토론으로 채우지 않도록 여기서 토론을 끝내야 합니다.

변경 가능한 유형 열이 잘못되었습니다. 개체 파생, 사전 및 배열만 변경할 수 있습니다. ( Vector2 는 vec2.x = 0 할 수 있기 때문에 변경 가능하게 보일 수 있지만 실제로는 vec2 = vec2.with_x(0) 와 같이 변환됩니다.)

ShortCut 을 Shortcut

다음 방법을 변경해야 합니다.
사이의 불일치

Input.is_action_just_pressed(action: String) -> bool
Input.is_action_just_released(action: String) -> bool
Input.is_action_pressed(action: String) -> bool

에게

Input.is_action_pressed(action: String, allow_echo: bool = false) -> bool
Input.is_action_released(action: String) -> bool

일관성을 위해
그리고

InputEvent.is_action_pressed(action: String, allow_echo: bool = false) -> bool
InputEvent.is_action_released(action: String) -> bool

수정해야 합니다.

추신 : "비슷한 방법은 적을수록 좋다"는 원칙에서 진행했습니다.

@dalexeev 부울 매개변수는 true 및 false 컨텍스트가 없기 때문에 종종 다른 메소드를 사용하는 것보다 가독성이 떨어집니다.

예, 하지만 일관성도 좋을 것입니다. 그러면 InputEvent에서 부울 매개변수를 제거하시겠습니까?

@Calinou 대부분의 경우 에코 이벤트를 확인할 필요가 없습니다.

나는 이것을 큰 문제로 보지 않는다. 코드를 입력하면 인수 힌트가 나타납니다. 코드를 읽을 때 Shift + 클릭을 사용할 수 있습니다. 자주 사용하는 함수에 대한 인수는 빠르게 기억할 수 있습니다(예: String.split ).

또한 doc/classes 디렉토리에서 208개의 선택적 부울 인수가 발견되었습니다(이것은 핵심일 뿐이며 16개 모듈에는 doc_classes 중첩 디렉토리가 있습니다).

AcceptDialog.xml

17:         <argument index="1" name="right" type="bool" default="false">

AnimatedSprite2D.xml

26:         <argument index="1" name="backwards" type="bool" default="false">

AnimationNode.xml

53:         <argument index="5" name="optimize" type="bool" default="true">
74:         <argument index="6" name="optimize" type="bool" default="true">

AnimationPlayer.xml

146:            <argument index="3" name="from_end" type="bool" default="false">
201:            <argument index="1" name="update" type="bool" default="false">
223:            <argument index="0" name="reset" type="bool" default="true">

Animation.xml

349:            <argument index="2" name="exact" type="bool" default="false">

Array.xml

130:            <argument index="1" name="before" type="bool" default="true">
146:            <argument index="3" name="before" type="bool" default="true">
172:            <argument index="0" name="deep" type="bool" default="false">
366:            <argument index="3" name="deep" type="bool" default="false">

AStar2D.xml

79:         <argument index="2" name="bidirectional" type="bool" default="true">
114:            <argument index="1" name="include_disabled" type="bool" default="false">
276:            <argument index="1" name="disabled" type="bool" default="true">

AStar.xml

74:         <argument index="2" name="bidirectional" type="bool" default="true">
94:         <argument index="2" name="bidirectional" type="bool" default="true">
113:            <argument index="2" name="bidirectional" type="bool" default="true">
131:            <argument index="1" name="include_disabled" type="bool" default="false">
293:            <argument index="1" name="disabled" type="bool" default="true">

Camera3D.xml

15:         <argument index="0" name="enable_next" type="bool" default="true">

CanvasItem.xml

274:            <argument index="2" name="filled" type="bool" default="true">
376:            <argument index="4" name="transpose" type="bool" default="false">
403:            <argument index="4" name="transpose" type="bool" default="false">
411:            <argument index="8" name="clip_uv" type="bool" default="true">

ClassDB.xml

55:         <argument index="1" name="no_inheritance" type="bool" default="false">
66:         <argument index="1" name="no_inheritance" type="bool" default="false">
88:         <argument index="1" name="no_inheritance" type="bool" default="false">
110:            <argument index="1" name="no_inheritance" type="bool" default="false">
134:            <argument index="2" name="no_inheritance" type="bool" default="false">

CodeHighlighter.xml

19:         <argument index="3" name="p_line_only" type="bool" default="false">

Color.xml

251:            <argument index="0" name="with_alpha" type="bool" default="true">

Control.xml

586:            <argument index="2" name="keep_margin" type="bool" default="false">
588:            <argument index="3" name="push_opposite_anchor" type="bool" default="true">
605:            <argument index="3" name="push_opposite_anchor" type="bool" default="false">
629:            <argument index="1" name="keep_margins" type="bool" default="false">
720:            <argument index="1" name="keep_margins" type="bool" default="false">
758:            <argument index="1" name="keep_margins" type="bool" default="false">
779:            <argument index="1" name="keep_margins" type="bool" default="false">

CryptoKey.xml

26:         <argument index="1" name="public_only" type="bool" default="false">
38:         <argument index="1" name="public_only" type="bool" default="false">
49:         <argument index="1" name="public_only" type="bool" default="false">
59:         <argument index="0" name="public_only" type="bool" default="false">

Curve2D.xml

121:            <argument index="1" name="cubic" type="bool" default="false">

Curve3D.xml

145:            <argument index="1" name="cubic" type="bool" default="false">
158:            <argument index="1" name="apply_tilt" type="bool" default="false">

Dictionary.xml

89:         <argument index="0" name="deep" type="bool" default="false">

Directory.xml

127:            <argument index="0" name="skip_navigational" type="bool" default="false">
129:            <argument index="1" name="skip_hidden" type="bool" default="false">

DisplayServer.xml

647:            <argument index="2" name="multiline" type="bool" default="false">

EditorInterface.xml

212:            <argument index="1" name="with_preview" type="bool" default="true">

EditorNode3DGizmoPlugin.xml

40:         <argument index="3" name="cancel" type="bool" default="false">
60:         <argument index="1" name="billboard" type="bool" default="false">
73:         <argument index="2" name="on_top" type="bool" default="false">
88:         <argument index="2" name="billboard" type="bool" default="false">
90:         <argument index="3" name="on_top" type="bool" default="false">
92:         <argument index="4" name="use_vertex_color" type="bool" default="false">

EditorNode3DGizmo.xml

37:         <argument index="2" name="billboard" type="bool" default="false">
39:         <argument index="3" name="secondary" type="bool" default="false">
53:         <argument index="2" name="billboard" type="bool" default="false">
66:         <argument index="1" name="billboard" type="bool" default="false">
103:            <argument index="2" name="cancel" type="bool" default="false">

EditorProperty.xml

30:         <argument index="3" name="changing" type="bool" default="false">

Expression.xml

36:         <argument index="2" name="show_error" type="bool" default="true">

File.xml

211:            <argument index="0" name="allow_objects" type="bool" default="false">
439:            <argument index="1" name="full_objects" type="bool" default="false">

Font.xml

47:         <argument index="5" name="outline" type="bool" default="false">

GIProbe.xml

19:         <argument index="1" name="create_visual_debug" type="bool" default="false">

HTTPClient.xml

32:         <argument index="2" name="use_ssl" type="bool" default="false">
34:         <argument index="3" name="verify_host" type="bool" default="true">

HTTPRequest.xml

110:            <argument index="2" name="ssl_validate_domain" type="bool" default="true">

ImageTexture.xml

43:         <argument index="1" name="immediate" type="bool" default="false">

Image.xml

226:            <argument index="0" name="renormalize" type="bool" default="false">
415:            <argument index="0" name="square" type="bool" default="false">
433:            <argument index="1" name="grayscale" type="bool" default="false">

ImmediateGeometry3D.xml

24:         <argument index="3" name="add_uv" type="bool" default="true">

InputEvent.xml

54:         <argument index="1" name="allow_echo" type="bool" default="false">

Input.xml

40:         <argument index="1" name="update_existing" type="bool" default="false">

InstancePlaceholder.xml

16:         <argument index="0" name="replace" type="bool" default="false">
33:         <argument index="0" name="with_order" type="bool" default="false">

ItemList.xml

19:         <argument index="1" name="selectable" type="bool" default="true">
32:         <argument index="2" name="selectable" type="bool" default="true">
58:         <argument index="1" name="exact" type="bool" default="false">
235:            <argument index="1" name="single" type="bool" default="true">

JavaScript.xml

18:         <argument index="1" name="use_global_execution_context" type="bool" default="false">

JSONRPC.xml

59:         <argument index="1" name="recurse" type="bool" default="false">

JSON.xml

28:         <argument index="2" name="sort_keys" type="bool" default="false">

KinematicBody2D.xml

78:         <argument index="1" name="infinite_inertia" type="bool" default="true">
80:         <argument index="2" name="exclude_raycast_shapes" type="bool" default="true">
82:         <argument index="3" name="test_only" type="bool" default="false">
96:         <argument index="2" name="stop_on_slope" type="bool" default="false">
102:            <argument index="5" name="infinite_inertia" type="bool" default="true">
125:            <argument index="3" name="stop_on_slope" type="bool" default="false">
131:            <argument index="6" name="infinite_inertia" type="bool" default="true">
145:            <argument index="2" name="infinite_inertia" type="bool" default="true">

KinematicBody3D.xml

80:         <argument index="1" name="infinite_inertia" type="bool" default="true">
82:         <argument index="2" name="exclude_raycast_shapes" type="bool" default="true">
84:         <argument index="3" name="test_only" type="bool" default="false">
98:         <argument index="2" name="stop_on_slope" type="bool" default="false">
104:            <argument index="5" name="infinite_inertia" type="bool" default="true">
127:            <argument index="3" name="stop_on_slope" type="bool" default="false">
133:            <argument index="6" name="infinite_inertia" type="bool" default="true">
158:            <argument index="2" name="infinite_inertia" type="bool" default="true">

Marshalls.xml

35:         <argument index="1" name="allow_objects" type="bool" default="false">
65:         <argument index="1" name="full_objects" type="bool" default="false">

Navigation2D.xml

43:         <argument index="2" name="optimize" type="bool" default="true">

Navigation3D.xml

46:         <argument index="2" name="use_collision" type="bool" default="false">
65:         <argument index="2" name="optimize" type="bool" default="true">

NavigationServer3D.xml

209:            <argument index="3" name="use_collision" type="bool" default="false">

Node2D.xml

63:         <argument index="1" name="scaled" type="bool" default="false">
74:         <argument index="1" name="scaled" type="bool" default="false">

Node.xml

126:            <argument index="1" name="legible_unique_name" type="bool" default="false">
146:            <argument index="1" name="legible_unique_name" type="bool" default="false">
159:            <argument index="1" name="persistent" type="bool" default="false">
189:            <argument index="1" name="recursive" type="bool" default="true">
191:            <argument index="2" name="owned" type="bool" default="true">
540:            <argument index="2" name="parent_first" type="bool" default="false">
599:            <argument index="1" name="keep_data" type="bool" default="false">
737:            <argument index="1" name="recursive" type="bool" default="true">

Object.xml

378:            <argument index="1" name="reversed" type="bool" default="false">

OS.xml

73:         <argument index="2" name="blocking" type="bool" default="true">
77:         <argument index="4" name="read_stderr" type="bool" default="false">
141:            <argument index="0" name="utc" type="bool" default="false">
150:            <argument index="0" name="utc" type="bool" default="false">
303:            <argument index="0" name="utc" type="bool" default="false">
451:            <argument index="0" name="short" type="bool" default="false">

PacketPeerDTLS.xml

17:         <argument index="1" name="validate_certs" type="bool" default="true">

PacketPeer.xml

36:         <argument index="0" name="allow_objects" type="bool" default="false">
57:         <argument index="1" name="full_objects" type="bool" default="false">

PCKPacker.xml

33:         <argument index="0" name="verbose" type="bool" default="false">

PhysicsDirectSpaceState2D.xml

62:         <argument index="4" name="collide_with_bodies" type="bool" default="true">
64:         <argument index="5" name="collide_with_areas" type="bool" default="false">
89:         <argument index="5" name="collide_with_bodies" type="bool" default="true">
91:         <argument index="6" name="collide_with_areas" type="bool" default="false">
107:            <argument index="4" name="collide_with_bodies" type="bool" default="true">
109:            <argument index="5" name="collide_with_areas" type="bool" default="false">

PhysicsDirectSpaceState3D.xml

63:         <argument index="4" name="collide_with_bodies" type="bool" default="true">
65:         <argument index="5" name="collide_with_areas" type="bool" default="false">

PhysicsServer2D.xml

21:         <argument index="3" name="disabled" type="bool" default="false">
351:            <argument index="3" name="disabled" type="bool" default="false">

PhysicsServer3D.xml

21:         <argument index="3" name="disabled" type="bool" default="false">
351:            <argument index="3" name="disabled" type="bool" default="false">
426:            <argument index="1" name="init_sleeping" type="bool" default="false">

PopupMenu.xml

36:         <argument index="2" name="global" type="bool" default="false">
70:         <argument index="3" name="global" type="bool" default="false">
118:            <argument index="3" name="global" type="bool" default="false">
133:            <argument index="3" name="global" type="bool" default="false">
195:            <argument index="2" name="global" type="bool" default="false">
219:            <argument index="2" name="global" type="bool" default="false">
526:            <argument index="2" name="global" type="bool" default="false">

ProjectSettings.xml

93:         <argument index="1" name="replace_files" type="bool" default="true">

Rect2.xml

146:            <argument index="1" name="include_borders" type="bool" default="false">

RenderingDevice.xml

29:         <argument index="4" name="sync_with_draw" type="bool" default="true">
413:            <argument index="3" name="arg3" type="bool" default="false">
493:            <argument index="1" name="allow_cache" type="bool" default="true">
565:            <argument index="6" name="sync_with_draw" type="bool" default="false">
591:            <argument index="9" name="sync_with_draw" type="bool" default="false">
677:            <argument index="2" name="sync_with_draw" type="bool" default="false">
691:            <argument index="3" name="sync_with_draw" type="bool" default="false">

RenderingServer.xml

847:            <argument index="0" name="swap_buffers" type="bool" default="true">
1812:           <argument index="3" name="color_format" type="bool" default="false">
1814:           <argument index="4" name="custom_data_format" type="bool" default="false">
2455:           <argument index="3" name="use_filter" type="bool" default="true">
2557:           <argument index="2" name="is_2d_skeleton" type="bool" default="false">

ResourceLoader.xml

61:         <argument index="2" name="no_cache" type="bool" default="false">
100:            <argument index="2" name="use_sub_threads" type="bool" default="false">

Resource.xml

24:         <argument index="0" name="subresources" type="bool" default="false">

RigidBody2D.xml

106:            <argument index="1" name="infinite_inertia" type="bool" default="true">

SceneState.xml

142:            <argument index="1" name="for_parent" type="bool" default="false">

SceneTree.xml

65:         <argument index="1" name="pause_mode_process" type="bool" default="true">

ScriptCreateDialog.xml

25:         <argument index="2" name="built_in_enabled" type="bool" default="true">
27:         <argument index="3" name="load_enabled" type="bool" default="true">

Script.xml

107:            <argument index="0" name="keep_state" type="bool" default="false">

Skeleton3D.xml

238:            <argument index="3" name="persistent" type="bool" default="false">

SkeletonIK3D.xml

25:         <argument index="0" name="one_time" type="bool" default="false">

StreamPeerSSL.xml

33:         <argument index="1" name="validate_certs" type="bool" default="false">

StreamPeer.xml

128:            <argument index="0" name="allow_objects" type="bool" default="false">
274:            <argument index="1" name="full_objects" type="bool" default="false">

String.xml

587:            <argument index="0" name="with_prefix" type="bool" default="false">
855:            <argument index="1" name="allow_empty" type="bool" default="true">
924:            <argument index="1" name="allow_empty" type="bool" default="true">
947:            <argument index="1" name="allow_empty" type="bool" default="true">
957:            <argument index="0" name="left" type="bool" default="true">
959:            <argument index="1" name="right" type="bool" default="true">

SurfaceTool.xml

216:            <argument index="0" name="flip" type="bool" default="false">

TextEdit.xml

61:         <argument index="1" name="adjust_viewport" type="bool" default="true">
73:         <argument index="1" name="adjust_viewport" type="bool" default="true">
75:         <argument index="2" name="can_be_hidden" type="bool" default="true">

Texture2D.xml

23:         <argument index="3" name="transpose" type="bool" default="false">
50:         <argument index="4" name="transpose" type="bool" default="false">
77:         <argument index="4" name="transpose" type="bool" default="false">
89:         <argument index="10" name="clip_uv" type="bool" default="true">

TileMap.xml

137:            <argument index="1" name="ignore_half_ofs" type="bool" default="false">
153:            <argument index="3" name="flip_x" type="bool" default="false">
155:            <argument index="4" name="flip_y" type="bool" default="false">
157:            <argument index="5" name="transpose" type="bool" default="false">
183:            <argument index="2" name="flip_x" type="bool" default="false">
185:            <argument index="3" name="flip_y" type="bool" default="false">
187:            <argument index="4" name="transpose" type="bool" default="false">

TileSet.xml

323:            <argument index="3" name="one_way" type="bool" default="false">

TreeItem.xml

22:         <argument index="3" name="disabled" type="bool" default="false">
205:            <argument index="0" name="wrap" type="bool" default="false">
229:            <argument index="0" name="wrap" type="bool" default="false">
439:            <argument index="2" name="just_outline" type="bool" default="false">
567:            <argument index="4" name="expr" type="bool" default="false">

UndoRedo.xml

103:            <argument index="0" name="increase_version" type="bool" default="true">

Viewport.xml

117:            <argument index="1" name="in_local_coords" type="bool" default="false">
165:            <argument index="1" name="in_local_coords" type="bool" default="false">

if e.is_action_pressed("ui_left", allow_echo = true):
    velocity += Vector2.LEFT

var arr = s.split(",", allow_empty = false)

@dalexeev 스크롤을 더 쉽게 하기 위해 스포일러에 넣을 수 있습니까?

@dalexeev 키를 눌렀을 때만 아니라 키가 눌렸는지 확인해야 하는 경우가 많습니다. 예를 들어, 캐릭터를 이동하는 스크립트는 WASD 또는 화살표 키를 사용하여 이 작업을 수행해야 합니다. 거의 모든 게임은 입력을 처리해야 하므로 이러한 작업에 대해 두 가지 방법만 사용하는 것이 낭비라고 생각하지 않습니다.

코드를 읽을 때 Shift + 클릭을 사용할 수 있습니다.

GitHub에서 diff를 보고 있는 경우에는 그렇지 않습니다. 코드에서 읽을 수 있는 IDE가 필요한 경우 좋은 코드가 아닙니다.

@aaronfranke 다른 207개의 경우에 대해 별도의 기능을 만드는 것도 제안합니까? 그렇지 않다면 이 주장은 결정적이지 않습니다. 또한 위에서 매개변수 이름을 지정할 수 있으면 IDE 없이도 읽을 수 있다고 썼습니다.

키를 눌렀을 뿐 아니라 눌렸는지 확인해야 하는 경우가 많습니다.

종종, 하지만 에코가 없는 것보다 더 자주는 아닙니다.

세 가지 메서드( is_action_just_pressed , is_action_just_released , is_action_pressed )의 존재는 is_action_released 메서드가 있을 것으로 예상하기 때문에 혼란스럽습니다.

추가하다. 적어도 시각적으로 어떤 옵션이 더 쉽습니까?

is_action_released 는 not is_action_pressed 로 달성할 수 있습니다. just 메서드에는 해당되지 않습니다.

위에서 언급했듯이 원시 bool은 피해야 합니다. INPUT_ALLOW_ECHO/INPUT_NO_ECHO와 같은 플래그는 bool보다 훨씬 낫습니다.

@dalexeev 그것은 혼란을 일으킬 뿐입니다. is_action_pressed() 와 echo는 2가지 다른 것입니다. is_action_pressed() 는 지연이 없는 반면 에코 이벤트는 첫 번째 누름 후 약간의 지연 후에 수신되는 것을 확인할 수 있습니다.

@KoBeWi 당신

is_action_pressed(action: String, allow_echo: bool = false) -> bool

로 변경되어야 합니다

is_action_pressed(action: String, allow_echo: bool = true) -> bool

와 일치하지 않기 때문에

func _input(e):
    if !e.is_action("ui_left"):
        return
    $Label.text += "pressed: %s, echo: %s\n" % [e.is_pressed(), e.is_echo()]

pressed: True, echo: False
pressed: True, echo: True
pressed: True, echo: True
pressed: True, echo: True
pressed: False, echo: False

@dalexeev 당신이 제안한 것이 올바르지 않습니다. 에코 이벤트에 대해 이야기할 때 키를 누르는 동안 반복되는 키보드 이벤트에 대해 이야기합니다. 여기서 이 용어를 사용하는 것은 의미가 없습니다. 액션 시스템은 이벤트에 직접 의존하지 않고 상태가 프레임 단위로 업데이트되기 때문입니다. 또한 동작은 "에코" 이벤트가 존재하지 않는 컨트롤러나 마우스 버튼과 같은 다른 장치에서도 작동할 수 있습니다.

TreeItem의 get_children()은 첫 번째 자식만 반환하고 이름(또는 문서의 설명)이 제안하는 것처럼 모든 자식을 반환하지는 않습니다.

[편집하다]
NVM 문서. 메서드 설명이 마스터에서 업데이트되었습니다. 죄송합니다.

Resource의 local_to_scene 는 local_to_instance 또는 unique_per_instance 여야 합니다. "장면에 로컬"은 실제로 장면의 인스턴스당인 경우 장면에 대해 로컬인 동작을 나타냅니다.

Image.load() → Image.load_from_file() 이름을 바꿉니다.

1. 코드를 통해 load("image.png") 파일과의 혼동 가능성을 줄이는 데 도움이 됩니다. 문서 변경 사항 #42412를 참조하십시오.
2. Image.load() 는 더 이상 GDScript 내장 이름으로 강조 표시되지 않습니다: #28866.
3. 이미지 형식당 Image.load_*_from_buffer() 와 일치합니다. 버퍼 관련 메서드는 API 팽창을 방지하기 위해 동일한 인터페이스로 잠재적으로 통합될 수 있지만 이는 논의할 또 다른 주제입니다.

@Xrayez는 GDScript에서 load 를 제거하는 것도 가치가 있습니다: https://github.com/godotengine/godot-proposals/issues/263

ProjectSettings의 registering_order 변수 및 관련 메서드 set_registering_order 는 사용되지 않습니다.

RandomNumberGenerator 는 Random 로 이름을 변경해야 하며 randf 및 rand_range 와 같은 전역 임의 함수는 더 이상 사용되지 않거나 제거되어야 합니다.

임의의 시드가 지정된 동안 신뢰할 수 없는 함수를 호출하는 가능한 문제를 봅니다.

seed(123)
randf()
call_method() # This could change the seed for its own random reasons!
randf()

randf 및 rand_range 와 같은 전역 임의 함수는 더 이상 사용되지 않거나 제거되어야 합니다.

Godotengine/godot-proposals#1590의 일부로 논의되었습니다.

나는 접근 가능성과 프로토타이핑 목적을 위해 적어도 일부는 이러한 기본 무작위 방법을 전역 범위에서 사용하는 것을 선호합니다. 그러나 seed() 및 rand_seed() 는 확실히 제거할 수 있습니다.

Callable 이 추가된 이후 FuncRef 이 중복된 것 같습니다.

Inspector에서 property_can_revert 및 property_get_revert 메소드를 발견하고 #43078에 보고했습니다. 그러나 _get , _set 및 _get_property_list 의 규칙을 따르려면 선행 밑줄로 이름을 바꿔야 한다고 생각합니다.

EditorImportPlugin 와 EditorExportPlugin 는 서로 연관되어 보이지만 하나는 리소스 가져오기에 대한 것이고 다른 하나는 프로젝트 내보내기에 대한 것입니다. EditorImportPlugin 을 EditorResourceImportPlugin 또는 해당 라인에 따라 변경하는 것이 좋습니다.

편집: 그리고 EditorPlugin.add_import_plugin 그에 따라 이름을 바꿔야 합니다.

왜 ResourceImportPlugin 아닌가요? 많은(대부분?) 편집기 클래스에는 SceneTreeDock 또는 모든 애니메이션 항목과 같이 "Editor"라는 단어가 이미 포함되어 있지 않습니다.

Tracking_status 에 열거 ARVRInterface 로 변경해야합니다 TrackingStatus , 다른 열거 이름의 스타일과 일치합니다.

위의 ARVRInterface 보면 이름의 품질이 일반적으로 상당히 좋지 않습니다. 제안된 이름도 다음과 같습니다.

• ar_is_anchor_detection_enabled → anchor_detection_enabled (속성)
• interface_is_initialized → initialized (속성, setter가 있으므로 enabled 추가로 다시 작성할 수 있음)
• interface_is_primary → primary (속성)
• get_render_targetsize() → get_render_target_size() (메소드)
• uninitialize() → finalize() (메소드)

그렇지 않으면 문서가 잘못되었습니다. 🙂

나는 이 클래스를 전혀 사용하지 않았지만, 그 클래스를 보기만 해도 이름이 이상해 보입니다.

Control.MOUSE_FILTER_PASS 을 Control.MOUSE_FILTER_PASSTHROUGH 해야 합니까? 이렇게 하면 이벤트가 제어 노드를 통해 그 아래에 있는 노드로 전달된다는 것이 더 분명해집니다. 실제로 이름을 바꿀 가치가 있는지 확실하지 않습니다.

@Calinou 아프지 않을 것 같아서 응원합니다. 당신이 언급했듯이, 그 변경은 그 마우스 필터 모드가 하는 일을 한 눈에 좀 더 명확하게 만들 것입니다.

@Calinou 현재 행동이 비정상적이라고 생각합니다. 이 장면 설정은 "Click Child2, Click Scene"을 생성합니다.

(참고로 모두 통과로 설정)

:smile: 제안 A : 입력 이벤트가 부모에게만 전송되는 것처럼 보이기 때문에 현재 동작에 대해 아마도 Control.MOUSE_FILTER_PASSPARENTS 와 같은 것입니다.

:로켓: 명제 B : 상수를 다음과 같이 변경합니다.

• 중지: 현재 동작 - 이벤트를 가져오고 모든 전파를 중지합니다.
• PASS_PARENT: 현재 PASS와 동일한 동작
• PASS_ALL: 무시하지만 이벤트를 받습니다.
• IGNORE: 현재 동작 - 이벤트를 받지 않지만 계속 전파합니다.

:eyes: 명제 C : 노드가 GUI 입력을 받는지 여부는 실제로 관련이 없습니다. 신호를 연결할 수 없거나 부울 플래그를 사용할 수 없기 때문입니다. 옵션을 Control.propagation_mode 하고 다음 상수를 가질 수 있습니다.

• 없음
• 부모의
• 모두

제 생각에는 훨씬 깨끗해 보일 것입니다.

그것은 이름을 바꾸는 것 이상이며 제안으로 논의되어야 합니다.

이 모든 이름 바꾸기가 긴 이유는 무엇입니까? 간단하고 짧은 것을 정말 긴 것으로 바꾸고 있습니다.

clip 를 intersection 로 변경하면 입력 시간이 두 배 늘어납니다.
Control.MOUSE_FILTER_PASS 도 Control.MOUSE_FILTER_PASSTHROUGH
등

나는 더 간단하고 덜 장황한 변경을 선호합니다. 기능에 대한 설명이 아니라 기능 이름입니다.

나는 더 간단하고 덜 장황한 변경을 선호합니다. 기능에 대한 설명이 아니라 기능 이름입니다.

이름은 설명적이어야 합니다. 또한 길이는 자동 완성 기능(Godot 편집기에 내장되어 있음)을 사용하는 경우 문제가 되지 않습니다.

IRC에서 한 번 언급했지만 응답을 받지 못했지만 TextureRect에는 "Scale On Expand(Compat)"라는 스트레치 모드가 있습니다. 이것은 제거할 수 있는 것처럼 들립니다.

우리 Godot 프로젝트 전체에 강력한 코드베이스를 갖고 싶다면 "덜 장황한" 메뉴는 확실히 없습니다. 최신 코딩 도구는 이름이 길더라도 빠르게 입력할 수 있는 자동 완성 및 기타 지능형 기능을 제공합니다. 또한 이러한 변경 사항에 대한 주장을 읽으면 해당 기능을 사용하는 개발자에게 해당 기능을 덜 모호하게 만드는 목표가 있습니다. 짧은 이름은 달콤할 수 있지만 혼란스럽고 덜 검색할 수 있습니다.

그리고 항상 기억하십시오. 코드 입력은 소프트웨어 개발의 빠른 부분입니다. 나중에 코드를 읽고 이해하는 것이 훨씬 더 중요합니다. 마치 아이를 낳고 키우는 것과 같다.

둘 다 동의하지 않습니다. 저는 Godot 사용자이고 GDScript가 간결하고 빠르게 작성하기 때문에 특별히 Godot를 사용합니다. 두 배 더 길게 만들면 속도 이점이 없어집니다. 두 배는 두 배 더 많이 쓰게 되고 전체 코드 줄을 가로로 보려면 두 배 더 스크롤해야 하기 때문입니다.

코딩할 때 엄청나게 긴 함수나 변수 이름을 입력하고 싶지 않을 것입니다. 이러한 제안된 변경 사항 중 일부는 다른 모든 것을 희생하면서 "명확성"을 위해 매우 긴 함수 및 변수 이름을 추가합니다. 의심이 가는 경우 내장된 도움말을 읽을 수 있습니다. 플러스 프로그래밍은 API를 배우는 것입니다. 이름에 관계없이 처음 사용할 때 항상 함수를 찾습니다. Take printf는 간결하고 간단합니다. Godot에서는 이름을 send_formatted_string_to_standard_out. 로 지정합니다. 모든 사람이 API를 다시 배우도록 강요할 뿐만 아니라 이러한 변경 중 일부는 통일된 비전조차 갖지 않습니다. 제 생각에는 많은 사람들이 모여서 엔진의 한 부분만 교체한 것 같습니다.

예를 들어 배열을 가져 가라.
remove -> remove_at _at는 여기에 무엇을 추가합니까? 이미 remove_value가 있습니다. 또 무엇을 제거할 수 있습니까?
erase -> remove_value 아직 명확하지 않습니다. 문서에서 "배열에서 값의 첫 번째 항목을 제거합니다." 또한 사람들은 전체 배열에서 하나의 단일 값을 제거할 수 있다고 생각할 수도 있습니다. 명확하게 하기 위해 실제로는 remove_first_occurance_of_value 여야 합니다. 이것이 함수가 실제로 하는 일이기 때문입니다. 그래서 당신은 함수를 더 길고 똑같이 혼란스럽게 만들었습니다.

remove 및 erase 두 가지 다른 기능이 있지만 추가 문자를 사용하여 remove 에서 동일한 변형으로 둘 다 전환합니다. 그러나 그들은 다르게 작동합니다. Remove는 특정 인덱스에서 제거하는 반면, Erase는 찾은 값의 첫 번째 인스턴스를 제거합니다.

이것들은 사람들이 코드를 업데이트하도록 강요하는 것 외에는 그다지 유용하지 않습니다.
반전 -> 반전
복제 -> 복제
비어 있음 -> is_empty

고장나지 않았다면 고치지 마세요.

@CarlGustavAlbertDwarfsteinYung 하지만 두 번 입력하지는 않을 것입니다. 처음 3개의 문자를 입력한 후 자동 완성이 시작되고 전체 단어를 입력하는 대신 필요한 것을 선택합니다.

예를 들어 empty -> is_empty 볼 때 다른 이름의 경우 변경이 수행하는 작업에 대한 설명을 제공해야 합니다. empty 를 보면 이것이 무언가를 비우는 방법인지, 무언가가 비어 있는지 확인하는 책인지, 다른 것인지 알 수 있습니까? is_empty 하면 이것이 비어 있으면 true이고 비어 있지 않으면 false인 bool임을 한 눈에 알 수 있습니다. 이름만 봐도 함수나 변수가 무엇을 하는지 알아야 합니다. empty 와 같은 이름으로는 그렇게 할 수 없습니다.

@Feniks-Gaming 나는 비어 있거나 is_empty가 똑같이 혼란스럽고 하나가 다른 것보다 길다고 말할 수 있습니다.

@CarlGustavAlbertDwarfsteinYung empty 는 동사로 읽으면 액션이 될 수 있습니다. is_empty 는 확실히 품질입니다. 물론 그 혼란은 영어 수준에 따라 다를 수 있습니다.

또한, 최신 코드 편집기에서 함수가 send_formatted_string_to_standard_out 라고 하더라도 sfstso 또는 중간 문자의 다른 조합으로 입력할 수 있습니다. 원하는 경우 자동 완성 기능이 제공합니다. 유일한 옵션.

@pycbouh 사람들은 이 엔진을 몇 년 동안 사용하고 있습니까? 그리고 이 엔진의 가장 큰 문제가 무엇인지 알고 있다고 말하는 사람을 한 사람도 본 적이 없습니다. 배열에는 empty 대신 is_empty 있습니다.

너희들은 아무도 원하지 않거나 요구하지 않은 것을 고치고 여기 앉아 있다. 예, 표현이 혼란스럽기는 하지만 실제로 문제가 되지는 않으며 2015년에 이 엔진을 사용하기 시작한 이후로 문제가 된 적이 없습니다. 제안된 변경 사항 중 일부는 매우 환영하며 공정하게는 is_를 사용합니다. 비어 있어도 괜찮습니다. 그러나 일부 변경 사항은 너무 길고 똑같이 혼란스럽습니다. 나는 구체적으로 그 변경 사항이 전부가 아닌 것에 대해 이야기하고 있었습니다.

이 메가쓰레드의 존재는 사람들이 그것을 요구하고 있다는 증거입니다. 이러한 문제는 귀하나 다른 사람에게 중요하지 않을 수 있지만 사람들은 잘못된 이름 지정으로 인해 API를 이해하는 데 문제가 있습니다. 그리고 이것이 이 문제가 수집하는 문제 유형입니다. 이러한 변경 사항의 전반적인 중요성에 대해 믿거나 말거나 이러한 변경 사항을 추적하고 구현하는 것이 다른 개발 시간을 빼앗는 것은 아닙니다.

그리고 당신이 제공하고 설명하려고 시도한 예를 살펴보십시오.

Remove는 특정 인덱스에서 제거하는 반면, Erase는 찾은 값의 첫 번째 인스턴스를 제거합니다.

당신은 그것을 썼고 현재 와 미래의 모든 Godot 사용자를 위해 적어도 조금 더 명확하게 명명을 개선할 이유가 없다고 생각하십니까?

@pycbouh 그리고 실제로 remove_at 및 remove_value 배열의 예도 제공했습니다. remove_value 는 지우기에 대한 설명과 동일하지 않으며 여전히 똑같이 혼란스럽습니다. 어디에서 값을 제거하시겠습니까? 끝에서 값을 제거하고 처음부터 rmeo? 배열에서 모든 값을 제거하시겠습니까?

정말로 변경해야 하는 경우 remove 및 remove_first_occurence 를 사용하여 간결하고 설명적으로 만듭니다.

@pycbouh 나는 그것을 요구하지 않습니다. 이 스레드의 존재는 일부 사람들이 고전적인 프로그래머 패션이 아닌 것을 엔지니어링하고 수정하기 때문입니다. 미래의 사용자는 어떻습니까? 그들은 어떻습니까? 나는 한때 미래의 사용자였으며 API를 배웠습니다. 함수 이름 지정에는 문제가 없었습니다. 의견의 50%는 제안된 변경 사항에 동의하지 않는 사람들입니다. 이러한 변경 사항의 대부분은 소수의 커뮤니티 구성원이 이러한 변경 사항을 모든 사람에게 적용하는 것 같습니다. 제안된 변경 사항에 대해 투표할 수 있습니까?

사실 여기에 제안이 있습니다. API 명명에 대한 변경 사항에는 기여자/기부자/사용자 의견이 포함되어야 합니다. 그들이 모두 동의한다면 나도 동참한다. 투표를 하고 모두가 무엇을 하는지 보십시오. 다른 사람들이 원하는 것을 추측하려고 하지 마십시오. 당신에게 좋은 것이 다른 사람에게는 좋지 않을 수 있습니다.

나는 내가 본 것에서 제안된 변경 사항의 약 50%에 반대합니다.

의견의 50%는 제안된 변경 사항에 동의하지 않는 사람들입니다.

만들어진 통계를 문 앞에 두고 가도 될까요?

제안된 변경 사항에 대해 투표할 수 있습니까?

그것이 바로 토론과 반응을 위한 것입니다.

나는 내가 본 것에서 제안된 변경 사항의 약 50%에 반대합니다.

"나는 이렇게 배웠기 때문에 나 이후의 모든 사람들이 같은 고통을 당하기를 바란다"는 이유로 반대한다면 그것은 명제에 대한 잘못된 비판이며 무시될 것입니다.

당신에게 좋은 것이 다른 사람에게는 좋지 않을 수 있습니다.

같게.

만들어진 통계를 문 앞에 두고 가도 될까요?

전체 커뮤니티에 대한 이 주장이 마음에 드십니까?

이러한 문제는 귀하나 다른 사람에게 중요하지 않을 수 있지만 사람들은 잘못된 이름 지정으로 인해 API를 이해하는 데 문제가 있습니다.

사람들이 어떤 문제를 가지고 있는지 어떻게 알 수 있습니까? 그들에게 물었습니까? 이에 대한 설문조사나 연구 또는 설문지가 있었습니까? 어떻게 이 정보를 알게 되었나요?

저는 0에서 시작하여 API를 배운 그런 사용자 중 하나입니다. 네이밍에 문제가 없었습니다. 모든 API에는 몇 가지 이상한 명명 규칙이 있습니다. 모든 함수는 코드로 작성할 수 있도록 다소 간결해야 합니다.

@pycbouh 여기에 있는 모든 명명 제안이 훌륭하다고 저를 설득하려는 경우 정중하게 동의하지 않을 수 있습니다. 이것은 변경 사항에 대해 논의하는 스레드이며 제안된 변경 사항 중 일부가 필요하지 않거나 요구되지 않을 뿐만 아니라 더 길고 똑같이 혼란스럽다는 것을 말씀드리고자 합니다. 일부는 정말 좋고 환영합니다. 당신과 같은 소수의 사람들이 전체 커뮤니티에 API 이름에 문제가 있다고 생각한다고 해서 모든 이름을 대량으로 바꾸지는 맙시다. 저는 그런 적도 없었고 초보자로 시작했습니다. 그리고 나도 그렇지 않은 소수의 사람들을 알고 있습니다. 저는 이러한 변경 사항 중 일부가 중요하며 전체 커뮤니티 또는 최소한 정식 릴리스 이전에 기여자가 동료 검토를 받아야 한다고 생각합니다.

사람들이 어떤 문제를 가지고 있는지 어떻게 알 수 있습니까? 그들에게 물었습니까?

이 스레드에 있는 대부분의 항목은 여기 GitHub(이 경우 문제가 연결됨) 또는 다른 커뮤니티 또는 개인 채널을 사용하여 문제가 있는 사람들에 의해 생성됩니다. 엔진에서 이름을 바꿀 다른 기능이나 속성에 대해 생각하는 것 외에는 할 일이 없기 때문에 우리가 여기 앉아 우리의 사적인 부분을 핥고 있다고 가정하지 마십시오.

게다가, 여기에 제안된 많은 변경 사항이 실행되지도 않았고 PR이나 다른 활동도 없었습니다. 그것들은 나열되어 있고 그게 전부입니다. PR을 주시하고 기분을 상하게 하는 사람이 나타나면 주저하지 말고 이에 대해 언급하십시오. 그 후 변경 사항을 승인하고 병합하는 것은 Godot의 PM에게 달려 있습니다. 건설적으로 행동하고 원치 않는 수정을 방지할 수 있지만 한 번 말한 것을 잊지 마십시오.

당신에게 좋은 것이 다른 사람에게는 좋지 않을 수 있습니다.

따라서 지금까지 API에 문제가 없었다고 해서 다른 사람들도 문제가 없었거나 앞으로 문제가 없을 것이라는 의미는 아닙니다.

모든 API에는 몇 가지 이상한 명명 규칙이 있습니다.

논의할 협약이 있으면 좋습니다. 그러나 Godot의 일부 API는 오픈 소스가 되기 오래 전에 이름이 지정되었으며 원하는 만큼 신중하지 않을 수 있습니다. 다시 한 번, 여기 사람들이 변경 사항을 제안할 것이라고 가정하지 마시기 바랍니다.

여기서 이런 토론은 하지 말아주세요. 특정 API 변경 사항에 대해 논의하고 싶다면 괜찮지만 여기 제안 사항이 마음에 들지 않는 포괄적인 설명은 도움이 되지 않습니다.

핵심 개발자는 이러한 제안을 하나씩 검토합니다. 많은 사람들이 결국 받아들여지지 않을 가능성이 높습니다.

일시적으로 잠그면 나중에 잠금 해제됩니다.

다음 항목을 목록에 추가할 수 있습니까?

• AnimationPlayer : stop() 을 pause()
• AnimatedSprite : stop() 을 pause() (#31168) (이미 추가됨)
• AnimatedSprite3D : stop() 을 pause() (#31168) (이미 추가됨)
• Tween : stop() 를 pause() , stop_all() 를 pause_all() (PR #41794, #43442)

트윈: stop()의 이름을 pause()로, stop_all()을 pause_all()로 이름을 바꿉니다(#43442).

이것은 #41794에 의해 다룹니다.

@opl- 여기에서도 논의됩니다: https://github.com/godotengine/godot-proposals/issues/287

이러한 전역 범위 RNG 함수가 수행하는 작업을 더 명확하게 할 수 있는 몇 가지 이름 변경:

• seed() -> set_seed() (RandomNumberGenerator와 일치시키기 위해 get_seed() 추가할 수도 있음) – 현재로서는 이것이 setter 함수인지 명확하지 않습니다.
• rand_seed() -> rand_from_seed() – 현재 제공된 시드를 기반으로 실제로 임의의 숫자를 제공할 때 시드 또는 무언가를 무작위화할 수 있는 것처럼 들립니다.

rand_seed() -> rand_from_seed() – 현재 제공된 시드를 기반으로 실제로 임의의 숫자를 제공할 때 시드 또는 무언가를 무작위화할 수 있는 것처럼 들립니다.

시드를 무작위로 지정하는 것을 제외하고. 문서를 읽으십시오.

rand_seed() -> rand_from_seed() – 현재 제공된 시드를 기반으로 실제로 임의의 숫자를 제공할 때 시드 또는 무언가를 무작위화할 수 있는 것처럼 들립니다.

시드를 무작위로 지정하는 것을 제외하고. 문서를 읽으십시오.

죄송합니다. 내 말은 그것이 시드 만 무작위화하는 것처럼 들린다는 것입니다. int를 반환하므로 rand_int_from_seed() 이어야 합니다. 실제로 문서에서는 반환되는 유형을 지정하지 않고 "임의...숫자"만 언급합니다. 인트인가요?

그래서 전달한 시드를 기반으로 새 시드를 생성한 다음 해당 새 시드를 기반으로 새 번호를 생성합니까? 이름 변경에 대해서는 확실하지 않지만, 그런 일이 발생한다면 설명에 약간의 재작업이 필요할 수 있습니다.

그것이 하는 일이 이 방법이 2개의 더 작은 방법으로 분할되어야 하는 것처럼 들리면 이름을 바꾸는 대신 한 가지 일을 하십시오.

컨트롤::pending_resize

미사용.

Object::is_class(name) → Object::inherits_class(name) .

나는 이제 이 방법이 GDScript is ( extends btw)와 거의 동일하다는 것을 이해하지만 C++에는 더 많은 명시성이 필요합니다.

내가 겪은 혼란은 특정 객체 가 상속 없이 기존 유형인지 확인하는 것 입니다.

// Use case: we're only interested in editing "Node2D" classes directly.
node = Object::cast_to<Node2D>(p_edited);
if (!node) {
    return;
}
if (node->get_class() != "Node2D") {
    return; // OK, any class other than "Node2D" is not edited.
}
// vs.
if (!node->is_class("Node2D")) {
    return; // ERROR: derived classes like "Sprite" will also be edited...
}

기본 구현은 모든 곳에서 "상속" 매크로/템플릿을 사용하므로 이 이름을 inherits_class 로 바꾸는 것이 합리적입니다.

https://github.com/godotengine/godot/issues/21461#issuecomment -416155187도

get_class() 및 is_class() 는 일반적으로 나에게 혼란을 줍니다.