أستخدم جودو بشكل احترافي لأكثر من عام.

أوافق على كل ما قلته ، باستثناء:

بالنسبة للبعض ، أعتقد أننا يجب أن نحافظ على الطريقة الحالية

إذا كانت لدينا هذه الفرصة الذهبية ، فلنقم فقط بإعادة تسمية كل شيء. يتضمن Sprite2D و MeshInstance3D.

من الأفضل دائمًا إعادة بناء مؤلم كامل ، مثل العديد من معالجات إعادة البناء المؤلمة الجزئية.

الحديث عن إعادة التسمية: https://github.com/godotengine/godot/issues/16863

@ jahd2602 لا أمانع شخصيًا في أي من الحالتين ، يمكننا استطلاع ذلك في أسوأ الحالات.

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

Zylann أعرف ، إذا قررنا شيئًا هنا ،

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

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

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

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

CodeDarigan أنا أفهم أن لها فوائد وأنا لا

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

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

التنقل -> Nagivagion3D
هل هذا خطأ مطبعي؟

تضمين التغريدة

reduz أتفق مع @ jahd2602. حتى إذا كانت بعض الأشياء قد تكون واضحة ، من أجل الاتساق ، يجب علينا بعد الإصلاح باستخدام إما ثنائي الأبعاد أو ثلاثي الأبعاد.

ما زلت أبدأ مع Godot والتغييرات المقترحة تبدو منطقية بالنسبة لي - استخدام أسماء مختلفة بمهارة للمتغير ثنائي الأبعاد أو ثلاثي الأبعاد للعقدة هو شيء تسبب لي في بعض الارتباك أثناء تعلم أي نهاية منتهية والانتقال إلى Thing2D / Thing3D أو Thing / Thing3D يبدو وكأنه تحسن كبير في الوضوح والاستيعاب.

ارجوك افعلها.

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

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

أنا أيضًا أؤيد إعادة تسمية الأشياء لتكون بشكل صريح ثلاثية الأبعاد أو ثنائية الأبعاد.

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

يمكن إضافة تحذير للتعليمة البرمجية باستخدام أسماء العقدة المهملة ثم يمكن إزالتها في 4.1 أو 4.2.

إذا كان هناك إصداران من العقدة ، فسأقوم دائمًا بإلحاق لاحقة ثنائية الأبعاد / ثلاثية الأبعاد.

أيضًا ، سأكون سعيدًا إذا كان Label -> TextLabel. أذهب لإضافة عقدة حتى أتمكن من عرض بعض النص ، لذلك أكتب نصًا في شريط البحث وبالطبع يظهر RichTextLabel فقط مما يذكرني بأن العقدة النصية القياسية لا تحتوي فعليًا على نص في الاسم.

@ Janders1800 هذه هي الطريقة التي تعمل بها الآن ، فكلما قلت الميزات التي تستخدمها في SpatialMaterial ، كلما كان الظل الذي تخلقه أصغر.

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

أنا أؤيد استخدام اللواحق 2D / 3D دون قيد أو شرط.

في حين أنه من الصحيح أنه بالنسبة لبعض العقد يبدو أنها فرصة ضائعة للحصول على المزيد من الأسماء "الطبيعية" ، فإن الاتساق يفوز.

ما لا أحبه تمامًا هو أن StandardMaterial3D هو غير ORM. نقطتي هي أن ORM مدعومة بقوة بمعيار (على الأقل RM ، وهو ما لديك في glTF).

لكن لا يمكنني حتى الآن اقتراح تسمية أفضل.

ربما تكون هذه أيضًا فرصة لفعل شيء بخصوص "قماش". لقد وجدت هذا المفهوم مربكًا بعض الشيء في بعض الأحيان.

أعلم أنه صعب ، لأنه لا يوجد نظير ثلاثي الأبعاد: مشاهد ثلاثية الأبعاد مباشرة في عقد Spatial ، لكن يمكن أن تحتوي اللوحات على مزيج من Node2D s و Control s.

ومع ذلك ، سيكون رائعًا إذا تمكنا من تحديد بعض الأسماء التي تسمح بإعادة تسمية CanvasItemMaterial إلى Material2D ، مع إبقائها ذات مغزى لـ 2D "الخالص" وعوالم واجهة المستخدم الرسومية.

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

للتوافق في المستقبل ، في gdscript

ملف gdscript ...

يمتد المكاني
class_name Node3D

وما إلى ذلك وهلم جرا.

هل فكرت في إعادة تسمية translation للعقد المكانية إلى position ؟

BeayemX أعتقد أن الترجمة مصطلح شائع للفضاء ثلاثي الأبعاد ، والموضع شائع لمطوري 2D: التفكير:

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

أنا أؤيد إعادة تسمية العقد ثلاثية الأبعاد كما هو مقترح هنا. لا أعرف حجم المشكلة بالنسبة لصانعي البرامج التعليمية على الرغم من ذلك. على أقل تقدير ، يجب أن يكون من التافه إعادة تشكيل قواعد الكود الحالية. في C # يمكننا حتى إساءة استخدام ObsoleteAttribute في وضع التصحيح لتسهيل الأمر (لست متأكدًا مما إذا كانت فكرة جيدة):
[Obsolete("Use Node3D", error: true)] class Spatial { /* Nothing here */ }

آمل أن نضيف مساحات / فئات كما تمت مناقشته في # 18711. أريد فصل واجهة برمجة تطبيقات C # إلى مساحات أسماء وربما تجمعات أيضًا لتمكين المستخدمين من اختيار ما يحتاجون إليه فقط.
كانت خطتي لـ 4.0 هي ترميز جدول مساحات الأسماء بنفسي إذا لم يكن هناك خيار آخر ، لكنني أفضل إذا كان بإمكاني الحصول على هذه المعلومات من ClassDB بدلاً من ذلك.

@ eon-s لا أعتقد أنه ... بينما translation صالح تقنيًا لتمثيل الإحداثيات ، فإن Godot هو المحرك الأول الذي أرى فيه مصطلحًا مختلفًا يتم استخدامه هنا ، وإلا فقد رأيت دائمًا position بغض النظر عن 2D أو 3D. بالنسبة لي أيضًا ، يرتبط translation بالحركة ، ويتعارض مع مصطلح آخر متعلق باللغة / التحول ، مما يجعله غريبًا. تم ذكر ذلك في https://github.com/godotengine/godot/issues/16863 أيضًا.

راجع للشغل ، لماذا نخطط لكسر أقل قدر ممكن؟ أفهم سبب عدم رغبة الأشخاص في المزيد من تعطل التوافق ، خاصةً أولئك الذين يقومون بعمل برامج تعليمية ؛ ولكن إذا لم نأخذ 4.0 كفرصة لكسر التوافق ، فمتى سنذهب؟ # 16863 يجمع بالفعل الكثير من الاقتراحات.

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

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

@ eon-s بالتأكيد الانتظار حتى 5.0 يعني فقط أنه سيكون هناك قدر أكبر من العمل يحتاج إلى التحديث؟

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

أقدر الاختلاف في التسمية بين Node و Spatial لأن العقد Node ليس لديها معرفة بالفضاء ، فإن وجود Node و Node2D و Node3D سيكون مربكًا. ما لم تكن تخطط للتخلص من Node ، فسيكون ذلك منطقيًا تمامًا.

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

من فضلك لا تضيف لاحقة ثلاثية الأبعاد. هل حقا يستحق الصداع لما يضيفه؟ هل يستحق هذه التكلفة؟ لتحديث كل شيء أو وجود برامج تعليمية قديمة؟ دروس يوتيوب غير قابلة للتعديل وعفا عليها الزمن؟ سوف يجلب المزيد من الارتباك.

dpalacio أنا

neikeq نعم ، يجب استبدال الفئة

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

هل فكرت في إعادة تسمية translation للعقد المكانية إلى position ؟

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

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

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

فيما يلي بعض العقد التي أود أن أراها متغيرة لتبقى متسقة:

• MeshInstance -> MeshInstance3D (للبقاء متسقًا مع MeshInstance2D )
• GridMap -> TileMap3D أو GridMap3D
• TileMap -> TileMap2D أو GridMap2D
• YSort -> YSort2D أو 2DSort (أو شيء لتظهر أنه ثنائي الأبعاد)
• ProximityGroup -> ProximityGroup3D
• GIProbe -> GIProbe3D (أو شيء لتظهر أنه ثلاثي الأبعاد)
• ReflectionProbe -> ReflectionProbe3D (أو شيء لتظهر أنه ثلاثي الأبعاد)
• SpatialMaterial -> PBRMaterial أو Godot3DMaterial أو StandardMaterial3D (مجرد أفكار)
• Label -> TextLabel (أتفق مع MuffinManKen)

إليكم أفكاري حول هذا الاقتراح ، بدءًا من الإيجابيات:

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

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

فائدة أخرى يمكنني رؤيتها مع هذا التغيير هي أنه يضع معيارًا لكيفية تسمية العقد ، مما قد يكون مفيدًا لمنشئي المكونات الإضافية ومساهمات Godot Engine المستقبلية. على سبيل المثال ، إذا كنت أقوم بعمل عقدة صائق (على سبيل المثال) ، فعند هذا التغيير أعلم أنه يجب علي تسميتها شيئًا مثل Decal3D بدلاً من Decal .
قد يساعد هذا أيضًا في تسمية فئات GDScript / C # المعرفة.

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

الآن للسلبيات:

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

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

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

أتفق مع @ eon-s: ألا تنتظر هذه التغييرات قليلاً؟ تتغير الأشياء بالفعل بشكل كبير ، على الأقل في قاعدة الشفرة ، مع Godot 4.0. أعتقد أن إضافة تغيير هائل آخر لن يؤدي إلا إلى زيادة صعوبة التطوير وإعادة تعيين الكثير من التقدم الذي يحرزه الأشخاص من خلال الجانب ثلاثي الأبعاد من Godot.

بمجرد إصدار Godot 4.0 ، أعتقد أن العمل على إعادة تسمية العقد في الإصدار 4.1 أو 5.0 سيكون ممتازًا ، لكن في رأيي أعتقد أن إضافة تغيير كبير آخر مثل هذا سوف يضر أكثر مما يساعد.

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

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

TLDR: أنا جميعًا مع التغييرات ، وأعتقد أنه يجب فقط الانتظار حتى Godot 4.1 أو نظام / فترة انتقالية لإعطاء الجميع الوقت للتكيف مع التغييرات.

بغض النظر عن كيفية انتهاء هذا الاقتراح: أعتقد أن Godot 4.0 سيكون رائعًا وأنا أتطلع إليه 🙂

reduz أقول اذهب لذلك. وأعود @ jahd2602

لست من أشد المعجبين بجعل جميع العقد ثلاثية الأبعاد تنتهي بـ "3D" ، ولكن بالتأكيد ، إذا أراد الجميع ذلك. أعتقد أنه من الجيد الاحتفاظ بأسماء مختلفة بدلاً من وجود لاحقة دائمًا (على سبيل المثال: TileMap و GridMap)

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

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

(راجع للشغل لماذا يوجد Sprite3D في حين أنه يمكن أن يكون مجرد شبكة رباعية؟)

TwistedTwigleg اقرأ

تغيير رائع ، بصفتي مبرمجًا ، يسعدني أن أرى اسم الطرف المقابل متماثلًا قدر الإمكان

هل يمكنك شرح ما تعنيه قوام نمط ORM بمزيد من التفصيل؟

reduz هو الاختلاف الوحيد بين المادة المكانية القياسية وواحدة ORM ، حيث أن لديك قناة نسيج واحدة فقط (بدلاً من 3 كما هي حاليًا) مع ORM؟ هل ستظل قادرًا على الوصول إلى نفس المعلمات (في المعادن والخشونة) مثل المرآوية والمضاعفات؟ لا تستخدم في كثير من الأحيان ولكن تستخدم في بعض الأحيان للقرص.

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

لقد قمت مؤخرًا بوضع قناة العمق (الارتفاع) في قناة ألفا لخرائط ORM الخاصة بي للحصول على مزيد من الأميال من الأنسجة. ثم يمكنك عمل معظم القوام باستخدام 3 قوام فقط ... البياض / العادي / ORM (H). قد يكون هذا مفيدًا للإضافة افتراضيًا (ما لم نحصل على خيار 16 بت لخرائط الارتفاع ، حيث قد ترغب في استخدام واحدة منفصلة). إذا حصلت 4.0 في النهاية على تغطية بالفسيفساء / الإزاحة ، فستكون قناة الارتفاع أكثر أهمية مما هي عليه حاليًا.

وبالحديث عن ذلك ، ستكون أيضًا فرصة جيدة لتغيير تسمية قناة DEPTH إلى HEIGHT في 4.0 وجعلها تستخدم معكوس ما تستخدمه حاليًا (على سبيل المثال ، الأبيض هو سطح مرتفع والأسود مغلق). هذا من شأنه أن يجعلها تتماشى مع العارضين ومحركات الألعاب الأخرى ، والأهم من ذلك مع أدوات مثل Substance و Quixel و Marmoset.

أنا أفضل اللواحق الصريحة للعقد ثنائية وثلاثية الأبعاد ، ولا توجد لاحقة إذا لم تكن قابلة للتطبيق. أرغب أيضًا في فصل عُقد "التحكم" تمامًا عن عُقد "Node2D" (تم تجميع كلاهما حاليًا ضمن "CanvasItem").

حول translation مقابل position ، سأختار الأول في كل من 2D و 3D.

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

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

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

TwistedTwigleg بخصوص إصدار ألعاب ثلاثية الأبعاد ، وذلك لأننا ننتظر 4.0 و Vulcan 😎

أود أيضًا مراجعة أسماء العقد Control ... والوثائق المضمنة.

أحيانًا أتساءل ما الفرق بين AcceptDialog و ConfirmationDialog ، ونفس الشيء مع PopupPanel ، PopupDialog ، PopupMenu ... أتمنى ذلك يساعد!

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

قادم متأخرًا إلى الحفلة ، ولكن بعض التوضيحات لإبقاء الأمور تحت السيطرة:

• يرجى التعليق فقط على اقتراح إعادة تسمية العقد ، وآثاره التقنية على كيفية الحفاظ على التوافق ، والتأثير على المشاريع الحالية ، والبرامج التعليمية ، وصانعي المحتوى ، وما إلى ذلك.
• ليس هذا هو المكان المناسب لمناقشة نقاط محددة في واجهة برمجة التطبيقات والتي يجب أخذها في الاعتبار لإعادة التسمية. إذا قررنا المضي قدمًا في عملية إعادة التسمية الضخمة هذه ، فسنراجع واجهة برمجة التطبيقات بالكامل في جدول بيانات للتأكد من أن لدينا أسماء متسقة. لأشياء محددة مثل الأساليب أو الخصائص أو الفئات التي يجب إعادة تسميتها بما يتجاوز ما تمت مناقشته هنا ، راجع # 16863.
• RandomShaperfracteedfirereduz الرجاء نقل النقاش حول المواد القياسية لقضية مخصصة.

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

يمكن أن يعطي استخدام المصمم أيضًا فائدتين أخريين:

1. يمكن لـ IDE بسهولة التقاط هذه العلامة وعرضها في نافذة اختيار العقدة ، على سبيل المثال بدلاً من مجرد قول "مكاني" يمكن قراءة "مكاني (استخدام متقادم Node3D)".

2. يمكن أن يصبح المصمم بعد ذلك تحذيرًا مدمجًا يظهر في محرر الكود.

بالإضافة إلى أنه لا يمنع أي شخص من إنشاء أداة إعادة تسمية ...

بعض الأفكار:

أوافق على إعادة تسمية العقد ، بالإضافة إلى بعض الأساليب والخصائص (انظر القائمة الحالية في # 16863) لتحسين التناسق ولجعل واجهة برمجة التطبيقات أسهل في التعلم والاستخدام. يبدو أن توضيح التمييز بين 2D / 3D فكرة جيدة ، وإذا تم ذلك يجب أن يتم بشكل متسق (على سبيل المثال ، MeshInstance3D أيضًا كما هو مذكور). أقترح أن نستخدم جدول بيانات لسرد جميع العقد الحالية وما يجب أن تكون أسمائهم الجديدة في 4.0 - ويمكننا ركوب الدراجات هناك حول عقد معينة مثل TileMap / GridMap. سأقوم بإنشاء جدول البيانات هذا في الأيام القادمة إذا تأكدنا من أن هذه هي الطريقة التي نريد أن نسير بها.

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

كما ذكرRandomShaper وchucklepie، ينبغي أن نضيف الأسماء المستعارة إهمال لكافة العقد والأساليب والخصائص، والثوابت، وإشارات، وما إلى ذلك أننا إعادة تسمية، مع الديكور الملكية / الفوقية التي من شأنها أن تشير على أنها عفا عليها الزمن وتشجيع المستخدمين على تغيير كودهم. يجب أن يتيح استخدام هذه المعلومات في IDE للمستخدمين متابعة البرامج التعليمية 3.x في الإصدار 4.0 دون مشكلة ، بينما يتعلمون بسهولة عن الأسماء الجديدة أثناء انتقالهم.

للقيام بذلك ، نحتاج إلى طرق مساعدة يمكن أن تتيح لنا تحديد الأسماء المستعارة المهملة عند تسجيل الارتباطات. # 23023 هي المحاولة الأولى لإضافة مثل هذه الواجهة ، لكنها لا تزال بحاجة إلى المراجعة ودمجها وربما توسيعها إذا لم تكن كافية لما سنحتاجه في 4.0. يمكن الاحتفاظ بهذه الأسماء المستعارة المهملة طوال دورة الإصدار 4.x ، وإسقاطها في الإصدار 5.0.
سأعارض أي إعادة تسمية لكسر التوافق حتى يتم تصميم هذه الواجهة جيدًا ودمجها ، لذلك أي شخص مهتم بهذا مرحب به لتجربة هذه العلاقات العامة واقتراح التغييرات إذا لزم الأمر.

بالنسبة للوقت ، أصر على أنه إذا أردنا كسر التوافق مرة أخرى ، فهذا هو الآن. لا معنى لانتظار 5.0 ، لأنه سيجعل المزيد من المحتوى عفا عليه الزمن بمجرد أن نصل إلى 5.0 ، ولن يساعد في تصوير Godot كأداة تطوير مستقرة إذا قطعنا التوافق مع (نأمل) العديد من الألعاب الرائعة قيد التطوير مع Godot 4 .x.

تتضاعف قاعدة مستخدمي Godot بشكل أو بآخر كل عام ، لذا فإن كل عام يمر يجعل إعادة البناء أقل واقعية ، حيث يفوق القصور الذاتي لقاعدة المستخدمين الكبيرة في نهاية المطاف الفوائد من كسر التوافق. إذا بدت محركات أخرى مثل Unity أو Unreal مستقرة نسبيًا من حيث API مقارنة بـ Godot ، فهذا ليس بسبب عدم امتلاكهم للأشياء التي يرغبون في إعادة بنائها أو إعادة تسميتها ، ولكن لأنهم لا يستطيعون تحمل تكاليفها. لا يزال بإمكاننا ، في الوقت الحالي ، لذلك علينا اغتنام الفرصة. كان الأمر نفسه بالنسبة إلى Godot 3.0 وخرج المجتمع منه سالماً نسبيًا ، على الرغم من أن لدينا نسبة صغيرة من المستخدمين يلتزمون بـ 2.1 لأنهم لا يستطيعون تحمل تكلفة النقل إلى 3.0. بالنسبة إلى الإصدار 4.0 ، نأمل أن يكون نطاق هذه التغييرات أقل بكثير ، ويجب أن يكون أي عمل نقل مباشرًا ، ولكن المجتمع قد نما متشعبًا في هذه الأثناء ، وبالتالي فإن تأثير أي كسر متوافق سيكون كبيرًا أو أكبر من 3.0 بوصات شروط الصورة / إزعاج المستخدم المتراكم :)

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

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

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

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

بشكل عام ، أنا لا أؤيد إجراء تغيير جذري في هذه الحالة.

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

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

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

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

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

chucklepie المشكلة هي أنه ليست كل اللغات تدعم الأسماء المستعارة للفئة مثل typedef. C # واحد منهم.

reduz آه ، لم أكن أدرك ذلك ، من الجيد معرفة ذلك. المشكلة الأكثر أهمية هي تحويل قناة العمق إلى ارتفاع لـ 4.0 ، لذلك نأمل أن تفكر في تغيير ذلك.

تعديل. آسف أكيين ، فقط رأيت تعليقك بعد نشر هذا ...

neikeq المشكلة هي أنه ليست كل اللغات تدعم الأسماء المستعارة

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

@ gerald1248 اقرأ سيتعطل ، وستستمر المشاريع التي تم إنشاؤها في 3.x في العمل باستخدام الأسماء المستعارة عند التحميل وعلى البرامج النصية. سيؤدي استخدامها إلى إطلاق تحذير بالإهمال ، لكن مشروعك سيستمر في العمل.

أنا معجب كبير بـ

التنقل -> Nagivagion3D

إعادة تسمية. أنا أؤيد هذا الطلب!

reduz قال:
TwistedTwigleg اقرأ

سيئتي ، لقد فاتني هذا الجزء من المنشور.

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

Norrox قال:
TwistedTwigleg بخصوص إصدار ألعاب ثلاثية الأبعاد ، وذلك لأننا ننتظر 4.0 و Vulcan 😎

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

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

فيما يتعلق بالتغييرات المقترحة في OP: تحتوي العقد ثنائية الأبعاد بالفعل على لاحقة "ثنائية الأبعاد" مطبقة ، والتي تعني بطبيعتها أن نظيراتها ثلاثية الأبعاد.

ومع ذلك ، فأنا أؤيد إجراء تغييرات مثل Label إلى TextLabel . ( MuffinManKen يقدم نقطة رائعة)

أنا أؤيد كل شيء هنا بشكل أساسي ، ولكن فيما يتعلق بسؤال "Sprite2D / Sprite3D" ، أقترح ترك Sprite كـ Sprite ، إذا لم يكن هناك سبب آخر غير اللاحقة ثنائية الأبعاد تضيف كمية إضافية من الفوضى ، IMO.

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

هل هذا الترميز اللوني مفيد للأشخاص الذين يعانون من أشكال مختلفة من عمى الألوان؟
من المؤكد أنه ليس مفيدًا عند كتابة التعليمات البرمجية (بدلاً من إضافة العقد من مربع الحوار).

reduz شكرا

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

الصريح أفضل من الضمني.

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

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

gimg ، AlexHoratio لا تنس أن 4.5٪ من السكان مصابون بعمى الألوان أيضًا: stuck_out_tongue:

أعتقد أن إعادة التسمية فكرة جيدة.
سيصبح الانتقال من 2D إلى 3D أسهل كثيرًا. على الأقل للأشخاص الذين بدأوا بـ 2D (وربما العكس أيضًا)

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

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

أنا شخصياً أعتقد أن Sprite -> Sprite2D سيكون ضحية مؤسفة لإعادة تسمية صريحة تمامًا ، لكن أعتقد أنه يمكنني دائمًا إعادة تسميته يدويًا إلى Sprite في كل مشهد أقوم به حتى أتعب منه.

أعتقد أنه من غير المقبول عدم تجميع CanvasLayer و CanvasItem ، وأن Node2D موجود داخل CanvasItem مع Control ، كما أشار آخرون.

أعلم أن @ akien-mga قال إن هذا مخصص فقط لإعادة تسمية العقد ، لكنني أعتقد أن النقاش على الأقل حول position مقابل translation يدخل حيز التنفيذ هنا. أعتقد أن الغرض من إعادة تسمية العقد يكون مسطحًا إلى حد ما إذا كانت واجهات برمجة التطبيقات الخاصة بهم مختلفة بشكل كبير (باستثناء الاختلافات بين أنظمة الإحداثيات وما شابه ذلك) ، لذلك يجب أن تكون هي نفسها بالتأكيد ، مهما كانت. كنت سأصوت لـ "المنصب" كطريقة للذهاب إلى هنا ، كان هناك تعليق حول كونها مضللة مقارنة بـ "الترجمة". أود أن أقول إن "الترجمة" مضللة لأنها تنطوي على تحول أو حركة بدلاً من كونها مجرد إحداثيات. الموقف نسبي بشكل حدسي ، imo (لا تقوم بتصويب الكراسي الخاصة بك فيما يتعلق باتجاهات البوصلة ، بل تفعل ذلك فيما يتعلق بجدران الغرفة).

أعتقد أنه يجب تسمية المتغيرات باسم الموضع لكليهما ، ولكن يجب أن تظل وظائف translate ، وتغيير وظائف move_local في Node2D إلى translate_local ، حتى الوثائق تسميها تترجم. سأحتفظ باستخدام move للعقد المتعلقة بالفيزياء ، للتمييز بين حركة الفيزياء والترجمة الهندسية.

جزء كبير من النصف الثاني من هذا يتعلق أيضًا بـ # 16863

أيضًا reduz ، أعتقد أنه نظرًا لأن C # تكتسب وظائف في المحرك ، فإن المزيد والمزيد من الأشخاص

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

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

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

aaronfranke أنا أكره أن أكون الشخص الذي يفسد فكرة معقولة ، لكن أسماء العقد المختلفة بين الأنظمة المختلفة تجعل مشاركة ملفات gd النصي أمرًا مستحيلًا. نظرًا لأنه يتم تصدير جميع المكونات الإضافية كملفات ومشاهد gscript خام ، فإنها ستتوقف عن العمل ، إذا تم تطويرها على نظام مع تعيينات عقدة مختلفة. لتجنب ذلك ، ستحتاج جميع ملفات gdscript وملفات المشهد إلى تضمين تعيينات اسم العقدة لترجمة الملف للنظام الجديد. أنا متأكد تمامًا من أن هذا النوع من النفقات العامة يمثل رفضًا كبيرًا لـreduz.

aspenforest لا أعتقد أن إضافة رسم خرائط سيكون

ما يمكن صنعه بسهولة من فكرة @ aaronfranke هو مجرد إعادة تسمية العقد عند الإنشاء. على غرار الإعداد الحالي في ProjectSettings والذي يغير أسماء العقدة التي تم إنشاؤها حديثًا إلى snake_case أو spine-case (لذلك سيتم تسمية العقدة الجديدة MeshInstance تلقائيًا mesh_instance بدلاً من MeshInstance ) ، يمكن إضافة إعداد آخر للواحق العقد ، والذي من شأنه إزالة اللاحقة "ثنائية الأبعاد" أو "ثلاثية الأبعاد" من أسماء العقد (لذلك يتم تسمية العقدة Sprite2D فقط Sprite ).

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

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

إذا كان الأمر يتعلق بالاختيار بين جعل الأسماء متسقة والحصول على ميزة محرر لتبسيط الأسماء ، @ aaronfranke كان

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

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

+1 للأسماء الصريحة ثنائية الأبعاد / ثلاثية الأبعاد.

لدي سؤال بخصوص عقدة واحدة أفترض أنه قد يتم وضع علامة عليها للإهمال في المستقبل ، ومن الذي يمكنني أن أتخيله قد يكون مربكًا من وجهة نظر التسمية. منذ أن تم إسقاط نظام الرسوم المتحركة الجديد ، أصبح لدينا الآن عقدتان ، واحدة تسمى AnimationTree و AnimationTreePlayer والتي لا علاقة لها ببعضها البعض على الإطلاق. أي أفكار حول ما قد يكون أفضل طريقة لمعالجة هذا؟

SaracenOne هذا ليس المكان المناسب لطرح أسئلة من هذا القبيل. آسف. هذا الموضوع مخصص لمناقشة اللاحقة ثنائية / ثلاثية الأبعاد فقط.

هناك مشكلة أخرى تتعلق بمناقشة تغييرات الاسم بشكل عام https://github.com/godotengine/godot/issues/16863

كان لدي فكرة من المحتمل أن تكون خارج نطاق كسر التوافق المقبول لـ 4.0 ، وبالتالي ربما يكون ببساطة غير ممكن / غير مقبول ، لكنني اعتقدت أنني سأذكرها لمعرفة ما إذا كان هناك شخص أكثر خبرة مما أنا مهتم بالتعليق.

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

من الناحية النظرية ، يمكن لمثل هذا النظام:

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

سيكون من الجيد تجنب الموقف الذي يكون فيه "SomeClass2D لديه تنفيذ x و y و z ولكن لا يوجد شيء مثل ذلك بالنسبة لـ SomeClass3D" وهو يحل مشكلة التسمية بطريقة مختلفة. ربما يكون هذا غبيًا للغاية لبعض الأسباب التي لا أفكر بها الآن ، لكنني اعتقدت أنني سأرميها هناك.

vortexofdoom هذا ما يحدث بالفعل. يتم توريث Node2D بواسطة جميع العقد ثنائية الأبعاد ، ويتم توريث Spatial بواسطة جميع العقد ثلاثية الأبعاد. السؤال هو ماذا نسمي كل شيء.

والأهم من ذلك ، يرث كل من Spatial و Node2D من Node .

أود أن أقول أنه لا يزال هناك شيء ما في فكرة vortexofdoom لم يتم تغطيته فقط من خلال التسلسل الهرمي للفصل ، لكن لا يمكنني تحديد ما هو بالضبط.

فقط أتساءل: هل تعتقد أنه سيكون من المفيد إضافة لاحقة - Res لجميع الفصول الدراسية المشتقة من Resource ؟

aaronfranke أنا أشير إلى فكرة امتلاك واحد من كل نوع من العقدة (ببساطة KinematicBody أو Sprite) ، Node2D3D الذي يملي سلوكهم. آسف إذا لم يتم شرح ذلك بشكل جيد. لذا فبدلاً من وجود تسلسل هرمي ثنائي الأبعاد وتسلسل هرمي ثلاثي الأبعاد ، سيكون لدينا تسلسل هرمي ثنائي الأبعاد / ثلاثي الأبعاد. هذا هو السبب في أنني قلت أنه سيكون معمل إعادة بناء أكبر مما هو مقبول على الأرجح.

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

vortexofdoom ولكن لا يوجد شيء مشترك فعليًا بين 2D و 3D. قد يكون لديهم بعض أنواع العقد نفسها ولديهم نفس أسماء الطرق ، ولكن تقريبًا كل عمليات التنفيذ مختلفة تمامًا. أكثر ما يمكن أن أتوقعه من مشاركة ستكون واجهة ، حيث أن فكرتك ستشمل if (is2d) { do 2d stuff } else { do 3d stuff } وستجعل ملفات الشفرة أطول مرتين وغير قابلة للقراءة بدون فائدة.

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

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

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

RandomShaper يمكنني بالتأكيد رؤية فائدة ذلك ، خاصة إذا كان لدينا خيار الأسماء البسيط هذا.

ترك تعليقاتي للأجيال القادمة ، لكنني أتراجع عن اقتراحي لصالح مخطط تسمية صارم ثنائي الأبعاد / ثلاثي الأبعاد مع ترك التسلسل الهرمي إلى حد كبير كما هو.

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

ولكن حتى خارج حالة الحافة هذه ، سيسمح لك بإنشاء فئات مثل Area بدلاً من إنشاء شيء مثل RoomGroup كمثال سريع.

أنا سعيد جدًا لأن هذا الأمر قيد المناقشة. آمل أن يتم ذلك.

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

مثال:

Geometry.get_closest_point_to_segment()    # <-- this is the 3D version
Geometry.get_closest_point_to_segment_2d()

بالإضافة إلى العقد والطرق ، ماذا عن هياكل البيانات؟ وأفترض أن Transform سيتم إعادة تسميته إلى Transform3D ليصطف مع Transform2D ، ولكن Basis ربما لا تحتاج إلى أن يكون Basis3D لأنه لا يوجد Basis2D حيث يتم تضمينها كلها ضمن Transform2D .

تضمين التغريدة

فقط أتساءل: هل تعتقد أنه سيكون من المفيد إضافة لاحقة - Res لجميع الفصول الدراسية المشتقة من Resource ؟

يبدو قليلا ضجة كبيرة جدا لباك. أفضل التصويت لتضمين الموارد في اقتراحي (# 31054) لتمييز الكود ، tbh. سيعكس وجودهم بلون مختلف نوعهم الأساسي بمجرد الانتهاء من كتابة اسم الفئة (تمامًا كما هو الحال مع الأنواع المضمنة مثل Vectors و AABB).

ماذا عن المشاريع المنفصلة إلى ثنائية وثلاثية الأبعاد.

(على اقتراح الصورة لاستبدال 2d بواجهة مستخدم وثلاثي الأبعاد بالمشهد).

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

وبهذه الطريقة يتم إنشاء نوع من مسافات الأسماء ، ولا مزيد من الخلط بين هذه الأنواع:

باستخدام Godot2D ؛
باستخدام Godot3D ؛

عندما تكون في مشروع ثلاثي الأبعاد أو ثنائي الأبعاد - انقر فوق واجهة المستخدم لديك نافذة UI (2D) لتحرير واجهة المستخدم الرسومية ، عند النقر فوق Scene - أنت في المشهد (2d أو 3d يعتمد على نوع المشروع).

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

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

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

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

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

aaronfranke لقد أضفت شرحًا واسعًا قليلاً لما قصدته في تعليقي السابق.

أعتقد أن عرض أسماء العقد بشكل مختلف اعتمادًا على الظروف من شأنه أن يضيف الارتباك.

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

dmitryuck قد تتطلب بعض المشاريع خلط ثنائي الأبعاد وثلاثي الأبعاد ، وبعض الألعاب بها واجهات مستخدم ثلاثية الأبعاد.

Skaruts التبديل إلى العرض ثنائي الأبعاد في مشهد ثلاثي الأبعاد ممكن من خلال تنفيذ مكون مثل هذا المحرر

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

إن إعادة تسمية https://godotengine.org/qa

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

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

Node type 'Spatial' is deprecated and replaced by 'Node3D'. 

و

Method 'clip_polygon()' is deprecated and replaced by 'clip_polygon_3d()'. 

لقد وجدت بالأمس أن الثوابت لا تتبع جميعها نفس الحالة. على سبيل المثال ، هناك Color.black و Vector3.UP . ألا يجب أن يكون هذا متسقًا مع 4.0؟

BenjaminNavarro تمت مناقشة تغيير ثوابت اللون إلى أحرف كبيرة في الجزء السفلي من https://github.com/godotengine/godot/pull/14704.

أيضًا ، يجب مناقشة الطريقة / الإشارة / إعادة التسمية المستمرة في # 16863 ، لأن هذه المشكلة تتعلق تحديدًا بأسماء العقد.

Calinou شكرًا ، كنت متأكدًا تمامًا من وجود مشكلات أخرى ولكن لم أتمكن من العثور عليها.

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

إذا لم يكن الإصدار الرئيسي هو الوقت المناسب للقيام بذلك ، فما هو.

SemVer: بالنظر إلى رقم الإصدار MAJOR.MINOR.PATCH ، قم بزيادة:
الإصدار الرئيسي عند إجراء تغييرات غير متوافقة في واجهة برمجة التطبيقات ،
إصدار MINOR عند إضافة وظائف بطريقة متوافقة مع الإصدارات السابقة ، و
إصدار PATCH عند إجراء إصلاحات أخطاء متوافقة مع الإصدارات السابقة.

إلى أي مدى ستذهب مع هذا؟

هل ستصبح GridMap بعد ذلك TileMap3D و Tilemap Tilemap2D على سبيل المثال؟

أيضًا ، تبدو node2D و node3D عامة بعض الشيء ، فلماذا لا يكون لديك Spatial2D و Spatial3D بعد ذلك؟

أعتقد أن الاختلاف الكبير في UX سيكون أيضًا في التحكم والعقدة 2D والمكانية ، بغض النظر عن تسميتها ، يمكن الوصول إليها مباشرة أسفل العقدة في مربع حوار العقدة الجديدة ، على الرغم من أن node2D والتحكم يرثان من CanvasItem. لا يمكنك إضافة CanvasItem مباشرةً إلى شجرة على أي حال ، لذلك ربما لا يجب أن يكون مرئيًا في هذا الحوار.

وبقدر ما تذهب الأساليب ، أعتقد أنه ليست هناك حاجة لإضافة 2D أو 3D postfix على هؤلاء ، لأنك تعرف ما تسميه لهم على حق؟

ما زلت آمل في إجراء بعض التحديثات المفيدة ، مثل معالجة بطء استيراد الموارد ، وتحسين أداء نصوص GD النصية. في الوقت الحالي ، يستغرق استيراد موارد 1G حوالي ساعة. إذا قمت باستيراد موارد 10G ، فيجب عليك الجلوس أمام الكمبيوتر والنوم لمدة يومين. ومع ذلك ، فإن مستعرض نظام ملفات محرر الموارد لاستيراد 700M-1G معطل الآن ، ولن يتم عرض أي شيء. قائمة الملفات ، قد تكون هذه هي عيوب المحرر نفسه ، لذلك أعتقد أن تحسين المشكلات الموجودة وحلها هو أفضل طريقة لـ Godot. إذا كان بإمكاني استيراد 100-500 مليون من الموارد فقط ، فمن المحتم ألا يتمكن Godot من تطوير ألعاب كبيرة ، لكن طريقي مغلق الآن ولا يمكنني المضي قدمًا. أتمنى أن يحل الإصدار القادم مثل هذه المشاكل ، أتمنى أن يكون Godot أفضل وأفضل!

@ qq715152910 من فضلك لا تعلق على المواضيع الطويلة التي تحتوي على معلومات غير ذات صلة على

سأقدم رأينا حول بعض عمليات إعادة التسمية التي ستكون مفيدة لنا (نستخدم C # بشكل أساسي)

إعادة التسمية التي نقترحها بشدة:

1. Transform.origin -> transform.origin

(جعل الوصول إلى خاصية تحويل صغيرة)

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

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

2. يجب أن يكون الوصول إلى الثوابت لبعض الألوان المحددة مسبقًا بـ Color عكس Colors .

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

نسيج أطلس -> نسيج أطلس

يُسمى AtlasTexture لأنه يتبع التقليد المعتاد <Type>Texture حيث يمكن أن يكون <Type> Image ، Viewport ، Stream ،…

نسيج أطلس -> نسيج أطلس

يُسمى AtlasTexture لأنه يتبع التقليد المعتاد <Type>Texture حيث يمكن أن يكون <Type> Image ، Viewport ، Stream ،…

هذا ما يظهر عندما أكتب "أطلس".

هذا ما يحدث عندما نكتب Texture:

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

bigmonte و Transform سوف يمكن تسميته البنية إلى Transform3D في غودو 4.0 كما في هذه المسألة، لذلك سوف لم تعد بحاجة this. لجعلها واضحة أنه من الممتلكات.

تحرير: https://github.com/godotengine/godot/pull/38430

يجب أن يكون الوصول إلى الثوابت لبعض الألوان المحددة مسبقًا بـ Color عكس Colors .

أنا من اقترح ذلك في المقام الأول ، وأنا أعارضه بشدة. من الأفضل إبقائهم منفصلين ، نظرًا لأنه يزيد من قابلية اكتشاف أعضاء ثابتين Color (حاليًا Color8 ، ColorN ، و FromHsv ) عند استخدام الإكمال التلقائي في IDEs مختلفة. أفكر أيضًا في اقتراح إعادة تسمية Color.red إلخ -> Colors.RED في GDScript من أجل الاتساق.

بالمناسبة ، أعتقد أنك كنت تبحث عن # 16863.