مملة للغاية بالنسبة لي ، ولكن أتمنى لمن يصلح instance كـ instantiate حيث يتم استخدامه كفعل.

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

هناك الكثير في فئة التحكم ، يجب أن يكون لكل من get / set نفس اسم المتغير ، فمن المزعج التحقق من الأرصفة في كل مرة تعرف فيها اسم المتغير.

تحتوي فئة TileMap على مجموعة من أساليب getter و setter التي لا تتفق مع خصائص كل منها. في الواقع ، أقترح إعادة تسمية معظم المحترفين والمحدّدين في تلك الفئة ، لذا فهم يتفقون مع خصائصهم بالإضافة إلى التسمية في الفئات الأخرى.

يجب أن يكون Animation.track_remove_key_at_position
Animation.track_remove_key_at_time

أساليب

• OS : يجب تقسيم execute إلى طريقتين مختلفتين ، واحدة للحظر والأخرى بدون حظر.
  مثل الأسماء: execute / exec_process (منع) و spawn_process (بدون حظر) # 19302

يحتوي LineEdit على معلمة new_text على "text_changed" ولكن 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 بسيط ...

وبعد ذلك ستتم إعادة تسميته مرة أخرى لأنه قصير جدًا مثل الموضع-> الموضع: D

هم طويلون بعض الشيء أنت على حق.

لقد لاحظت أن لدى جودو حاليًا اصطلاحات تسمية مختلفة في أسماء الطرق الخاصة به.

في بعض الأحيان ، يتبع ذلك اصطلاحًا شائعًا يمكن العثور عليه في واجهات برمجة التطبيقات للغات مثل C # أو Java ، مثل [action][object]() form: ie)

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

ومع ذلك ، في أماكن أخرى ، فإنه يتبع اصطلاحًا مختلفًا قدره [prefix][action][object]() ، مثل:

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

هم مجرد أمثلة قليلة من بين الكثير.

إذا كان بإمكاننا القيام بتغييرات شاملة في التوافق في وقت ما في المستقبل ، أود أن أرى أنه يمكن إعادة تسميتها لاتباع اصطلاح تسمية واحد محدد جيدًا (آمل أن يكون الأول ، لأنه غالبًا ما يستخدم داخل Godot وخارجه).

ومع ذلك ، في أماكن أخرى ، يتبع اصطلاحًا مختلفًا قدره [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) ، لكن لا يوجد 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">

أو طرق *node_get في ATP:

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 يمكن للمرء أن يجادل بأن الصناديق عبارة عن حاويات حسب التعريف ، ولكن نظرًا لأن لدينا BoxContainer وهو ليس مثل Container ، أعتقد أن الإسهاب لا يزال مبررا.

يحتوي LineEdit على معلمة new_text على "text_changed" ولكن TextEdit لا.

لا أعتقد أنه سيكون من المفيد إضافة new_text إلى TextEdit. في LineEdit ، يحتوي ببساطة على نص LineEdit بالكامل ، وليس النص الذي تم تغييره ، لذلك أجادل بأنه لا يجب أن يكون موجودًا في LineEdit text_changed . ومع ذلك ، من الشائع أكثر أنك تريد استخدام النص الكامل لـ LineEdit عند الإدخال ، بدلاً من القيام بأشياء مع النص الكامل لـ TextEdit متعدد الأسطر عند الضغط على حرف جديد.

@ akien-mga

لم أتحقق من جميع الاستخدامات مرة أخرى ، ولكن مما رأيت هذا النمط من تسمية الطرق ، على الرغم من كونه محرجًا بعض الشيء ، إلا أنه يتبع أيضًا اصطلاحًا محددًا

أنا على دراية بحقيقة أنها اصطلاح تسمية خاص بها. لكنها لا تزال غير شائعة الاستخدام خارج Godot ، كما أنها مربكة بعض الشيء لأنه في بعض الأحيان يتم استخدام نفس الكلمة مثل BlendShape في الأساليب التي تتبع اصطلاحين مختلفين للتسمية.

أنا شخصياً أرغب في رؤيتهم جميعًا أعادوا تسمية GetPrefix* و SetPrefix* أجل التناسق ، ولكن ربما يكون لدى الأشخاص الآخرين آراء مختلفة حول هذا الموضوع.

الأساليب تغيرت في # 16757. يعتبر ترتيب الوسيطة أكثر منطقية ، لكنه يكسر توافق API بين 3.0 و 3.1 (# 19648).

سأرفع # 9128 مرة أخرى: translation في 3D مقابل position في 2D هو اختلاف غريب.
تم رفعه قبل 3.0 ولكن تم إغلاقه بعد أن خرج 3.0 بسبب ... 3.0 خارج.

يجب أن يستخدم OS.execute posix_spawn .

قد يتم إعادة تسمية "الهامش" إلى "الإزاحة" لعقد التحكم.
نظرًا لأن الهوامش سلبية على الجانب الأيمن ، فإن هذا يضلل الأشخاص ، خاصة عند المقارنة مع StyleBoxes

groud أشعر أن الإزاحة عامة جدًا ، على الرغم من أن الهوامش كانت الكلمة الصحيحة لأنها لم تكن موجهة بشكل سلبي على الجانب الأيمن عند تقديمها لأول مرة

groud أشعر أن الإزاحة عامة جدًا ، لكن الهوامش كانت مصطلحًا جيدًا (ولم تكن سلبية عند تقديمها لأول مرة)

حسنًا ، الهامش مضلل الآن بعد أن أصبح سالبًا. الأوفست عام ، لكنه أكثر منطقية. لا أعتقد أنها مشكلة عامة لأنها في سياق عقد التحكم.
على أي حال أنا منفتح على اقتراحات أفضل. أردت فقط ترك هذه الفكرة هنا حيث تم اقتراح تغيير اسم الخاصية هذا بالفعل. انظر هنا على سبيل المثال.

يتم تسمية حجم الصناديق / المكعبات بشكل غير متسق.
يستخدم BoxShape للتصادمات النطاقات.
CubeMesh لها خاصية حجم مع x و y و z ، والتي تمثل كل نصف النطاقات.
يحتوي CSGBox على خاصية Width و Height و Depth والتي يتم تعريفها مثل الحجم x و y و z في CubeMesh.

بالإضافة إلى خاصية size ، في بعض الأحيان يتم استخدام "Cube" وأحيانًا يتم استخدام "Box". سيكون من المنطقي استخدام "Box" لكل شيء حيث يمكن تعيين x و y و z لـ CubeMesh بشكل مستقل ، وبالتالي فهو أيضًا صندوق.

نظرًا لأن لدينا مثل HTML5 و UWP كأهداف ، وهي ليست أنظمة تشغيل بالضبط ، أقترح إعادة تسمية نظام التشغيل إلى النظام الأساسي (PlatformWindows ، PlatformUnix ، ...).
من المنطقي مع تقسيم نظام التشغيل / العرض أيضًا.

من هذا # 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 ستستفيدان حقًا من وجود واجهات برمجة تطبيقات متسقة مع بعضها البعض بحيث يمكن استخدامها (في الغالب) بالتبادل. في الوقت الحالي ، يبدو الأمر وكأنه فوضى في محاولة العمل معهم معًا ، لدرجة أن النظر إلى عقدة واحدة يجعلني مرتبكًا بشأن الأخرى.

@ eska014 بالإضافة إلى ذلك ، فإن الخيار scons هو بالفعل platform . من المنطقي أن تكون متسقًا.

يجب إعادة تسمية إعدادات المشروع display/window/size/test_width و test_height إلى window_width و window_height . يجب أن نفكر أيضًا في إعادة تسمية إعدادات width و height ، ربما render_width و render_height .

خصائص الكاميرا القريبة والبعيدة لها أسماء مختلفة عن أدوات تحديدها (مثل set_znear / set_zfar). يجب تغيير هذا؟

znear و zfar مربكا. لا علاقة له بالمحور Z في فضاء العالم. يمكن تغييره إلى clip_near و clip_far لأنهم يتحكمون في مستويات القطع ، أو فقط near و far .

نعم ، هناك طريقتان لحل هذه المشكلة.

يجب أن نتخلص (أو نناقش بجدية) امتدادات الموارد الثنائية .. (RES_BASE_EXTENSION)

أسماء gdscript_function.cpp و gdscript_functions.cpp متشابهة جدًا ، ما زلت أخلط بينهما. يستحق إعادة التسمية؟ تضمين التغريدة

لقد غيرت https://github.com/godotengine/godot/pull/21425 لإعادة تسمية "decimals" إلى "step_decimals" مع الاحتفاظ بـ "decimals" كاسم مستعار. بافتراض أنه تم دمجه ، يمكننا إزالة "الكسور العشرية" في كسر التوافق التالي ، إذا لم يكن الأمر كذلك ، فقم فقط بإعادة التسمية.

mysticfall في رأيي ، من الأفضل عدم استخدام كلمة "get" في أسماء الأساليب عندما لا تكون ضرورية.

في بعض الأحيان ، تريد أن تكون الخاصية قادرة على الحصول عليها وتعيينها ، مع التحكم في الوصول. في C # ، تسمح لك الخصائص بالقيام بذلك والتحكم في الوصول فقط عن طريق القراءة والتعيين كما لو كان حقلاً ، وهو أمر رائع.

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

ومع ذلك ، في GDScript ، الخصائص ليست شيئًا (؟). يمكننا أيضًا الحصول على اسم طريقة بدون كلمة get. تعيد معظم الطرق شيئًا ما ، لذا من الأفضل أن يكون لديك الحصول على معلومات ضمنية من الإعداد: نظرًا لأن GDScript لها خصائص أقترح استخدامها في كثير من الأحيان. لاحظ أنني لم أتمكن من العثور على أي وثائق حول هذا الموضوع. لقد وجدت وثائق حول كيفية القيام بذلك داخل GDScript باستخدام setget ولكن ماذا عن الإضافة عبر C ++؟

باختصار ، أوافق على أنه ليس من الجيد "الحصول" في أماكن غير متسقة ، ولكن الحل المثالي في رأيي ليس ممكنًا حقًا في الوقت الحالي في خصائص أو يمكننا إزالة "get" و "الاحتفاظ" .

لدىaaronfranke GDScript خصائص بطريقة ما ، حيث يمكن لفئات المحرك تحديد getter و setter (أو فقط getter) وعرضها لـ GDScript كخصائص. ومع ذلك ، فأنا ضد إزالة get و set من الطرق لأن 1) يجعل الاسم أكثر وضوحًا و 2) يميز بين getter و setter. على سبيل المثال ، يبدو Mesh.SurfaceFormat() طريقة "تنسيق السطح" ، وليس طريقة "الحصول على التنسيق". أيضًا ، يمكن تجاهل معظم (إن لم يكن كل) هؤلاء واستخدامهم كخصائص بدلاً من ذلك على أي حال.

الآن ، لا أهتم كثيرًا بـ gdscript_function.cpp و gdscript_functions.cpp . يحتوي أحدهما على فئة GDScriptFunction ، والآخر يحتوي على تعريف وظائف GDScript ، ومن الواضح دائمًا بالنسبة لي أيهما (على الرغم من أنني معتاد على ذلك). إنه أيضًا ليس تغييرًا جذريًا ، لذلك لا داعي لأن يكون هنا.

نعم ، GDScript له خصائص. يتم إنشاء خصائص C # من ClassDB ، حيث تحصل عليها GDScript.

هناك عدة طرق لـ 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 أفضل تغيير apply_impulse إلى (القوة ، الموضع) بدلاً من تغيير add_force إلى (الموضع ، القوة). يعتبر موقع القوة معلمة اختيارية لذا يجب أن تذهب في النهاية. لكن يجب أن يكون لكل القوى والنبضات ناقل قوة.

@ نقطة عادلة

• 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- هو نوع من "Javaism" الذي من الأفضل تجنبه في C #.

كان شاغلي الرئيسي هو استخدام "بادئة المجال" كما في حالة مثل shape_owner_get_shape أو node_get_input_count ، لذلك إذا استطعنا إعادة تطبيقها على أنها خصائص C # مناسبة بدون Get- أو Set- بادئات ، سيكون أفضل.

في ملاحظة جانبية ، اعتقدت دائمًا أنه من الغريب أن تحتوي الخصائص في واجهة برمجة تطبيقات Godot's C # على مجموعة متطابقة من أدوات التسجيل والمحددات ، على سبيل المثال ، Node.Name و Node.GetName() / Node.SetName() .

يبدو الأمر زائدة عن الحاجة بالنسبة لي ، ولكن إذا كان هناك أي سبب يجعلنا نحتفظ بهذه الاتفاقية ، أفترض أننا سنحصل على كل من NodeInputCount و GetNodeInputCount() / SetNodeInputCount() أي حال ، إذا كنا كذلك لإعادة تسمية node_get_input_count كما هو مقترح.

أيها الرجال ، يرجى الاستمرار في المناقشات حول C # API والاتفاقيات المعتادة خارج هذه المشكلة ، والتي تركز على Godot API. لن يتم تكييف واجهة برمجة تطبيقات Godot (C ++ و C و GDScript) من أجل C # ، إلا إذا كانت تمثل أيضًا تحسينًا للغات أخرى.

@ akien-mga لا أعتقد أنه شيء محدد C # هو مناقشة ما إذا كان يمكن إعادة تسمية node_get_input_count إلى شيء مثل get_node_input_count .

لا ، أعني أن أي شيء محدد لـ C # يجب ألا يكون في هذه المشكلة. يمكن أن تكون هناك مشكلة أخرى لأعطال التوافق الخاصة بـ C # إذا لزم الأمر (على الرغم من وجود العديد من IINM).

ماذا عن إعادة تسمية Spatial إلى Node3D؟ لطالما وجدته غريبا

KoBeWi مخطط التسمية الذي يستخدمه Godot حاليًا هو "Thing2D" للأشياء ثنائية الأبعاد و "Thing" فقط للأشياء ثلاثية الأبعاد ، لذا فهو متوافق تمامًا مع باقي الكود ثنائي الأبعاد. بالطبع فإن الشيء المنطقي الذي يجب تسميته بـ "Spatial" سيكون "Node" باتباع نمط إزالة "2D" ، لكن هذا الاسم مأخوذ بالفعل بالطبع.

مخطط التسمية الذي يستخدمه Godot حاليًا هو "Thing2D" للأشياء ثنائية الأبعاد و "Thing" فقط للأشياء ثلاثية الأبعاد

لذا ربما تغير كل شيء ثلاثي الأبعاد إلى "Thing3D"؟ لقد خطرت في بالي أيضًا ، لكنها تبدو مبالغة.
على أي حال ، لقد اقترحت للتو. ليس الأمر كما لو كان مهمًا جدًا. أيضًا ، يعد Spatial2D أسوأ من Spatial.

لذلك ، تقوم String.right () بإرجاع عدد n من الأحرف الصحيحة من موضع معين. ألن يكون الأمر أكثر سهولة إذا أرجع عددًا من الأحرف فقط من اليمين؟

"abcdef".right(2)
بدلا من "cdef" سيعود "ef". سيكون من الأفضل IMO.

كنت أتوقع نفس الشيء.

لدى Python نفس الطريقة التي يحبها معظم المستخدمين لمقارنة GDScript مع Python. من المحتمل أن يربك المزيد من تغييره.

KoBeWi أوافق. لا أرى الفرق بين التنفيذ الحالي والسلسلة الفرعية.

يجبرك Godot substr على تحديد حجم السلسلة إذا كنت تريد كل شيء على اليمين.

Zylann تسمح معظم التطبيقات بحذف المعلمة الثانية. سأعتبر هذه مشكلة من جانب جودو. بالإضافة إلى ذلك ، أفضل استخدام substr لجعل المعلمة الثانية اختيارية بدلاً من طريقة جديدة باسم مختلف.

Zylannneikeq هذه نتيجة مؤسفة لوجود طرق غير للحمل الزائد ، لا توجد طريقة للحصول على مواصفات الطول ولا مواصفات الطول.

aaronfranke Um ، لكن الوسائط الافتراضية موجودة. يمكن احتساب 0 أو -1 على أنه لم يتم تحديد طول.

تحتاج إلى إزالة get_selected_id() من OptionButton حاليًا يتم إرجاع -1 دائمًا. بعد دمج https://github.com/godotengine/godot/pull/21837 get_selected_id() سيعود نفس get_selected() .

هناك الكثير من طرق التوين التي تعود صحيحًا في كل مرة ، ربما يجب أن تكون باطلة.

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

تحتوي عقدة الشجرة على وظيفة get_selected() ويبدو أنها ترجع عنصر TreeItem المركّز. قد يكون من المفيد إعادة تسميته إلى شيء مثل get_active() ، لأن التركيز والاختيار شيئان مختلفان.

يجب أن يكون load_from_globals() في InputMap load_from_project_settings() .

سأضيف: tada: رد فعل على جميع الاقتراحات التي تم دمجها في OP ، للحصول على نظرة عامة أفضل.

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 فربما يمكن إعطاؤهم استخدامات أكثر عمومية.

لاحظ أن نفس العقدة في شجرة التحكم هي 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 ، يعني القطع عمومًا أننا قطعنا شيئًا ما ، والذي لم يتم تنفيذه في أي من الفئتين. يصفه التوثيق بأنه:

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

بعض المقترحات لفصل الصفيف المتواضع:
→ مكرر إما نسخ أو استنساخ.
...
ملاحظة: نسخة طبق الأصل ← نسخ / استنساخ تنطبق على القواميس أيضًا.

والعقد والموارد (أساسًا أي كائن بنية بيانات مكشوفة للبرامج النصية ، afaik).

أفضل كلمة "استنساخ" ، وأعتقد أنها أكثر وضوحًا حول ما تفعله.

صباح! @ akien-mga لم نتمكن من إعادة تسمية instance إلى new بدلاً من instantiate ؟ وجود نفس الواجهة على PackedScene كما يفعل Object s على سبيل المثال يزيل بعض النماذج المعيارية لإنشاء البرنامج المساعد على وجه الخصوص ، ولكن على الأرجح بشكل عام. willnationsdev ما رأيك؟ أعلم أنك واجهت هذا من قبل.

آسف إذا كان هناك بالفعل حديث عن هذا في مكان ما ، لم أتمكن من العثور عليه من خلال البحث.

grabber_area -> slider_progress
slider -> slider_background

أو فقط:
grabber_area -> progress
slider -> background ؟

لا أعرف ما إذا كان هذا قد تمت مناقشته ولكن AnimationPlayer لديه root_node مع 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 ، WORLD_MATRIX في CanvasItem shaders هو في الواقع مصفوفة نموذجية. يوافق reduz على أنه في CANVAS_MATRIX و ITEM_MATRIX .

ضع في اعتبارك إعادة تسمية Array.invert إلى Array.reverse . العكس هو أشبه بالمقلوب أو نوع الشيء "المتبادل". انظر 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 ، يوجد في

parse_input_event (حدث InputEvent)
يغذي حدث InputEvent في اللعبة. يمكن استخدامها لتشغيل أحداث الإدخال بشكل مصطنع من التعليمات البرمجية.

التحليل مضلل ، فسيتم تلقي التحليل ومعالجته ولكن الوصف يشير إلى إرسال أو تشغيل إدخال

وفقًا لـ # 24153 - يستخدم CanvasLayer طبقة لوصف الطبقة التي سيتم رسم العقد عليها. لكن تقريبًا كل عقدة ثنائية الأبعاد تستخدم المصطلح "Z Index" ( z_index ) لوصف (ما يبدو للوهلة الأولى) نفس الشيء. كما اقترح swarnimarun https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 تحسين أسماء الطبقات.

هل سيكون OS.has_feature () / Platform.has_feature () أكثر منطقية في شيء مثل ProjectSettings ، نظرًا لأنها لا تنقل أي شيء حصريًا عن نظام التشغيل؟

يمكن إعادة تسمية set_cell_item إلى set_cell لتوحيد GridMap مع TileMap؟

يمكن إعادة تسمية set_cell_item إلى set_cell لتوحيد GridMap مع TileMap؟

تعال إلى التفكير في الأمر ، ربما يجب أن يكون هناك set_cellv لخرائط GridMaps أيضًا؟

واجهة ARVR:

• ar_is_anchor_detection_enabled -> anchor_detection أو ما شابه
• interface_is_initialized -> is_initialized أو is_interface_initialized

الرسوم المتحركة

• يمكن إزالة play_backwards لأن play يحتوي على منطقي اختياري لذلك.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / تصادممضلع 2D:

• تغيير disabled bool إلى enabled bool.

Bone2D:

• get_index_in_skeleton -> get_skeleton_index

• يمكن إزالة play_backwards لأن play يحتوي على منطقي اختياري لذلك.

سيكون هذا ضارًا لسهولة القراءة ، على الأقل طالما لم يتم تنفيذ # 6866. إنها ليست مشكلة في C # لأنها تدعم المعلمات المسماة.

يجب أن يكون المعرف في id_pressed( int ID ) و id_focused( int 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()
أعتقد أنه يجب تغيير كلمة "إخوة" إلى "أشقاء" ، لأن هذه هي الكلمة المستخدمة في كل مكان لوصف عقد الأشقاء.

ARVRPositionalTracker: get_type() -> get_tracker_type()

• get_tracker_type() هو أكثر وضوحا - get_type() يمكن الخلط بينه و get_class()

• GetType() بالفعل لشيء آخر في C # كما هو مذكور هنا .

تقوم بإرجاع TrackerType ، وهناك أيضًا get_hand() الذي يُرجع TrackerHand ، لذلك يمكن أيضًا تغييره إلى get_tracker_hand() للتوافق إذا رغبت في ذلك.

ARVRPositionalTracker enum 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 () const
إرجاع عنصر لوحة الرسم RID المستخدم بواسطة VisualServer لهذا العنصر.

يجب إعادة تسميتها إلى get_rid() بعد ذلك.

get_canvas_item() محير لأنني بالفعل في العقدة CanvasItem . كما أنه يضمن الاتساق لأن الفئات الأخرى لديها طريقة get_rid() مشابهة بالفعل: CollisionObject ، Resource .

هل يجب تغيير Label إلى TextLabel ؟ لقد أردت عدة مرات الآن وضع كائن نصي ونسيت ما كان يسمى ، لذلك أبحث عن "نص" ولا يظهر إلا RichTextLabel . TextLabel أكثر اتساقًا مع RichTextLabel لأنه لا يزال نصًا ولكن بدون الأغنياء.

كمرجع ، تحتوي الوحدة على Text و TextMesh ، وأنا شخصياً أشير إليها كنص بدلاً من تسمية.

لقد كنت أتساءل أيضًا عن إعادة تسمية Tree و GraphNode إلى TreeView و GraphEditNode .
بالنسبة إلى Tree ، فإن السبب هو أنه واسع جدًا لاسم عقدة GUI عالمية IMO ، وجميع أطر عمل GUI الأخرى التي أعرفها تستخدم TreeView .
بالنسبة إلى GraphNode ، فذلك لأنني عملت على عدد قليل من النماذج الأولية التي تتضمن هياكل رسوم بيانية فعلية ، ولم أتمكن من استخدام Node ولا GraphNode وهو أمر مزعج للغاية.

Zylann نظرًا لأن عُقد Graph مرئية / عناصر تحكم للرسوم البيانية (وليس الأشجار) ، فقد يكون 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 ، وهي تحافظ على التوافق مع الإصدارات السابقة (على ما أعتقد).

تحرير: لم يعد.

يجب أن يكون Area هو Volume ، لأنه ثلاثي الأبعاد. و Area2D يجب أن يكون Area . المنطقة ثنائية الأبعاد بطبيعتها.

GridMap CubeMap . لست متأكدًا من هذا ، مجرد أن "الشبكة" تبدو وكأنها شيء ثنائي الأبعاد بالنسبة لي.

يجب أن يكون عنصر التحكم CheckButton SwitchButton أو شيء من هذا القبيل. إنه أمر محير لأن هناك أيضًا Checkbox . أو ربما يجب إزالته تمامًا. إنه يخدم نفس وظيفة Checkbox على أي حال ، بقدر ما أستطيع أن أقول.

أوافق على إعادة: CheckButton ، والآخرون مجرد مستحضرات تجميل.

أو ربما يجب إزالته تمامًا. إنه يخدم نفس وظيفة Checkbox على أي حال ، بقدر ما أستطيع أن أقول.

تعد UX-wise و CheckBox و CheckButton أشياء مختلفة ، على الرغم من وجود نفس الوظيفة.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ Rodeo-McCabe Area تسمى هكذا للتوافق مع النظير ثنائي الأبعاد ، وأيضًا أحد تعريفات area هو a particular extent of space or surface .
Cubemaps هي صور ثلاثية الأبعاد ، يجب أن تكون صحة بناء الجملة في السياق أو تضيف التباسًا فقط.

grabber_area -> slider_progress
slider -> slider_background

أو فقط:
grabber_area -> progress
slider -> background ؟

يمكن:
grabber_area -> progress_area أو progressed_area
slider -> progress_background ؟

Cubemaps هي صور ثلاثية الأبعاد ، يجب أن تكون صحة بناء الجملة في السياق أو تضيف التباسًا فقط.

@ eon-s عادل بما فيه الكفاية ، لم أكن أعرف ذلك.

تسمى المنطقة بهذا الشكل للتوافق مع النظير ثنائي الأبعاد

المشكلة هي أن النظير ثنائي الأبعاد غير متسق أيضًا . في الرياضيات ، المساحة هي الطول * الارتفاع ، وليس هناك أي بعد ثالث. لذلك ليس من المنطقي أن نقول Area2D ، لأنه يجب أن يكون ثنائي الأبعاد بحكم كونه منطقة. تعريف آخر أكثر رياضية لـ "المنطقة" هو:

السطح المتضمن ضمن مجموعة من الخطوط ، على وجه التحديد: عدد مربعات الوحدة متساوية في القياس مع السطح

وبالمثل ، فإن الفضاء ثلاثي الأبعاد في الرياضيات يسمى "الحجم". لقد كنت مرتبكًا في البداية عندما اكتشفت أن المنطقة كانت في الواقع عقدة ثلاثية الأبعاد ، وبدلاً من ذلك كانت تسمى المناطق "Area2D" بشكل غريب. نظرًا لأن هذا محرك لعبة ، فإن تعريفات الرياضيات هي التي يجب أن نأخذها.

بينما أفهم المنطق ، لا أعرف ما إذا كان سيكون هناك أي فائدة خاصة لتغيير الاسم ، خاصة للأشخاص الجدد. أوافق على أن "الحجم" قد يكون مصطلحًا أكثر ملاءمة لهذا ، لكنني أشعر أن وجود "حجم" للأبعاد الثلاثية و "المنطقة" بالنسبة للأبعاد الثنائية قد يكون أمرًا محيرًا بعض الشيء. بعد كل شيء ، سيتم تسمية الكثير من العقد التي تحتوي على متغيرين ثنائي وثلاثي الأبعاد "

أعتقد أن وجود مخطط التسمية موجود في المقام الأول (بقدر ما توجد بعض العقد التي تلتزم في الغالب فقط بالمخطط) يعني أنه لا ينبغي أن يكون لدينا استثناء للقاعدة ، حتى في حالة وجود مصطلح آخر لمتغير واحد أكثر منطقية ، وإلا فإنه من المحتمل أن يربك المستخدمين.

إذا جاز لي ذلك ... ربما أعيد تسمية Area2D إلى Area ، و Area إلى Area3D ؟

تحرير: يبدو أن النص المُحاط بـ <> لا يظهر إلا إذا قمت بتخطي <>

@ Rodeo-McCabe لدي انطباع بأن نية تسمية العقدة هي التعبير عن الأشياء بلغة بشرية وليست رياضية. لذا لا يُقصد من "المنطقة" أن تكون منطقة هندسية ، بل مكان يجب أن تكون ، مثل داخل مستوى أو مرحلة. IE - المنطقة 1.

لا تحتوي العقدة نفسها بشكل مباشر على أي هندسة أو هي في حد ذاتها هندسة ، لذلك قد يتساءل الآخرون مثلي عن مكان مساحتها / حجمها عند إنشائها ، ثم لماذا يتعين علي إرفاق مناطق وأحجام (أشكال) بمنطقة و الصوت؟

إذا تمت إعادة التسمية لتجنب الخلط بينها وبين المنطقة الهندسية ، فمن المحتمل أن تكون المرادفات هي السبيل للذهاب.

قد يطلق عليهم:

• Region2D / 3D
• Space2D / 3D
• Zone2D / 3D
• Field2D / 3D
• إلخ.

راجع للشغل ، بصرف النظر عن أن هذا المتعقب مخصص فقط للطريقة والخصائص والإشارات (وليس العقد) ، فقد ذكر

يبدو أن الهدف هو ترك الأشياء كما هي الآن ، لذلك قد يتم إرجاع أشياء مثل هذه إلى الإصدار الرئيسي التالي بعد 4.0؟

يرجى ترك هذه المشكلة للمساهمين الأساسيين ، فهي ليست مكانًا لتقديم اقتراحات لإعادة تسمية كبيرة في كل مكان ، والهدف هو إصلاح التناقضات الفعلية التي تجعل واجهة برمجة التطبيقات مرهقة.

التغييرات الموضحة في OP ليست كسرًا كبيرًا للتوافق وسيتم تنفيذ معظمها لـ 4.0 ، ما أشار إليه

سيكون هناك بعض كسر التوافق في 4.0 ، وإلا فلن يطلق عليه 4.0. سيكون ذلك معقولًا وسيكون النقل سهلاً ، ومن المحتمل أن يكون ذلك باستخدام محول لضمان تحويل الخصائص والطرق والإشارات المعاد تسميتها بشكل صحيح إذا تم استخدامها في المشاهد والنصوص. إنه ليس المكان المناسب لمناقشته على أي حال :)

يجب أيضًا أن يسقط Control _set_anchor() البداية "_".

تحتوي قائمة PopupMenu على index_pressed(index) و id_pressed(id) والتي تعمل بشكل جيد ، ولكن أيضًا id_focused الذي يتم إصداره بالفعل مع الفهرس بدلاً من معرف العنصر.

لا توجد مشكلة لهذا حتى الآن ولكن بعد اقتراحه على أكين اليوم يستحق وضعه في القائمة.

إعادة بناء عامل ARVRServer لذلك يطلق عليه XRServer. عندما قمنا بتصميمه ، استخدم المصطلح XR للإشارة إلى كل من VR و AR لم يستخدموا على نطاق واسع حتى الآن. ولا ، لن أذهب إلى MRServer ؛)

هل يجب أن يحتوي RayCast على خاصية "معطل" بدلاً من "ممكّن"؟ يحتوي CollisionShape على "معطل" وهو false افتراضيًا (مما يعني أنه يتم تمكينه افتراضيًا). في المقابل ، الخاصية "Enabled" الخاصة بـ RayCast هي false افتراضيًا ، مما يجعلها معطلة افتراضيًا.

أو ، لاستخدام النموذج الإيجابي (الذي أعتقد أنه أقل إرباكًا بشكل عام) ، هل يجب أن يحتوي CollisionShape على خاصية "ممكَّنة" ( true افتراضيًا) بدلاً من "معطل"؟

Calinou لا Enabled دائمًا. تعيين قيمة منطقية على true لتعطيل شيء ما أربكني كثيرًا.

Calinou أتفق مع Zylann السلبيات المزدوجة محيرة ويجب تجنبها كلما أمكن ذلك. يجب علينا بدلاً من ذلك تغيير الرموز المنطقية "معطلة" إلى "ممكّنة". لا بأس إذا كانت القيمة الافتراضية لشيء ما "صحيحة". أجريت هذه المناقشة في # 17212 و # 21822.

يجب إعادة تسمية الخاصية speed للماوس وأحداث الإدخال باللمس إلى velocity نظرًا لأنها Vector2.

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 لجعل هذا متسقًا عبر جميع الأنواع المضمنة ، ولكن هذا قد ينطوي على بعض كسر التوافق الخطير على ما أعتقد.

أعتقد دائمًا أنها وظيفة لمسح سلسلة في البداية.

تستخدم معظم الطرق clear name في Godot لذلك الغرض.

@ Xrayez ،

تستخدم معظم الطرق اسمًا واضحًا في Godot لذلك الغرض.

أعلم ، بالإشارة فقط إلى حقيقة أن empty فعل وكذلك صفة ، وإضافة is_ يوضح أيهما المقصود.

أؤيد استخدام is_empty عبر جميع العناصر المضمنة لهذا النطاق المنطقي.

في Godot 3.0 و 3.1 ، كان لدينا طرق Set في C #. ومع ذلك ، فإن هذه في الواقع لم تضيف أي وظائف فعلية مقارنة باستخدام مُنشئ ومهمة فقط ، ومع ذلك فقد سمحت للكود بالفشل بصمت ، لذا فقد تم إهمالها. لقد أضفتها في الغالب لمحاولة أن تكون متسقة ، نظرًا لأن طريقة Quat موجودة بالفعل ، والتي جاءت من جوهر لها طرق محددة. لمزيد من المعلومات انظر # 30744

يحتوي GDScript على set_euler و set_axis_angle ، ولكن هناك أيضًا مُنشئون للقيام بنفس الشيء ( q.set_axis_angle(myvec3, myval) يمكن استبداله بـ q = Quat(myvec3, myval) . يحتوي Core أيضًا على هذه الطرق لـ Basis ، لكنهم لم يتعرضوا لـ GDScript.

السؤال إذن ، ما الذي يجب فعله حيال ذلك؟ هل يجب إهمال طرق مجموعة Quat لصالح المنشئين وأن تكون متسقة مع C # ، أم أنه من المفيد إبقائها صريحة بشأن العملية التي يتم إجراؤها؟ إذا كان الأخير ، فهل يجب فضح طرق الأساس أيضًا؟

aaronfranke لطالما وجدت أنه من الغريب أن هؤلاء أسلك المسار السابق إذا كان ذلك ممكنًا.

aaronfranke تتعلق هذه المشكلة بإعادة تسمية الأشياء في واجهة برمجة التطبيقات ، وليس وظائف المحرك أو الأخطاء.

Geometry 's point_is_inside_triangle() إلى is_point_in_triangle() ، لمطابقة الطرق الأخرى التي تُرجع أيضًا bool s في نفس الفصل.

يجب إعادة تسمية TreeItem.get_children() get_first_child() . يجب أن يوضح المستند أيضًا أنه لا يقوم بإرجاع العناصر الفرعية. يتم تكرار الأطفال باستخدام get_next() .

عند العمل على # 31976 ، لاحظت أن قيمة أطلس الظل يجب أن تكون بقوة 2 (لكل من الظلال الاتجاهية والظلال الشاملة / الموضعية). ومع ذلك ، تقبل الأساليب أي قيمة عددية ؛ إذا لم تكن القوة 2 ، فإن الطريقة ستقربها إلى أقرب قوة 2. ربما يجب أن نجعلها تقبل عددًا من القيم ، بحيث يمكن تقديمها بطريقة سهلة الاستخدام في إعدادات المشروع.

وبالمثل ، يجب أن يكون مستوى التصفية متباين الخواص تعدادًا (2 × ، 4 × ، 8 × ، 16 ×) ، نظرًا لأن قيم قوة اثنين فقط هي التي تكون منطقية هنا.

VisualServer 's 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 () بتشغيل مكرر مثل طريقة عمل Directory. اضطررت إلى إجراء الاختبار الخاص بي لمعرفة أن كل ما يفعلونه هو إنتاج نفس المؤشر في كل مرة يتم استدعاؤهم.

يجب إعادة تسمية get_children () لتصبح get_first_child ().

يجب إعادة تسمية get_next () و get_prev () إلى get_next_sibling () و get_prev_sibling ()

ماذا عن إعادة تسمية Engine.iterations_per_second إلى Engine.physics_fps للتوافق مع إعدادات المشروع؟

is_processing :

يعود صحيحا إذا تم تمكين المعالجة.

can_process :

يعود صحيحًا إذا كانت العقدة قادرة على المعالجة أثناء إيقاف شجرة المشهد مؤقتًا

قد يكون من الأفضل إعادة تسمية 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 .

محدث. JSON.serialize ممكن أيضًا ، لكن بعدد الأحرف يكون هو نفسه JSON.stringify . :ابتسامة:

أود أن أقترح ضد كلمة "serialize" لأنها تستخدم عادة للتسلسل الثنائي ، ومثل هذا الإخراج يحتاج إلى خطوات إضافية للوصول إلى هذا النموذج.

نظرًا لأن هذه الفئة بها طريقتان فقط للانتقال بين أنواع 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 بإحضار موجة كبيرة من الأشخاص الجدد إلى Godot نظرًا للأداء الأفضل وتحسينات تحقيقات GI والضجيج العام وما إلى ذلك.

إذا تم إجراء هذه التغييرات باستخدام 4.0 ، فسيحصل هؤلاء الأشخاص على هبوط صعب نظرًا لعدم وجود أي برنامج تعليمي موجود تقريبًا (إلى جانب البرنامج التعليمي "اللعبة الأولى" الرسمي) سيعمل معهم بعد الآن.

إذا تم إجراء هذه التغييرات بعد الإصدار 4.0 ، دعنا نقول في 4.1 ، فستكون رحلة وعرة للغاية لهؤلاء الأشخاص. لقد تعلموا للتو الأساسيات محركًا جديدًا ، وعليهم الآن إعادة تعلمها مرة أخرى. البدايات صعبة ، الاضطرار إلى المرور بهذا مرتين بعد وقت قصير جدًا يمكن أن يكون محبطًا بدرجة كافية للاستسلام تمامًا.

ألن يكون من المنطقي أن يكون لديك إصدار "3.3" أو "3.9" قبل الإصدار 4.0 الذي يحتوي على كل تغييرات واجهة برمجة التطبيقات التي تكسر التوافق ، ومع ذلك يمنح منشئي البرنامج التعليمي وقتًا كافيًا لإنشاء بعض البرامج التعليمية قبل التدفق الهائل المتوقع للمستخدمين الجدد؟

لست متأكدًا مما إذا كان هذا هو المكان المناسب أم لا ، ولكن نظرًا لأن هذا قد يكون حلاً جزئيًا محتملاً لإعادة تسمية المشكلات ، فسوف أقوم بعرضه هنا.
لماذا لا تقوم بإجراء جميع تغييرات إعادة التسمية المطلوبة ثم إضافة لغة جديدة إلى الترجمات التي تسمى GodotOldNames / GodotPre4.0 والتي تحتوي على جميع الأسماء القديمة لجميع التغييرات.
بهذه الطريقة في حالة عدم عثور شخص ما على الأسماء القديمة الموجودة في البرامج التعليمية القديمة ، يمكنه فقط تغيير اللغة إلى GodotPre4.0. هذا من شأنه أيضًا أن يجعل التبديل إلى الأسماء الجديدة أسهل.
هذا لا يحل المشكلة برمتها ولكن قد يعمل مع # 4397.

Anutrix هذا من شأنه أن يضيف الكثير من التعقيد (ماذا عن اللغات غير الإنجليزية؟). علاوة على ذلك ، ليست كل السلاسل المعروضة في المحرر قابلة للترجمة في المقام الأول.

الفيزياء " طبقة " ، تصيير " طبقة "

أتذكر أنني مررت بنفس الارتباك الذي مر به هذا الشخص المسكين خلال الأسابيع القليلة الأولى لي من تعلم Godot.

قد يكون من المنطقي "الطبقة" الفيزيائية ، تقديم "الطبقة" لشخص قادم من التصميم الموجه للكائنات ، لكن الأمر محير للغاية بالنسبة لأي شخص آخر. يستخدم مصطلح "الطبقات" عند وصف طبقات متعددة من الطلاء ، أو معاطف من القماش في نسيج ، أو معاطف من الجلد على بصلة (أو غولة) ، أو طبقات من الرواسب على سطح الكوكب ، ...
يبدو أن الطبقات (الجمع ، مقابل طبقة واحدة) ، تعني ضمنيًا التكديس فوق بعضها البعض في كل تلك الحالات.

بالنسبة للعديد من الأشخاص ، فإن "وضع طبقات" خاصة عند العمل باستخدام رسومات ثنائية الأبعاد أو رسوم متحركة يعني العمل بمقدمة وخلفية وطبقات بين أو فوق. يعتقد الكثير من الناس أن الطبقات هي أفلام شريط سينمائي فوق الخلفية ، بينما في الواقع يستخدم Godot مثل العديد من محركات الألعاب الأخرى طرقًا مختلفة "للفرز" لإنجاز هذه المهمة.

حقيقة أننا نطلق على القواسم المشتركة المجردة التي قد تشترك فيها كائنات فيزيائية أو كائنات تصيير "طبقات" ، بينما في نفس الوقت هذه القواسم المشتركة المجردة لا علاقة لها بمظهر التراص للطبقات المرئية (هذا "الفرز") ، هو ما يجعل هذا محيرة جدا للبعض.

عندما فهمت الاستخدام الحقيقي والمعنى الحقيقي لـ "الطبقة" الفيزيائية ، تجسيد "الطبقة" ، تساءلت على الفور لماذا هذه ليست مجموعة الفيزياء ، مجموعة Render ، ولأكون صادقًا ، ما زلت لا أعرف. من المؤكد أنهم ليس لديهم أي علاقة قابلة للتكديس مع بعضهم البعض ، مما يعني أن ترتيبهم أو علاقتهم ببعضهم البعض غير ذي صلة تمامًا. تسمية الطبقة ، لا يقوم imho بأرشفة أي شيء سوى إرباك الأشخاص ، أو "مجموعة" ، أو "متأثر بالمجموعة" للأقنعة ، أو ربما بعض المصطلحات الأخرى التي لا يمكنني التفكير فيها الآن ستكون أكثر دقة.

طريقة AnimationPlayer
يجب استدعاء .stop (false) .pause (true).
لأن هذا ما يفعله.

المشروع> إعدادات المشروع> العرض> النافذة> الإمتداد> الوضع:

وضع التمدد "2D" يجب أن يسمى وضع التمدد "عرض" أو "غرض عام"
لأنه من المربك أن نسميها ثنائية الأبعاد عندما تعمل أيضًا مع حالات الاستخدام ثلاثية الأبعاد ، ولكن ليس جيدًا لجميع الاستخدامات ثنائية الأبعاد (مثل مشاريع pixelart ، بينما يبدو أن نصف مشاريع Godot 2D تقريبًا هي pixelart.)
سيكون "العرض" أيضًا أكثر وصفًا لما يفعله في الواقع: عرض جميع الرسومات سواء كانت رسومات ثنائية الأبعاد أو كائنات ثلاثية الأبعاد أو شبكات ثنائية الأبعاد أو Line2D أو مضلعات بدقة العرض.
المزيد عن ذلك هنا .

يمكن توضيح حلقة ، تكرار ، ونشوت ، لمشغل الرسوم المتحركة ، والمؤقت ، والعقد المماثلة.

التكرار والتكرار وليس لقطة واحدة ، كلها أشياء متشابهة.

اعتقد انه
is_a_parent_of()
يجب إعادة تسميته إلى
is_parent_of()

KoBeWi انظر المناقشة في # 19801.

اعتقد انه
is_a_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() على التوالي. هذا سيجعلها أكثر قابلية للاكتشاف بفضل الإكمال التلقائي:

قد يتم الخلط بين Calinou print_error() printerr()

من فضلك ، ضع في اعتبارك تغيير اسم طريقة TreeItem.get_children() ، حيث يشير الاسم إلى أن مجموعة من الأبناء هي القيمة المعادة ، عندما يكون الطفل الأول من الناحية العملية هو الذي يتم إرجاعه ، ثم يتعين عليك التكرار على بقية باستخدام get_next() (كما هو موضح في # 19796 #).

نقلا عن Zylann من # 31404:

[إعادة تسمية rpc() / rset() to] remote_call() / remote_set() ؟
هذه الطرق لها أسماء قصيرة أيضًا ، لست متأكدًا مما إذا كان الاسم المستعار كافياً. يجب عليك فعلاً القيام بعدة لاعبين كثيرًا مع الكثير من هذه المكالمات لكل نص برمجي لتبرير المعرفات المكونة من 3 أحرف (وأنا متأكد من أن غالبية الألعاب لا تفعل ذلك).

تحرير (2020-01-03): في الفكر الثاني ، قد يكون call_remote() و set_remote() أكثر منطقية لأن لدينا بالفعل call_deferred() و set_deferred() .

تحرير: لا تمانع في الإغلاق / إعادة الفتح أدناه ، لقد قمت بالنقر بسرعة كبيرة.

الطرق التالية

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
• CPUParticles Flags enum -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker 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 فحسب ، بل إن نظام التسمية الحالي ، بسبب الفرز الأبجدي ، يتسبب في عكس ترتيبها. هذا مربك بعض الشيء عندما تقرأ المستندات لأنه من الواضح أن التدفق الزمني للعمليات هو الدخول أولاً ثم الخروج. كل ما في الأمر هو تحسين قابلية القراءة والاتساق لتغييرها.

لقد لاحظت عدم وجود خاصية Texture.size. كنت بحاجة إلى استدعاء Texture.get_size () getter بدلاً من ذلك.

سألت في Discord عما إذا كان هذا مقصودًا أم لا. كان أحد الاقتراحات هو النشر هنا للسؤال عما إذا كان هذا يحتاج إلى تحويل إلى خاصية ، وكان الاقتراح الآخر هو أنه نظرًا لعدم وجود "محدد" لهذا ، فإن استخدام get_size () هو السلوك المتوقع حاليًا.

jmbjr هل لدينا أي خصائص للقراءة فقط

نعم ، أعتقد أنك إذا كنت ستبدأ في دعم الخصائص المكشوفة للقراءة فقط ، فأنت بحاجة إلى علامة USAGE لها ولإضافة رمز المحلل اللغوي / المترجم GDScript الذي يدعمها.

SoftBody لديه areaAngular_stiffness والذي يجب أن يكون area_angular_stiffness (نفس الشيء بالنسبة لجميع الطرق ذات الصلة).

Input.joy_connection_changed (الطريقة) لا يجب أن تتعرض لواجهة برمجة تطبيقات البرمجة النصية ، حيث يتم استدعاؤها داخليًا عن طريق رمز التعامل مع عصا التحكم في كل نظام أساسي.

@ akien-mga عندما رأيت هذه الطريقة لأول مرة ، في وقت مبكر جدًا بعد اكتشاف Godot ، كانت لدي أفكار مماثلة ، ثم تذكرت كيف بنى Kojima بعض أساليب اللعب الأسطورية في MetalGearSolid حول أسلوب يجب أن يكون مشابهًا جدًا لهذا الأسلوب وفكرت: " حتى أن جودو يعطيني وسيلة لتخطي الجدار الرابع تمامًا مثل كوجيما بسطر واحد من التعليمات البرمجية ، ما مدى روعة ذلك! "

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 لاستخدام الفعل الماضي. يبدو الإصدار الحالي إلزاميًا إلى حد ما ، على عكس طبيعة إعادة الاتصال للإشارات.

تناقض آخر مع إشارات الجسم الفيزيائية

منطقة:

area_shape_entered (int area_id، Area area، int area_shape، int self_shape int)
area_shape_exited (int area_id، Area area، int area_shape، int self_shape int)
body_shape_entered (int body_id، node body، int body_shape، int area_shape)
body_shape_exited (int body_id، Node body، int body_shape، int area_shape)

أفترض أن area_shape في هذين الأخيرين يجب أن يكون شكلًا ذاتيًا؟ أو ...

جسم متماسك:

body_shape_entered (int body_id، Node body، int body_shape، int local_shape)
body_shape_exited (int body_id، Node body، int body_shape، int local_shape)

هنا يطلق عليه local_shape ...

FrederickDesimpel على حد علمي ، يمكن إعادة تسمية الحجج دون كسر التوافق. لا تتردد في فتح طلب سحب لهذا:

في البديل:

حقيقي -> تعويم
لا شيء -> لاغية؟

أنا أحب الاسم "الحقيقي" شخصيًا ، نظرًا لأن مصطلح "تعويم" غالبًا ما يستخدم لعوامات 32 بت على وجه التحديد ، ولكن Variant's real هو مزدوج ، ومعظم المحرك يستخدم real_t والذي يمكن أن يكون أيضًا.

ملاحظة: لقد قمنا بالفعل بإعادة التسمية بالعكس في عام 2017.

هل اعتبرنا إعادة تسمية هذه:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

تمت إعادة تسمية Zylann SpatialMaterial بالفعل إلى StandardMaterial3D في الماجستير.

هل يجب تغيير قيم limit_ في Camera2D إلى Rect2i ؟ الآن هم فقط أربعة ints.

تحرير: يمكن أيضًا تغيير هامش السحب إلى Rect2 .

String::begins_with إلى String::starts_with .

كما هو الحال في لغات البرمجة الجادة (جافا ، بايثون ، إلخ).

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 كاختصار لـ draw_arc من 0 إلى TAU .

Goutte في اللغة الإنجليزية ، يمكن أن تشير كلمة "دائرة" إلى دائرة مجوفة أو دائرة مملوءة. أعتقد أن الاسم الحالي أكثر قابلية للاكتشاف ، لذا لن أغيره.

في اللغة الإنجليزية ، يمكن أن تشير كلمة "دائرة" إلى دائرة مجوفة أو دائرة مملوءة.

لا أجد أي شيء يدعم هذا . هل لديك أي مصدر لهذا الادعاء أم أنه شعور داخلي؟

فيما يتعلق بقابلية الاكتشاف ، لا يزال بإمكاننا الحصول على draw_circle ، فهو ببساطة سيرسم دائرة وليس قرصًا.

لا أجد أي شيء يدعم هذا . هل لديك أي مصدر لهذا الادعاء أم أنه شعور داخلي؟

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

1 ب: مستوى مغلق (انظر مدخل المستوى 6 بمعنى 2 ب) منحنى كل نقطة منه متساوية البعد (انظر المعنى 1) من نقطة ثابتة داخل المنحنى
1 ج: السطح المستوي الذي يحده مثل هذا المنحنى

(1 ب) دائرة رياضية (محيط) ، (1 ج) قرص رياضي (سطح).

فيما يتعلق بواجهة برمجة التطبيقات (API) ، من الأسهل استخدام IMO أن يكون لديك draw_rect(bool filled) و draw_circle(bool filled) أكثر من draw_rect() ، draw_filled_rect() ، draw_circle() و draw_disk() (أو ما هو الاسم الرياضي لمستطيل ممتلئ؟).

تحرير: في الواقع draw_circle() لايوجد filled حجة بعد. أعتقد أننا يجب أن نضيف واحدة ، بحيث يمكن استخدامها لرسم كل من الدوائر (المحيط) والأقراص (الدائرة المملوءة).

جميل شكرا. معظم طلابي فرنسيون وكانوا جميعًا في حيرة من أمرهم ، وكذلك أنا ، وألقوا باللوم على جودو ولم أستطع السماح لهم بذلك بالطبع.

ما هو الاسم الرياضي لمستطيل ممتلئ؟

هذا سؤال جيد. كل ما يمكنني العثور عليه هو "منطقة المستطيل" أو "المستطيل الداخلي" ، ولا شيء مناسب. حتى أن الويكي تنص على أن معظم الناس يسيئون استخدام المصطلح مضلع ليعني الجزء الداخلي من المضلع ، دون تقديم كلمة أخرى له.

أعتقد أن حجة filled يمكن أن تساعد في تخفيف الغموض ، لكن سيكون من الصعب تحديد مكان وضعها في قائمة الحجج.

Goutte ولكن سيكون من الصعب تحديد مكان وضعها في قائمة الحجج.

نظرًا لأنها وسيطة اختيارية (لها قيمة افتراضية) ، وكذلك للتوافق مع draw_rect ، يجب أن تذهب في النهاية.

هناك حالات يتم فيها الحكم على عقد التحكم كعقد مشروطة. https://github.com/godotengine/godot/search؟q=modal&unscoped_q=modal في الغالب فيما يتعلق بوظيفة Viewport.get_modal_stack_top ()

أساليب EditorInterface 's 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 أليس Solid Rectangle بديلاً عن المستطيل المملوء؟

هل سيتم تحديث OP بالاقتراحات المنشورة بعد يونيو 2019؟ أتفهم أن هذا يتطلب الكثير من العمل ، ولكن هذا النوع من أجهزة التتبع مثالي أيضًا للمساهمين للتعامل معه معًا. وأفترض أن هذا هو الوقت الذي يمكننا فيه العمل على إعادة تسمية المزيد من الأشياء؟

تحديث OP قد يعني أيضًا أن الاقتراح المنشور مقبول من قبل الفريق.

Anutrix "شغل" هي أفضل من كلمة "صلب" ، لأن كلمة "صلب" يمكن أن تعني "ليست سائلة أو غازية".

pycbouh سيكون أيضًا فكرة جيدة لربط العلاقات العامة لكل قضية إذا كان هناك مشكلة. يقوم البروتوكول الاختياري بهذا بالفعل ، ولكن ليس للتعليقات الموجودة أدناه.

لا أعرف ما إذا كان قد تم رفعه ، لكنني لم أدرك عدد المرات التي أتوقف فيها لإلقاء نظرة خاطفة على المستند لهذا المستند:

• 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 أيضًا.

GDScript

range_lerp () = الخريطة ()
البذور = set_seed ()

من المحتمل أن تكون الخريطة () محجوزة لميزات البرمجة الوظيفية الجديدة.

Vector2.tangent() في المستندات على النحو التالي: Returns a perpendicular vector. ، هذا هو تعريف orthogonal أو orthonormal إذا تم تطبيع المتجه المرتجع. نظرًا لأن Vector2.tangent() يُرجع متجهًا غير طبيعي ، أقترح علينا إعادة تسميته إلى Vector2.orthogonal() أو حتى Vector2.perpendicular() إذا كان لدى الأشخاص شيئًا ما ضد التسمية الرياضية أو ربما حتى Vector2.normal() ، ولكن قد يختلط الأمر على الناس بين normalized() و normal()

قصصية من ناحيتي ، ولكن في المرة الأولى التي بحثت فيها عن هذا ، كانت عمليات البحث الأولى في المستندات عن _عامودي _.

يمكنك أيضًا الاحتفاظ بـ .tangent() كاسم مستعار لـ .perpendicular() ، أليس كذلك؟

لا أحب الاسم orthogonal لأنه ليس كلمة إنجليزية شائعة مقارنة بالكلمات الأخرى. لم أشاهد مشكلة في tangent قبل ، لكني أعتقد أن perpendicular هو اسم أفضل على أي حال.

نعم ، المتعامد نادر. أنا أصوت لصالح .perpendicular () ولكن مع الاحتفاظ بـ tangent () المستعار للمواطن وكذلك ، فهو أقصر.

@ Zireael07 أفضل إذا كان لدينا طريقة واحدة فقط للحصول على الظل. لا أعتقد أنها عملية شائعة جدًا بعد كل شيء.

ستندهش من عدد المرات التي أستخدمها في نصوص procgen الخاصة بي :)

لم أكن أتوقع أن يؤدي هذا إلى نشوء نقاش ، لكنني شخصيًا ضد الاحتفاظ بـ Vector2.tangent() لأنه استخدام غير صحيح لمصطلح الرياضيات المعتاد. منتج Vector2.tangent() خاطئ بالتعريف. اسم هذا الموضوع هو كسر التوافق المخطط التالي لذلك لا أرى أي سبب يدعو إلى الانحناء للخلف للحفاظ على التوافق. أنا شخصياً بخير مع Vector2.perpendicular() .

الاقتراح: اجعل معلمة find_node() owner خطأ افتراضيًا.

الاقتراح: أعد تسمية أساليب / إشارات 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_base_type() لتصبح get_instance_native_class() ل حافظ على اصطلاح التسمية ووضح أنه المثال وليس معلومات البرنامج النصي.

أعتقد أنه يجب إعادة تسمية autotile_coord (الخصائص والطرق) لـ TileMap لـ tile_coord أو tile_coordinate لأن كلا من AUTO_TILE و ATLAS_TILE استخدم هذا والاسم قد يكون محيرًا للمستخدمين الجدد. سيحتاج محرر المستندات أيضًا إلى تحديث. يمكنني إجراء هذا التغيير إذا لم تكن هناك مشكلة.

ضع في اعتبارك إزالة الوسيطة new_text من LineEdit.text_changed نظرًا لأن لها نفس سلوك LineEdit.text .

ضع في اعتبارك أيضًا إضافة old_text إما بالإضافة إلى أو كبديل لـ new_text .

ذات صلة بـ https://github.com/godotengine/godot/issues/16863#issuecomment -394745886

إعادة تسمية " طبقات التصادم" ، " طبقات VisualInstance" ، "عرض طبقة " ، إلخ
" مجموعة التصادم" ، " مجموعة VisualInstance" ، " مجموعة العرض " ، " مجموعة الضوء"

يظهر الارتباك حول سبب عدم تكديس تلك "الطبقات" مثل ساعة التوقيت على قنوات المجتمع.

لاحظ أنها تسمى طبقات في Maya و Lumberyard و Unity.

فقط لأن شخصًا آخر يفعل شيئًا لا يعني أنه لا يزال غير سبب
الارتباك وهي فكرة جيدة.

في يوم الإثنين 18 مايو 2020 ، الساعة 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 ، ألا يجب أن نعكس مقياسه بحيث يتم تكبيره عند زيادة القيمة؟

سيؤدي هذا إلى كسر التوافق تمامًا مثل إعادة تسمية الخاصية. إذا سلكنا مسار "المقياس العكسي" ، فلا يمكن إصلاحه تلقائيًا ، لسوء الحظ. ومع ذلك ، فقد يؤدي ذلك إلى ارتباك أقل على المدى الطويل.

CalinouKoBeWi هل هناك حالة الاستخدام لاستخدام هذا العقار التكبير على الرغم مباشرة، أو أن الجميع بحاجة إلى عكس ذلك في كل مرة لتطبيقها على نطاق و؟

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 . (بينما يمتلك الأعضاء الآخرون 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 الذي لم أذكره ولم يتم الكشف عنه ، ولكن يتم استخدامه داخليًا.

في النهاية أعتقد أنه يجب النظر إلى هذا الفصل بأكمله. يحتوي Viewport على 4 أعضاء مختلفين من Transform2D و 4 أعضاء Rect2 (i) و 9 أعضاء Vector2 (i) و 2 أعضاء Transform (3D). هذا هو بالفعل 264 بايت (مع عوامات أحادية الدقة) من هياكل البيانات فقط التي تخزن معلومات التحويل ، إذا أضفت جميع المؤشرات ومن المحتمل أن يكون أقرب إلى 1 كيلوبايت. ربما يحتاج Viewport إلى كل هذا ، ولكن يبدو أنه معقد للغاية ، وعلى الأقل يجب أن تكون هناك تعليقات (هناك عدد قليل جدًا في هذا الملف).

هل يجب إزالة Node2D / Node3D to_global و to_local ؟ لقد قدمت ملاحظات على # 38902 التي اقترحت إضافة طرق تعمل فقط مع الأساس ، ولكن هناك بعض المشكلات المتعلقة بها.

في المشاريع التجريبية ، لا يتم استخدام to_local أي مكان ، ويعيد $ grep -RIn "to_global" 5 نتائج فقط ، وكلها موجودة في واجهة المستخدم الرسومية في العرض التوضيحي ثلاثي الأبعاد ، ويمكن تحسين أداء العرض التوضيحي عن طريق التغيير هذا بحيث يخزن التحويل العام مؤقتًا ويستخدم xform بدلاً من استخدام to_global .

باختصار ، فإن الاهتمام بهذه الأساليب هو أنها تستخدم بشكل غير مألوف ، وأيضًا أنها تشجع كتابة التعليمات البرمجية التي تؤدي أداءً سيئًا لأنها تعيد حساب التحويل العالمي عدة مرات.

27509

AnimationPlayer 's 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 بعد إسقاطه لبضعة أشهر قد أعطاني منظورًا جديدًا لواجهة برمجة التطبيقات ، أود أن أقول ،

كلما كان ذلك أكثر وضوحا كلما كان ذلك أفضل. يعد تذكر واجهة برمجة التطبيقات لكل شيء أمرًا صعبًا في حد ذاته ، ويبدو الإسهاب في تسمية الوظائف بمثابة تغيير عاقل.

KoBeWi أن تكون قادرًا على معرفة ما تفعله باستخدام اسم الوظيفة بدلاً من الاضطرار إلى تذكر إضافة حقل آخر أو أثناء قراءة الكود (بعد نسيان / عدم معرفة هذا الجزء من واجهة برمجة التطبيقات) هو موضع تقدير كبير.

لذلك ما زلت أفضل وظيفة مختلفة ، حتى لو كانت الوظيفة الأخرى تستدعي الأولى بحجج مختلفة أو شيء من هذا القبيل.

EditorInterface.get_editor_viewport() => get_editor_main_container()

لا تقوم هذه الوظيفة بإرجاع Viewport ، فقط 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. لقد أضفت بعض النقاط الأخرى هناك.

GetSceneInstanceLoadPlaceholder() في Node خاطئًا جدًا ، أولاً لا يُرجع عنصرًا نائبًا كما قد يوحي الاسم ، ولكن منطقيًا وثانيًا هذا تسرب تفاصيل التطبيقات الموروثة إلى الفئة الأساسية بدون متطلبات حقيقية (اختبار للنوع من العقدة ممكن بطرق أخرى)

RayShape → SeparationRayShape ، كما هو مقترح في البداية في godotengine / godot-plans # 711.

ماذا عن إزالة sort_custom وجعل sort يأخذ خيارًا قابلاً للاستدعاء؟

هل يجب إزالة OS.get_ticks_msec() و OS.delay_msec() لصالح OS.get_ticks_usec() و OS.delay_usec() على التوالي؟ هذا من شأنه تجنب وجود طريقتين لتحقيق نفس الشيء. إذا كنت بحاجة إلى قيمة بالمللي ثانية ، فيمكنك ضربها أو تقسيمها على 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 People طلبات سحب لإعادة تسمية الأشياء بشكل منتظم. يتم ذلك بشكل تدريجي وليس دفعة واحدة.

الملمس (Texture2D) والصورة

• يجب تسمية get_data () في Texture (Texture2D) باسم get_image () ويجب تسمية get_data () في الصورة get_bytes () لتصف نفسها بنفسها.

IMO: get_image نعم ، get_bytes لا.

texture.get_image().get_data()

شبكة / MeshInstance

• في Mesh تحصل على / تعيّن المواد بهذه الطرق:
  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 .

ليس تعيين / الحصول على "عادي" ، لديهم فهرس للسطح المستهدف (إنه متجه داخل فئة Mesh)

Array يجب إعادة تسمية empty() إلى is_empty() لتوضيح أنه منطقي بشكل أفضل

String علينا إسقاط find_last() لصالح rfind() . ليس بالضبط إعادة تسمية ، ولكن لا يزال الأمر يستحق مناقشة أي واحد يجب الاحتفاظ به.

للأرقام الفردية ، لدينا stepify . بالنسبة إلى Vector2 / Vector3 ، لدينا snapped .

يفعلون نفس الشيء ، المتجهات تستدعي stepify لكل مكون. يجب اختيار اسم واحد ولكن أيهما؟

الاستطلاع:: القلب: = يجب أن يكون كلاهما stepify ،: صاروخ: = يجب أن يكون كلاهما snapped ،: -1: = عدم إعادة التسمية.

يمتلك AABB intersection ، بينما يحتوي Rect2 على clip . انهم يفعلون نفس الشيء. يجب اختيار اسم واحد ولكن أيهما؟

الاستطلاع:: القلب: = يجب أن يكون كلاهما intersection ،: صاروخ: = يجب أن يكون كلاهما clip ،: -1: = عدم إعادة التسمية.

aaronfranke نعم ، لقد اقترحت سابقًا اسم intersection في https://github.com/godotengine/godot/issues/16863#issuecomment -449628319. لدينا بعد ذلك intersects والذي يمكن إعادة تسميته إلى overlaps في Rect2 ، لكن لست متأكدًا من AABB بخصوص intersects → overlaps إعادة التسمية.

أعتقد أنه يجب إعادة تسمية find_node و / أو get_node لأن الأسماء لا تشير إلى وجود اختلافات بينهما على الإطلاق.
نظرًا لأن find_node تنظر فقط إلى الأطفال ، فربما find_child_node؟
لست متأكدًا من الاسم البديل الجيد لـ get_node. كانت فكرتي الأولى هي get_tree_node حيث يمكن أن تحصل على عقدة من أي مكان في الشجرة ، ولكن يمكن أيضًا استخدامها خارج شجرة المشهد مع المسارات النسبية.

أجد get_node جيدة، ولكن find_node يمكن تسميته find_child

MuffinManKen أعتقد أن get_node مفهوم تمامًا لأنه ، كما ذكرت ، يمكنه جلب أي عقدة ، في أي مكان ، طالما أنها متصلة بنفس الشجرة مثل العقدة المحددة ، بغض النظر عما إذا كانت جزءًا من شجرة المشهد أم لا.

Coldragon لست متأكدًا من أنني أحب إعادة تسمية find_node إلى find_child أيضًا ، لأنه يمنحني الانطباع بأنه يعمل فقط مع الأطفال المباشرين لسبب ما. سيكون البديل هو أن يطلق عليه find_descendant أو شيء من هذا القبيل ، لكن هذا كثير الكلام / معقد للغاية. كما أن قطعها إلى find() لا معنى له لأنه من غير الواضح بعد ذلك ما الذي نبحث عنه. على هذا النحو ، أعتقد أنه ما لم يتم البحث عن بديل آخر ، يجب أن يبقى find_node كما هو أيضًا. يجب أن تحتوي فقط على اختلافات موثقة واضحة في سلوك مستندات API.

في Godot 3.1 ، أضفت علامة ميزة standalone والتي يتم تقييمها إلى true عندما يتم تشغيل المشروع من نموذج تصدير ثنائي (تصحيح أو إصدار). العكس هو editor ، والذي يتم تقييمه إلى true عندما يتم تشغيل المشروع من محرر ثنائي.

ومع ذلك ، مع مرور الوقت ، أعتقد أنه سيكون من الأفضل إعادة تسمية standalone إلى runner لأنه أقصر و أكثر بقليل من الشرح الذاتي. ماذا تعتقد؟

ماذا عن exported أو release ؟

aaronfranke exported يشير إلى أن المشروع قد تم تصديره ، وهذا ليس هو الحال بالضرورة. يمكنك استخدام نموذج ثنائي لقالب التصدير لتشغيل مشروع مباشرة من ملفاته المصدر ، طالما تم استيراد الأصول مسبقًا.

أيضًا ، release مستخدم بالفعل لثنائيات وضع التحرير (على عكس debug ، والذي يستخدم للثنائيات في وضع التصحيح).

runner لا يبدو واضحًا جدًا بالنسبة لي. standalone ما يرام. إزالته ستكون جيدة أيضًا ، لأنه يمكنك فقط استخدام !OS.get_feature("editor") .

إزالته ستكون جيدة أيضًا ، لأنه يمكنك فقط استخدام !OS.get_feature("editor") .

لا يمكن استخدام هذا لتجاوز إعدادات المشروع بالرغم من ذلك ، نظرًا لعدم وجود محدد .not هناك. من المحتمل أن يكون ذلك ممكنًا من خلال التبديل بين الإعداد الافتراضي وتجاوزه ، لكنه يبدو أكثر تعقيدًا.

لماذا لا يكون app أو game على عكس editor إذن؟ أم أن ذلك سيكون أكثر إرباكًا؟ ربما يكون لديك علامة ميزة لـ no-editor لتكون أكثر وضوحًا؟

يشيرwillnationsdev game إلى أنه لا يمكن استخدام Godot إلا للألعاب. يستخدم العديد من الأشخاص برنامج Godot للتطبيقات التي لا تتعلق باللعبة بنجاح ، لذلك أفضل استخدام مصطلح أكثر شمولاً:

أيضًا ، لا تحتاج إلى شرح ذاتي: قد يعتقد الناس أنها لا تزال تنطبق على المشاريع التي يتم تشغيلها من المحرر (أنت تدير "اللعبة" من المحرر بعد كل شيء). الشيء نفسه ينطبق على app .

ماذا عن "المستقل"؟

يوم السبت ، 25 يوليو 2020 ، 5:49 صباحًا Hugo Locurcio ، [email protected]
كتب:

willnationsdev https://github.com/willnationsdev تشير اللعبة إلى Godot
لا يمكن استخدامها إلا للألعاب ، وهو ما ثبت أنه ليس كذلك 🙂

أيضًا ، إنه ليس حقًا توضيحيًا: قد يعتقد الناس أنه لا يزال
ينطبق على المشاريع التي يتم تشغيلها من المحرر. الشيء نفسه ينطبق على التطبيق.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

MuffinManKen independent لا يبدو واضحًا جدًا بالنسبة لي.

من المحتمل أن يكون Editor vs Standalone هو التسمية القياسية (واحد على الأقل أراه في العديد من المحركات المختلفة) لذلك لا يوجد سبب لإعادة اختراع عجلة imho.

لا يقتصر Get_node على الحصول على أحفاد ، لذلك سيكون ملف
اسم مضلل. الطريقتان تحتاجان إلى أسماء مختلفة جدًا لأنهما
فعل مختلف جدا.

يوم السبت 25 يوليو 2020 ، الساعة 3:14 مساءً ، أسئلة golddotasks ، <
[email protected]> كتب:

أتذكر الارتباك الذي كان لدي لفترة طويلة في البداية
find_node و get_node. أود حقًا find_descendant و
get_descendant ، لأن هذه ستكون صحيحة وغنية بالمعلوماتwillnationsdev
https://github.com/willnationsdevColdragon
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-plans # 397 ، ولكن ربما يكون هذا بعيد المنال.

تحرير: بناءً على مزيد من التفكير ، فإن segment لن يكون له معنى كبير من حيث RayCast node ، لكنه منطقي من حيث 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 ، إلخ.

تحرير Bugsquad: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool ، float ، int هي الأنواع / الفئات الوحيدة التي تبدأ أسماؤها بحرف صغير. أعتقد أنه يجب إعادة تسميتها (في GDScript) إلى Bool ، Float ، Int . سيؤدي هذا تلقائيًا إلى إصلاح مشكلة تمييز بناء الجملة بشكل غير صحيح.

ويجب استخدام bool و float و int فقط للوظائف المضمّنة الشبيهة بلغة Python من صفحة GDScript (تشمل أيضًا 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 هل من الاختلاف الأساسي أن ينعكس في اسم النوع؟

(بالنسبة لي ، "البدائية" هي "بسيطة" وليست "قطعة واحدة".)

لا أريد أن أفسر هذا لصالحي ، لكن:

يتم كتابة أسماء الأنواع الأولية بأحرف كبيرة. :ابتسامة:

فيما يلي المصطلحات كما أفهمها:

| اكتب الاسم | النوع البدائي | نوع القيمة | نوع متغير | النوع المضمن |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| int | نعم | نعم | غير متاح | نعم |
| Vector2 | لا | نعم | غير متاح | نعم |
| عقدة | لا | لا | نعم | نعم |
| سلسلة | لا | لا | لا | نعم |

بغض النظر ، لن يتم تغيير هذه الأسماء. إنها جيدة كما هي ومألوفة للمبرمجين من مختلف اللغات. يجب أن ننهي المناقشة هنا لتجنب ملء هذا المتعقب بمناقشة لا طائل من ورائها.

عمود النوع المتغير خاطئ: فقط مشتق من الكائنات والقاموس والصفيف قابل للتغيير. (قد يبدو 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

بحاجة الى تصحيح.

لقد انطلق PS I من مبدأ "كلما قل عدد الأساليب المتشابهة ، كان ذلك أفضل".

غالبًا ما تكون معلمات dalexeev المنطقية أقل قابلية للقراءة من استخدام طرق مختلفة ، نظرًا لعدم وجود سياق في true و false .

نعم ، لكن الاتساق سيكون جيدًا أيضًا. تخلص من المعلمات المنطقية في InputEvent إذن؟

Calinou في معظم الحالات ، لا تحتاج إلى التحقق من أحداث الصدى.

لا أرى هذا على أنه مشكلة كبيرة. عند كتابة الرمز ، يظهر تلميح الوسيطة. عند قراءة الكود ، يمكنك استخدام Shift + Click. يسهل تذكر وسيطات الدوال المستخدمة بشكل متكرر (على سبيل المثال ، String.split ).

علاوة على ذلك ، تم العثور على 208 وسيطة منطقية اختيارية في الدليل doc/classes (هذا هو النواة فقط ، كما أن 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 + Click.

ليس إذا كنت تشاهد الاختلافات على GitHub. إذا تطلب الرمز أن يكون IDE قابلاً للقراءة ، فهذا ليس رمزًا جيدًا.

aaronfranke بالنسبة

هناك العديد من الحالات التي تحتاج فيها إلى التحقق من الضغط على أحد المفاتيح وليس فقط إذا تم الضغط عليه للتو.

في كثير من الأحيان ، ولكن ليس أكثر من بدون صدى.

وجود ثلاث طرق ( is_action_just_pressed ، is_action_just_released ، is_action_pressed ) أمر محير لأنك تتوقع وجود طريقة is_action_released .

يضيف. ما هو الخيار الأسهل على الأقل بصريًا؟

is_action_released باستخدام not is_action_pressed . هذا ليس صحيحًا بالنسبة لطرق just .

كما ذكر أعلاه ، يجب تجنب الأكياس الخام. علم مثل INPUT_ALLOW_ECHO / INPUT_NO_ECHO سيكون أفضل بكثير من منطقي.

dalexeev لن يؤدي ذلك إلا إلى الارتباك. is_action_pressed() و echo هما شيئان مختلفان. يمكنك التحقق بنفسك من استلام أحداث الصدى بعد تأخير طفيف بعد الضغط الأول ، بينما لا يوجد تأخير في 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 ما تقترحه غير صحيح. عندما نتحدث عن أحداث الصدى ، فإننا نتحدث عن أحداث لوحات المفاتيح المتكررة أثناء الضغط على مفتاح ، واستخدام المصطلح هنا لا معنى له ، نظرًا لأن نظام الإجراء لا يعتمد على الحدث بشكل مباشر ، يتم تحديث الحالة بطريقة لكل إطار. أيضًا ، يمكن أن تعمل الإجراءات أيضًا مع أجهزة أخرى مثل وحدات التحكم أو أزرار الماوس ، حيث لا يوجد حدث "echo".

يقوم get_children () في TreeItem بإرجاع الطفل الأول فقط وليس كل الأطفال مثل الاسم (أو الوصف في المستندات) يقترح.

[يحرر]
Nvm المستندات. تم تحديث وصف الطريقة في الماجستير ، آسف.

أوصي المورد 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() لكل تنسيق صورة. من المحتمل أن يتم توحيد الأساليب المتعلقة بالمخزن المؤقت في نفس الواجهة لمنع سخام واجهة برمجة التطبيقات ، ولكن هذا موضوع آخر للمناقشة.

Xrayez قد يستحق الأمر أيضًا إزالة load في GDScript: https://github.com/godotengine/godot-proposals/issues/263

المتغير registering_order والطريقة ذات الصلة set_registering_order في ProjectSettings غير مستخدم.

يجب إعادة تسمية RandomNumberGenerator إلى Random rand_range ويجب إهمال الوظائف العشوائية العامة مثل randf و rand_range أو إزالتها.

أرى المشكلات المحتملة حيث يستدعي المرء وظيفة غير موثوق بها أثناء تحديد البذور العشوائية

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

الدالات العشوائية العامة مثل randf و rand_range يجب إهمالها أو إزالتها.

تمت مناقشته كجزء من مقترحات godotengine / godot # 1590.

أفضل أن تكون هذه الأساليب العشوائية الأساسية في النطاق العالمي لأغراض الوصول والنماذج الأولية ، على الأقل بعضها. ولكن يمكن بالتأكيد إزالة seed() و rand_seed() .

يبدو أن FuncRef أصبح زائدًا عن الحاجة منذ إضافة Callable .

اكتشفت الطرق property_can_revert و property_get_revert في المفتش وأبلغت عنها في # 43078. ومع ذلك ، أعتقد أنه يجب إعادة تسميتها بالشرطات السفلية الرئيسية لاتباع اصطلاحات _get ، _set ، و _get_property_list .

EditorImportPlugin و EditorExportPlugin مرتبطان ببعضهما البعض ، لكن أحدهما يتعلق باستيراد الموارد والآخر يتعلق بتصدير المشروع. أقترح إعادة تسمية EditorImportPlugin إلى EditorResourceImportPlugin أو شيء من هذا القبيل.

تحرير: ويجب إعادة تسمية EditorPlugin.add_import_plugin وفقًا لذلك أيضًا.

لماذا لا ResourceImportPlugin ؟ لا تحتوي العديد من فئات المحررين (معظمها؟) على كلمة "محرر" بالفعل ، مثل SceneTreeDock أو كل عناصر الرسوم المتحركة.

يجب إعادة تسمية تعداد Tracking_status في ARVRInterface إلى TrackingStatus ، ليكون متسقًا مع أنماط أسماء التعداد الأخرى.

بالنظر إلى ARVRInterface أعلاه ، فإن جودة الأسماء رديئة جدًا بشكل عام. هذه هي الأسماء المُقترحة أيضًا:

• ar_is_anchor_detection_enabled → anchor_detection_enabled (خاصية)
• interface_is_initialized → initialized (الخاصية ، يمكن إعادة كتابتها إلى 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: Proposition A : ربما شيء مثل Control.MOUSE_FILTER_PASSPARENTS للسلوك الحالي ، حيث يبدو أن أحداث الإدخال يتم إرسالها إلى الوالدين فقط.

: صاروخ: اقتراح ب : قم بتغيير الثوابت إلى هذه:

• توقف: السلوك الحالي - خذ حدثًا وأوقف كل عمليات التكاثر
• PASS_PARENT: نفس سلوك PASS حاليًا
• PASS_ALL: تجاهل ، لكنه يأخذ الأحداث
• تجاهل: السلوك الحالي - لا تأخذ الحدث ، ولكن لا يزال يتكاثر

: eyes: Proposition C : ما إذا كانت العقدة تأخذ مدخلات GUI أم لا ليست ذات صلة حقًا ، حيث لا يمكن للمرء فقط توصيل أي إشارات (أو استخدام علم منطقي). يمكننا تغيير الخيار إلى Control.propagation_mode والحصول على هذه الثوابت:

• لا أحد
• الأبوين
• الكل

سيبدو ذلك أكثر نظافة في رأيي.

هذا يتجاوز إعادة التسمية ويجب مناقشته كاقتراح.

لماذا كل هذه التسميات طويلة جدا؟ أنت تغير شيئًا بسيطًا وقصيرًا إلى شيء طويل جدًا.

أنت تقوم بتغيير clip إلى intersection ضعف طول الكتابة.
أنت تقوم أيضًا بتغيير Control.MOUSE_FILTER_PASS إلى Control.MOUSE_FILTER_PASSTHROUGH
إلخ

أفضّل إجراء تغييرات أبسط وأقصر وأقل تفصيلاً. إنه اسم وظيفة وليس وصفًا للوظيفة أيضًا.

أفضّل إجراء تغييرات أبسط وأقصر وأقل تفصيلاً. إنه اسم وظيفة وليس وصفًا للوظيفة أيضًا.

يجب أن يكون الاسم وصفي بالرغم من ذلك. لا يهم الطول أيضًا إذا كنت تستفيد من الإكمال التلقائي (المضمن في محرر Godot).

لقد ذكرت ذلك مرة واحدة على IRC ولم أتلق ردًا ، لكن TextureRect به وضع ممتد يسمى "Scale On Expand (Compat)". هذا يبدو وكأنه شيء يمكن إزالته.

"أقل الإسهاب" ليس في القائمة بالتأكيد إذا أردنا الحصول على قواعد رموز قوية عبر مشاريع Godot الخاصة بنا. توفر أدوات الترميز الحديثة الإكمال التلقائي والميزات الذكية الأخرى التي تتيح لك الكتابة بسرعة حتى لو كان الاسم طويلاً. بالإضافة إلى ذلك ، إذا قرأت الحجج الخاصة بهذه التغييرات ، فهناك هدف لجعل هذه الوظائف أقل غموضًا بالنسبة للمطورين الذين يستخدمونها. قد يكون الاسم المختصر حلوًا ، لكنه محير وأقل قابلية للاكتشاف.

وتذكر دائمًا: كتابة التعليمات البرمجية هي الجزء السريع من تطوير البرنامج. قراءة وفهم الكود بعد ذلك أكثر أهمية. إنه مثل الحمل وتربية الطفل على التوالي.

انا اختلف مع كلاكما أنا أحد مستخدمي Godot وأستخدم Godot على وجه التحديد لأن GDScript مقتضب وسريع في الكتابة. إذا كنت ستعمل على جعلها ضعف الطول ، فستفقد ميزة السرعة لأنني سأضطر إلى الكتابة مرتين ، وسأضطر إلى التمرير مرتين لأرى سطر الكود بالكامل أفقيًا.

عندما تقوم بالبرمجة لا تريد أن تكتب دالة طويلة بشكل لا يصدق أو أسماء متغيرة. تضيف بعض هذه التغييرات المقترحة وظائف طويلة جدًا وأسماء متغيرة من أجل "الوضوح" على حساب كل شيء آخر. يمكنك قراءة التعليمات المضمنة إذا كانت لديك أي شكوك. البرمجة الإضافية تدور حول تعلم API. ستبحث دائمًا عن دالة لأول مرة تستخدمها بغض النظر عن الاسم. خذ printf في C هو مقتضب وبسيط. في Godot يمكنك تسميته send_formatted_string_to_standard_out. ليس فقط أنك تجبر الجميع على إعادة تعلم API ولكن بعض هذه التغييرات لا تحتوي حتى على رؤية موحدة. يبدو لي أن مجموعة كاملة من الأشخاص اجتمعوا معًا وقام كل منهم بتغيير جزء واحد من المحرك.

خذ Array على سبيل المثال
remove -> remove_at ماذا يضيف _at هنا؟ لديك بالفعل remove_value. ما الذي يمكنك إزالته أيضًا؟
erase -> remove_value لا يزال غير واضح بما فيه الكفاية. من المستندات "يزيل التواجد الأول لقيمة من المصفوفة." قد يعتقد الأشخاص أيضًا أنه يمكنك إزالة قيمة واحدة من المصفوفة بأكملها. من أجل الوضوح ، يجب أن يكون في الواقع remove_first_occurance_of_value لأن هذا هو ما تفعله الوظيفة بالفعل. لذلك جعلت الوظيفة أطول ومربكة لفترة أطول.

لديك وظيفتان مختلفتان remove و erase لكنك تقوم بتشغيلهما في نفس الشكل على remove بأحرف إضافية. لكنهم يعملون بشكل مختلف. يزيل الإزالة من فهرس معين حيث يزيل المسح أول مثيل لقيمة تم العثور عليها.

هذه لا بأس بها ولكنها ليست مفيدة حقًا بخلاف إجبار الأشخاص على تحديث التعليمات البرمجية الخاصة بهم.
عكس -> عكس
تكرار -> استنساخ
فارغ -> فارغ

إذا لم يتم كسره لا تقم بإصلاحه.

CarlGustavAlbertDwarfsteinYung لكنك لن تكتب ضعف ذلك. بعد الأحرف الثلاثة الأولى التي تكتبها ، ستبدأ الكتابة التلقائية وتختار ما تحتاجه بدلاً من كتابة كلمات كاملة.

بالنسبة للأسماء الأخرى ، على سبيل المثال ، عند إلقاء نظرة على empty -> is_empty يلزم التغيير لتقديم توضيح لما يفعله. عندما تنظر إلى empty هل يمكنك معرفة ما إذا كانت هذه طريقة تفرغ شيئًا ما ، هل هو فحص كتاب إذا كان هناك شيء فارغ ، هل هو شيء آخر؟ باستخدام is_empty يمكنك أن ترى للوهلة أن هذا منطقي صحيح إذا كان هناك شيء فارغ وخطأ في حين أنه ليس كذلك. يجب أن تعرف الوظيفة أو المتغيرات فقط من خلال قراءة أسمائها. لا يمكنك فعل ذلك باسم مثل empty

@ Feniks-Gaming يمكنني أن أقول لك فارغة أو فارغة أو مربكة بنفس القدر ، فقط واحدة أطول من الأخرى.

CarlGustavAlbertDwarfsteinYung empty يمكن أن يكون فعلًا إذا تمت قراءته كفعل. is_empty هو بالتأكيد جودة. بالطبع قد يعتمد هذا الالتباس على مستواك في اللغة الإنجليزية.

أيضًا ، حتى إذا كانت الوظيفة تسمى send_formatted_string_to_standard_out في محرر كود حديث ، فيمكن كتابتها على أنها sfstso ، أو أي مجموعة أخرى من الأحرف الوسيطة ، إذا كنت ترغب في ذلك ، وسيمنحك الإكمال التلقائي الخيار الوحيد.

pycbouh يستخدم الناس هذا المحرك منذ كم سنة؟ ولم أسمع أي شخص يأتي إلي يقول إنك تعرف ما هي أكبر مشكلة في هذا المحرك. حقيقة أن المصفوفات بها empty بدلاً من is_empty .

أنتم يا رفاق جالسون هنا لإصلاح أشياء لم يطلبها أحد أو يريدها. نعم ، فإن الصياغة محيرة ولكنها ليست مشكلة في الواقع ولم تكن مشكلة منذ أن بدأت في استخدام هذا المحرك في عام 2015. بعض التغييرات المقترحة مرحب بها تمامًا ولكي نكون منصفين أستخدمها. فارغ سيكون بخير. لكن بعض التغييرات طويلة جدًا ومربكة أيضًا. كنت أتحدث على وجه التحديد عن تلك التغييرات وليس كل شيء.

إن وجود هذا الموضوع الضخم هو الدليل على أن الناس يطلبونه. قد تكون هذه المشكلات غير ذات أهمية بالنسبة لك أو لأي شخص آخر ، ولكن يواجه الأشخاص مشكلات في فهم واجهة برمجة التطبيقات بسبب التسمية السيئة. وهذا هو نوع المشاكل التي تجمعها هذه القضية. أما بالنسبة لأهمية هذه التغييرات بشكل عام ، صدق أو لا تصدق ، لكن تتبعها وتنفيذها لا ينتقص من وقت التطوير الآخر.

وانظر إلى المثال الذي قدمته وحاولت شرحه:

يزيل الإزالة من فهرس معين حيث يزيل المسح أول مثيل لقيمة تم العثور عليها.

أنت تكتب ذلك ولا ترى أي سبب لتحسين التسمية لتكون أكثر وضوحًا على الأقل لجميع مستخدمي Godot الحاليين والمستقبليين ؟

pycbouh وفي الحقيقة أعطيت مثالاً عن المصفوفة remove_at و remove_value . remove_value يختلف عن وصف المحو ولا يزال محيرًا بنفس القدر. إزالة القيمة من أين؟ إزالة القيمة من النهاية ، rmeove من البداية؟ إزالة كافة تكرارات القيمة من المصفوفة؟

إذا كنت حقًا بحاجة إلى تغيير الأشياء ، فاستخدم remove و remove_first_occurence مما يجعلها مقتضبة ووصفية.

pycbouh أنا لا أطلب ذلك. يرجع وجود هذا الخيط إلى أن بعض الأشخاص يفرطون في الهندسة وإصلاح الأشياء التي لا يتم كسرها بطريقة المبرمج الكلاسيكي. ماذا عن المستخدمين في المستقبل؟ ماذا عنهم؟ كنت مستخدمًا مستقبليًا ذات مرة وتعلمت واجهة برمجة التطبيقات. ليس لدي مشكلة مع تسمية الوظيفة. 50٪ من التعليقات أشخاص لا يوافقون على التغييرات المقترحة. يبدو أن معظم هذه التغييرات مدفوعة بعدد صغير من أعضاء المجتمع الذين يدفعون هذه التغييرات على الجميع. هل يمكننا التصويت على التغييرات المقترحة؟

في الواقع هنا اقتراح. يجب أن تتضمن أي تغييرات يتم إجراؤها على تسمية واجهة برمجة التطبيقات آراء المساهمين / المتبرعين / المستخدمين. إذا وافقوا جميعًا ، فأنا أيضًا على متن الطائرة. احصل على استطلاعات الرأي وشاهد ما يفعله الجميع. لا تحاول تخمين ما يريده الآخرون. ما هو جيد بالنسبة لك قد لا يكون جيدًا لشخص آخر.

أنا ضد حوالي 50٪ من التغييرات المقترحة هنا مما رأيته.

50٪ من التعليقات أشخاص لا يوافقون على التغييرات المقترحة.

هل يمكننا ترك الإحصائيات المختلقة عند الباب ، من فضلك؟

هل يمكننا التصويت على التغييرات المقترحة؟

هذا هو سبب المناقشة وردود الفعل.

أنا ضد حوالي 50٪ من التغييرات المقترحة هنا مما رأيته.

إذا كنت ضدهم فقط لأنني "تعلمت الأمر بهذه الطريقة ، لذلك أريد أن يعاني كل من بعدي من نفس المعاناة" ، فهذا نقد غير صالح للاقتراح وسيتم تجاهله.

ما هو جيد بالنسبة لك قد لا يكون جيدًا لشخص آخر.

نفس الشيء.

هل يمكننا ترك الإحصائيات المختلقة عند الباب ، من فضلك؟

مثل هذا الادعاء حول المجتمع بأكمله؟

قد تكون هذه المشكلات غير ذات أهمية بالنسبة لك أو لأي شخص آخر ، ولكن يواجه الأشخاص مشكلات في فهم واجهة برمجة التطبيقات بسبب التسمية السيئة.

كيف تعرف ما الذي يعاني منه الناس؟ هل سألتهم؟ هل كان هناك استطلاع أو دراسة أو أي استبيان حول هذا؟ كيف أتيت بهذه المعلومات؟

أنا أحد هؤلاء المستخدمين بدأت من الصفر وتعلمت واجهة برمجة التطبيقات. ليس لديه مشاكل في التسمية. تحتوي جميع واجهات برمجة التطبيقات على بعض اصطلاحات التسمية الغريبة. يجب أن تكون جميع الوظائف موجزة إلى حد ما حتى تتمكن من كتابتها في التعليمات البرمجية.

pycbouh إذا كنت تحاول إقناعي بأن جميع اقتراحات التسمية هنا جيدة ،

كيف تعرف ما الذي يعاني منه الناس؟ هل سألتهم؟

تم إنتاج معظم الإدخالات في هذا الموضوع من قبل أشخاص قادمين من مشاكل ، سواء كان ذلك هنا على GitHub (وفي هذه الحالات تكون المشكلات مرتبطة) أو باستخدام قنوات مجتمعية أو شخصية أخرى. لا تفترض أننا نجلس هنا فقط نلعق أجزائنا الخاصة لأنه ليس لدينا ما نفعله أفضل من التفكير في الوظيفة أو الخاصية الأخرى التي يجب إعادة تسميتها في المحرك.

علاوة على ذلك ، لم يتم حتى تنفيذ الكثير من التغييرات المقترحة هنا ، ولم يكن هناك علاقات عامة أو أي نشاط آخر. تم سردها وهذا كل شيء. راقب العلاقات العامة وإذا ظهر أحد المخالفين لك فلا تتردد في التعليق عليه. بعد ذلك ، يعود الأمر إلى رئيس وزراء Godot للموافقة على التغييرات ودمجها. كن بنّاءً وقد تمنع بعض التعديلات غير المرغوب فيها ، لكن لا تنسَ ما قلته بنفسك ذات مرة:

ما هو جيد بالنسبة لك قد لا يكون جيدًا لشخص آخر.

لذا ، حتى إذا لم تكن لديك مشكلات مع API حتى هذه النقطة ، فهذا لا يعني أن الآخرين لم يواجهوا أيًا من هذه المشكلات أو أنهم لن يواجهوا أي مشكلات في المستقبل.

تحتوي جميع واجهات برمجة التطبيقات على بعض اصطلاحات التسمية الغريبة.

هذا جيد إذا كانت هناك اتفاقية يمكن التحدث عنها. ولكن تم تسمية بعض واجهات برمجة التطبيقات في Godot قبل وقت طويل من فتحها المصدر وقد لا يتم التفكير فيها كما يأمل المرء. أطلب منك مرة أخرى ألا تفترض أن الناس هنا يقترحون تغييرات من أجل ذلك.

من فضلك لا تجري هذه الأنواع من المناقشات هنا. إذا كنت ترغب في مناقشة تغييرات معينة في واجهة برمجة التطبيقات ، فلا بأس بذلك ، ولكن العبارات الشاملة التي لا تعجبك الاقتراحات هنا ليست مفيدة.

سيقوم المطورون الأساسيون بمراجعة كل من هذه الاقتراحات واحدًا تلو الآخر. من المحتمل أن ينتهي الأمر بالعديد من الأشخاص غير المقبولين.

قفل مؤقتًا ، سيفتح لاحقًا.

هل يمكننا إضافة النقاط التالية إلى القائمة؟

• AnimationPlayer : إعادة تسمية stop() إلى pause() (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660، godotengine / godot-plans # 287)
• AnimatedSprite : إعادة تسمية stop() إلى pause() (# 31168) (مضاف بالفعل)
• AnimatedSprite3D : إعادة تسمية stop() إلى pause() (# 31168) (مضاف بالفعل)
• Tween : إعادة تسمية stop() إلى pause() ، stop_all() إلى pause_all() (PR # 41794، # 43442)

Tween: إعادة تسمية stop () للإيقاف المؤقت () ، stop_all () إلى pause_all () (# 43442)

هذا مشمول بالرقم 41794

@ opl- تتم مناقشة هذا أيضًا هنا: https://github.com/godotengine/godot-proposals/issues/287

زوجان من عمليات إعادة التسمية التي قد توضح ما تقوم به وظائف RNG ذات النطاق العالمي هذه:

• seed() -> set_seed() (ربما تضيف get_seed() أيضًا لمطابقة RandomNumberGenerator) - حاليًا ، ليس من الواضح أن هذه وظيفة تعيين.
• rand_seed() -> rand_from_seed() - حاليًا ، يبدو أنه قد يقوم بترتيب البذرة بشكل عشوائي أو شيء من هذا القبيل ، عندما يعطي بالفعل رقمًا عشوائيًا بناءً على البذور المقدمة.

rand_seed () -> rand_from_seed () - حاليًا ، يبدو أنه قد يقوم بترتيب البذرة بشكل عشوائي أو شيء من هذا القبيل ، في حين أنه يعطي بالفعل رقمًا عشوائيًا بناءً على البذرة المقدمة.

ماعدا انها تفعل العشوائيه البذرة. اقرأ الوثائق.

rand_seed () -> rand_from_seed () - حاليًا ، يبدو أنه قد يقوم بترتيب البذرة بشكل عشوائي أو شيء من هذا القبيل ، في حين أنه يعطي بالفعل رقمًا عشوائيًا بناءً على البذرة المقدمة.

ماعدا انها تفعل العشوائيه البذرة. اقرأ الوثائق.

آسف. ما قصدته هو أنه يبدو أنه يقوم فقط بترتيب البذور بشكل عشوائي. ربما يجب أن يكون rand_int_from_seed() ، لأنه يُرجع عدد صحيح؟ في الواقع ، لا تحدد المستندات النوع الذي يتم إرجاعه ، حيث تشير فقط إلى "رقم ... عشوائي". هل هو عدد صحيح؟

إذن ، يولد بذرة جديدة بناءً على بذرة تمررها ثم يولد رقمًا جديدًا بناءً على تلك البذرة الجديدة؟ لست متأكدًا من إعادة التسمية ، ولكن الوصف يمكن أن يستخدم بعض التعديلات هناك ، إذا كان هذا هو ما يحدث.

إذا كان هذا هو ما تفعله ، فيبدو أن هذه الطريقة يجب تقسيمها إلى طريقتين أصغر ، ففعل شيئًا واحدًا بدلاً من إعادة تسميته

التحكم :: waiting_resize

غير مستعمل.

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

أدرك الآن أن هذه الطريقة تعادل في الغالب GDScript is (والذي كان extends راجع للشغل) ، لكن 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() هي مربكة بالنسبة لي بشكل عام