मेरे लिए बहुत थकाऊ है, लेकिन गॉडस्पीड जो कोई भी instance को instantiate रूप में ठीक करता है जहां क्रिया के रूप में उपयोग किया जाता है।

16116

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

टाइलमैप.सेट_य_सॉर्ट_मोड (वैल) -> टाइलमैप.सेट_य_सॉर्ट_इनेबल्ड (वैल)
टाइलमैप.is_y_sort_mode_enabled () -> टाइलमैप.is_y_sort_enabled ()

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

कंट्रोल क्लास में और भी बहुत कुछ हैं, गेट/सेट का नाम वेरिएबल के समान होना चाहिए, जब आप वेरिएबल नाम जानते हैं तो हर बार डॉक की जांच करना कष्टप्रद होता है।

TileMap वर्ग में गेटटर और सेटर विधियों का एक समूह है जो उनके संबंधित गुणों से सहमत नहीं हैं। असल में मैं उस वर्ग में अधिकांश गेटर्स और सेटर्स का नाम बदलने का सुझाव दूंगा, इसलिए वे अपनी संपत्तियों के साथ-साथ अन्य वर्गों में नामकरण से सहमत हैं।

एनिमेशन.track_remove_key_at_position होना चाहिए
एनिमेशन.ट्रैक_रिमूव_की_एट_टाइम

तरीकों

• OS : execute को दो अलग-अलग तरीकों में विभाजित किया जाना चाहिए, एक अवरुद्ध और दूसरा गैर-अवरुद्ध।
  उदाहरण के नाम: execute / exec_process (अवरुद्ध) और spawn_process (गैर-अवरुद्ध) #19302

LineEdit में "text_changed" पर एक पैरामीटर new_text है, लेकिन TextEdit नहीं है।

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

मैं चाहता हूं कि VBoxContainer/HBoxContainer/GridContainer का नाम बदलकर साधारण VBox/HBox/ग्रिड कर दिया जाए ...

और बाद में इसका फिर से नाम बदल दिया जाएगा क्योंकि यह बहुत छोटा है जैसे pos->position :D

वे थोड़े लंबे हैं आप सही कह रहे हैं।

मैंने देखा कि गोडोट के विधि नामों में वर्तमान में दो अलग-अलग नामकरण परंपराएं हैं।

कभी-कभी, यह एक आम परंपरा का पालन करता है जो सी # या जावा जैसी भाषाओं के एपीआई में पाया जा सकता है, जैसे [action][object]() फॉर्म: यानी)

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

हालांकि, अन्य जगहों पर, यह [prefix][action][object]() एक अलग सम्मेलन का पालन करता है, जैसे:

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

वे कई में से कुछ उदाहरण हैं।

अगर हम भविष्य में कभी-कभी व्यापक अनुकूलता तोड़ने वाले परिवर्तन करने का जोखिम उठा सकते हैं, तो मैं देखना चाहता हूं कि उनका नाम बदलकर एकल, अच्छी तरह से परिभाषित नामकरण परंपरा का पालन किया जा सकता है (उम्मीद है कि पूर्व, क्योंकि यह अक्सर गोडोट के अंदर और बाहर दोनों का उपयोग किया जाता है)।

हालांकि, अन्य जगहों पर, यह [prefix][action][object]() एक अलग सम्मेलन का पालन करता है, जैसे:

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

मैंने सभी उपयोगों की दोबारा जांच नहीं की, लेकिन मैंने इस पद्धति के नामकरण की शैली को देखा है, हालांकि थोड़ा अजीब है, एक विशिष्ट सम्मेलन का भी पालन करता है। उदाहरण के लिए shape_owner_get तरीके:

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

"उपसर्ग" पहले तर्क को संदर्भित करता है, और get बाद का भाग वह है जो आप वास्तव में उस उपसर्ग में प्राप्त करेंगे। उदाहरण के लिए, shape_owner_get_shape_index(owner_id, shape_id) अवधारणात्मक रूप से get_shape_owner(owner_id)->get_shape_index(shape_id) , लेकिन स्क्रिप्टिंग एपीआई के संपर्क में कोई 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 तरीके:

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">

मैंने अब तक दिए गए अधिकांश सुझावों के साथ ओपी को अपडेट किया है।

मैं चाहूंगा कि VBoxContainer/HBoxContainer/GridContainer का नाम बदलकर साधारण VBox/HBox/ग्रिड कर दिया जाए

मैं आश्वस्त नहीं हूं, गोडोट में हम हर चीज को स्पष्ट नाम देने की कोशिश करते हैं, और उदाहरण के लिए Grid मुझे यह नहीं बताता कि यह एक कंटेनर है। VBox और HBox कोई तर्क दे सकता है कि बक्से परिभाषा के अनुसार कंटेनर हैं, लेकिन चूंकि हमारे पास BoxContainer जो Container जैसा नहीं है, मुझे लगता है कि वाचालता अभी भी वारंट है।

LineEdit में "text_changed" पर एक पैरामीटर new_text है, लेकिन TextEdit नहीं है।

मुझे नहीं लगता कि new_text को TextEdit में जोड़ना उपयोगी होगा। लाइनएडिट पर, इसमें केवल लाइनएडिट का पूरा टेक्स्ट होता है, न कि वह टेक्स्ट जो बदल गया है, इसलिए मैं यह भी तर्क दूंगा कि यह लाइनएडिट के text_changed में नहीं होना चाहिए। फिर भी, जब कोई नया वर्ण दबाया जाता है तो मल्टीलाइन टेक्स्टएडिट के पूर्ण टेक्स्ट के साथ काम करने के बजाय, यह अधिक सामान्य है कि आप इनपुट पर लाइनएडिट के पूर्ण टेक्स्ट का उपयोग करना चाहते हैं।

@ एकियन-मगा

मैंने सभी उपयोगों की दोबारा जांच नहीं की, लेकिन मैंने इस पद्धति के नामकरण की शैली को देखा है, हालांकि थोड़ा अजीब है, एक विशिष्ट सम्मेलन का भी पालन करता है

मैं इस तथ्य से अवगत हूं कि यह स्वयं का नामकरण सम्मेलन है। लेकिन यह अभी भी गोडोट के बाहर आमतौर पर उपयोग की जाने वाली चीज नहीं है, और थोड़ा भ्रमित करने वाला भी है क्योंकि कभी-कभी एक ही शब्द जैसे BlendShape का उपयोग उन तरीकों में किया जाता है जो दो अलग-अलग नामकरण सम्मेलनों का पालन करते हैं।

व्यक्तिगत रूप से, मैं स्थिरता के लिए उन सभी का नाम बदलकर GetPrefix* और SetPrefix* देखना चाहता हूं, लेकिन हो सकता है कि अन्य लोगों के पास इसके बारे में अलग-अलग विकल्प हों।

#16757 में तरीके बदल गए। तर्क क्रम अधिक समझ में आता है, लेकिन यह 3.0 और 3.1 (#19648) के बीच एपीआई संगतता को तोड़ता है।

मैं फिर से #9128 बढ़ाऊंगा: 3डी में translation बनाम 2डी में position एक अजीब असमानता है।
इसे 3.0 से पहले बढ़ा दिया गया था, लेकिन 3.0 के बाहर जाने के बाद बंद कर दिया गया था ... 3.0 बाहर होने के कारण।

OS.execute को posix_spawn उपयोग करना चाहिए।

नियंत्रण नोड्स के लिए एक और "मार्जिन" का नाम बदलकर "ऑफ़सेट" कर सकता है।
चूंकि मार्जिन दाईं ओर नकारात्मक है, यह लोगों को गुमराह करता है, खासकर स्टाइलबॉक्स के साथ तुलना करते समय

@ मुझे लगता है कि ऑफसेट बहुत सामान्य है, हालांकि मार्जिन सही शब्द हुआ करता था क्योंकि पहली बार पेश किए जाने पर वे दाईं ओर नकारात्मक रूप से उन्मुख नहीं थे

@ मुझे लगता है कि ऑफसेट बहुत सामान्य है, हालांकि मार्जिन एक अच्छा शब्द था (और पहली बार पेश किए जाने पर नकारात्मक नहीं था)

खैर, मार्जिन अब भ्रामक है कि वे नकारात्मक हैं। ऑफसेट सामान्य है, लेकिन अधिक समझ में आता है। मुझे नहीं लगता कि यह एक समस्या है कि वे सामान्य हैं क्योंकि यह नियंत्रण नोड्स के संदर्भ में है।
वैसे भी मैं बेहतर सुझावों के लिए खुला हूं। मैं इस विचार को यहां छोड़ना चाहता हूं क्योंकि इस तरह के संपत्ति नाम परिवर्तन का सुझाव पहले ही दिया जा चुका है। उदाहरण के लिए यहां देखें।

बक्सों/क्यूब्स के आकार का नाम असंगत रखा गया है।
टकराव के लिए BoxShape विस्तार का उपयोग करता है।
क्यूबमेश के पास x, y और z के साथ एक आकार की संपत्ति है, जो प्रत्येक आधे विस्तार हैं।
CSGBox में चौड़ाई, ऊंचाई और गहराई गुण होते हैं जिन्हें क्यूबमेश में x, y और z आकार की तरह परिभाषित किया जाता है।

आकार की संपत्ति के अलावा, कभी-कभी "क्यूब" का उपयोग किया जाता है और कभी-कभी "बॉक्स" का उपयोग किया जाता है। सब कुछ के लिए "बॉक्स" का उपयोग करना समझ में आता है क्योंकि क्यूबमेश के लिए x, y और z स्वतंत्र रूप से सेट किए जा सकते हैं और इस प्रकार यह एक बॉक्स भी है।

चूंकि हमारे पास लक्ष्य के रूप में एचटीएमएल 5 और यूडब्ल्यूपी है, जो वास्तव में ऑपरेटिंग सिस्टम नहीं हैं, इसलिए मैं ओएस का नाम बदलकर प्लेटफॉर्म (प्लेटफॉर्मविंडो, प्लेटफॉर्मयूनिक्स,...) करने का प्रस्ताव करता हूं।
ओएस/डिस्प्ले स्प्लिट के साथ भी समझ में आता है।

इस #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 , नए वैकल्पिक पैरामीटर या ब्रांड नई संपत्तियों/विधियों, नई कक्षाओं, आदि के साथ कई एपीआई परिवर्तन)। हम केवल पश्चगामी संगतता का ध्यान रखते हैं, आगे नहीं।

ओह मैं समझा! अगर ऐसा है तो मैं अभी वे बदलाव करूंगा।

अगर मैं सूची में एक जोड़ सकता हूं, तो लाइनएडिट और टेक्स्टएडिट नियंत्रण नोड्स वास्तव में एक दूसरे के साथ लगातार एपीआई रखने से लाभान्वित होंगे ताकि उनका उपयोग (ज्यादातर) एक दूसरे के लिए किया जा सके। अभी ऐसा लगता है कि उनके साथ मिलकर काम करने की कोशिश में एक गड़बड़ है, उस बिंदु तक जहां एक नोड को देखकर मैं दूसरे के बारे में भ्रमित हो जाता हूं।

@ 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 बहुत समान नाम हैं, मैं उन्हें मिलाता रहता हूं। नाम बदलने लायक? @vnen

मैंने "दशमलव" का नाम बदलकर "step_decimals" करने के लिए https://github.com/godotengine/godot/pull/21425 बदल दिया लेकिन "दशमलव" को उपनाम के रूप में रखें। यह मानते हुए कि यह विलय हो गया है, हम अगले संगतता टूटने में "दशमलव" को हटा सकते हैं, यदि नहीं, तो बस नाम बदल दें।

@mysticfall मेरी राय में अनावश्यक होने पर विधि नामों में "प्राप्त करें" शब्द नहीं होना बेहतर है।

कभी-कभी आप चाहते हैं कि कोई संपत्ति प्राप्त करने और सेट करने में सक्षम हो, लेकिन पहुंच को नियंत्रित करे। सी # में, गुण आपको ऐसा करने की अनुमति देते हैं और केवल पढ़ने और असाइन करके एक्सेस को नियंत्रित करते हैं जैसे कि यह एक फ़ील्ड था, जो अच्छा है।

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

हालाँकि, GDScript में, गुण कोई चीज़ नहीं हैं (?) शब्द प्राप्त किए बिना हमारे पास एक विधि नाम भी हो सकता है। अधिकांश विधियां कुछ लौटाती हैं इसलिए -नेस होना बेहतर है: चूंकि जीडीस्क्रिप्ट में गुण हैं, इसलिए मैं उन्हें अधिक बार उपयोग करने का सुझाव देता हूं। ध्यान दें कि मुझे इस पर कोई दस्तावेज नहीं मिला। मुझे setget साथ जीडीस्क्रिप्ट के अंदर इसे कैसे करना है, इस पर दस्तावेज़ीकरण मिला लेकिन सी ++ के माध्यम से जोड़ने के बारे में क्या?

संक्षेप में, मैं सहमत हूं कि असंगत स्थानों पर "प्राप्त" करना अच्छा नहीं है, लेकिन मेरी राय में आदर्श समाधान इस समय GDScript गुणों या हम "प्राप्त" को हटा सकते हैं और "सेट" रख सकते हैं। .

@aaronfranke GDScript में एक तरह से गुण होते हैं, क्योंकि इंजन वर्ग एक गेटर और सेटर (या केवल एक गेटर) को परिभाषित कर सकते हैं और GDScript को गुणों के रूप में उजागर कर सकते हैं। उस ने कहा, मैं तरीकों से get और set को हटाने के खिलाफ हूं क्योंकि 1) यह नाम को स्पष्ट करता है और 2) यह गेटर और सेटर के बीच अंतर करता है। उदाहरण के लिए 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 मैं add_force को (स्थिति, बल) में बदलने के बजाय apply_impulse (बल, स्थिति) में बदलना पसंद करूंगा। बल की स्थिति एक वैकल्पिक पैरामीटर है इसलिए इसे अंत में जाना चाहिए। लेकिन सभी बलों और आवेगों में एक बल वेक्टर होना चाहिए।

@aaronfranke फेयर पॉइंट। उस स्थिति में, आवश्यक स्वैप की सूची है:

• 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- उपसर्गों का उपयोग करना 'जावावाद' की तरह है जिसे सी # में टाला जाना बेहतर है।

मेरी मुख्य चिंता shape_owner_get_shape या node_get_input_count जैसे मामले में 'डोमेन उपसर्ग' का उपयोग था, इसलिए यदि हम उन्हें Get- या Set- बिना उचित C# गुणों के रूप में पुन: कार्यान्वित कर सकते हैं

एक तरफ ध्यान दें, मुझे हमेशा यह अजीब लगता था कि गोडोट के सी # एपीआई में गुणों में गेटर्स और सेटर्स का मिलान सेट होता है, उदाहरण के लिए, Node.Name और Node.GetName() / Node.SetName() ।

यह मेरे लिए बेमानी लगता है, लेकिन अगर कोई कारण है कि हम ऐसा सम्मेलन क्यों रखते हैं, तो मुझे लगता है कि हमें NodeInputCount और GetNodeInputCount() / SetNodeInputCount() दोनों मिलेंगे, अगर हम हैं सुझाव के अनुसार node_get_input_count का नाम बदलने के लिए।

दोस्तों, कृपया इस मुद्दे के बाहर सी # एपीआई और सामान्य सम्मेलनों पर चर्चा जारी रखें, जो गोडोट एपीआई पर केंद्रित है। गोडोट एपीआई (सी ++, सी और जीडीस्क्रिप्ट) को सी # के लिए अनुकूलित नहीं किया जाएगा, जब तक कि यह अन्य भाषाओं के लिए भी सुधार न हो।

@ akien-mga मुझे नहीं लगता कि यह सी # विशिष्ट बात है जो चर्चा कर रही है कि node_get_input_count का नाम बदलकर get_node_input_count ।

नहीं, मेरा मतलब है कि इस मुद्दे में कुछ भी सी # विशिष्ट नहीं होना चाहिए। यदि आवश्यक हो तो सी # -विशिष्ट संगतता टूटने के लिए एक और मुद्दा हो सकता है (हालांकि उनमें से कई आईआईएनएम पहले से ही हैं)।

स्थानिक का नाम बदलकर Node3D करने के बारे में क्या? मुझे हमेशा यह अजीब लगा।

@KoBeWi गोडोट वर्तमान में उपयोग की जाने वाली नामकरण योजना 2D सामान के लिए "Thing2D" है और 3D सामान के लिए केवल "थिंग" है, इसलिए यह बाकी 2D कोड के साथ काफी संगत है। बेशक "2D" को हटाने के पैटर्न के बाद "स्थानिक" को कॉल करने के लिए तार्किक बात "नोड" होगी, लेकिन वह नाम पहले से ही निश्चित रूप से लिया गया है।

गोडोट वर्तमान में जिस नामकरण योजना का उपयोग करता है वह 2डी सामान के लिए "थिंग2डी" है और 3डी सामान के लिए सिर्फ "थिंग" है।

तो शायद सब कुछ 3D को "Thing3D" में बदल दें? इसने मेरे दिमाग को भी पार कर लिया, लेकिन यह ओवरकिल जैसा लगता है।
वैसे भी, मैंने अभी सुझाव दिया है। ऐसा नहीं है कि यह बहुत महत्वपूर्ण है। साथ ही, Spatial2D, Spatial से भी बदतर है।

तो, String.right() दिए गए स्थान से n सही वर्ण देता है। क्या यह अधिक सहज नहीं होगा यदि यह केवल n वर्णों को दाईं ओर से गिनता है?

"abcdef".right(2)
"cdef" के बजाय "ef" वापस आ जाएगा। आईएमओ यह बेहतर होगा।

मुझे भी यही उम्मीद थी।

पायथन की वही विधि है जो अधिकांश उपयोगकर्ता जीडीस्क्रिप्ट की तुलना पायथन से करना पसंद करते हैं। यह शायद इसे बदलने में और भी भ्रमित करेगा।

@KoBeWi मैं सहमत हूँ। मुझे वर्तमान कार्यान्वयन और सबस्ट्रिंग के बीच अंतर नहीं दिख रहा है।

गोडोट substr आपको स्ट्रिंग के आकार को इंगित करने के लिए मजबूर करता है यदि आप दाईं ओर सब कुछ चाहते हैं।

@Zylann अधिकांश कार्यान्वयन दूसरे पैरामीटर को छोड़ने की अनुमति देते हैं। मैं इसे गोडोट के पक्ष में एक मुद्दा मानूंगा। इसके अलावा, मेरे पास substr एक अलग नाम के साथ एक नई विधि की तुलना में दूसरा पैरामीटर वैकल्पिक बनाना है।

@Zylann @neikeq यह गैर-अधिभारित विधियों का एक दुर्भाग्यपूर्ण परिणाम है, लंबाई विनिर्देश और लंबाई विनिर्देश दोनों होने का कोई तरीका नहीं है।

@aaronfranke उम, लेकिन डिफ़ॉल्ट तर्क मौजूद हैं। 0 या -1 को कोई निर्दिष्ट लंबाई के रूप में नहीं गिना जा सकता है।

get_selected_id() को OptionButton से निकालने की आवश्यकता है, वर्तमान में यह हमेशा -1 लौटाता है। https://github.com/godotengine/godot/pull/21837 विलय के बाद get_selected_id() get_selected() के समान वापस आ जाएगा।

ऐसी कई विधियां हैं जो हर बार सच हो जाती हैं, उन्हें शायद शून्य बना दिया जाना चाहिए।

WindowDialog.get_close_button ()
कन्फर्मेशनडायलॉग.गेट_कैंसल () -> कन्फर्मेशनडायलॉग.गेट_कैंसल_बटन ()
AcceptDialog.get_ok () -> AcceptDialog.get_ok_button ()

ट्री नोड में get_selected() फ़ंक्शन है जो फ़ोकस किए गए TreeItem को वापस करने लगता है। इसका नाम बदलकर get_active() करना उचित हो सकता है, क्योंकि फ़ोकस और चयन अलग-अलग चीज़ें हैं।

इनपुट मैप में load_from_globals() होना चाहिए load_from_project_settings() ।

मैं एक जोड़ूंगा: टाडा: सभी सुझावों पर प्रतिक्रिया जो ओपी में एकीकृत किए गए हैं, एक बेहतर अवलोकन के लिए।

स्थिरता के लिए global_rotate का नाम बदलकर rotate_global और rotate_object_local का नाम बदलकर rotate_local दिया जाना चाहिए और ताकि सभी घुमाने के तरीके "रोटेट" से शुरू हों।

ग्लोबल_रोटेट का नाम बदलकर रोटेट_ग्लोबल किया जाना चाहिए और रोटेट_ऑब्जेक्ट_लोकल को कंसिस्टेंसी के लिए रोटेट_लोकल नाम दिया जाना चाहिए और ताकि सभी रोटेट तरीके "रोटेट" से शुरू हों।

ठीक है, दूसरी ओर मुझे यह पसंद है कि वैश्विक-संबंधित फ़ंक्शन (जैसे 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 है क्योंकि ऐसा लगता है थोड़ा अक्ष मार्कर।

यदि उनका नाम बदलकर Gizmo कर दिया जाता तो शायद उन्हें और अधिक सामान्य उपयोग दिए जा सकते थे।

ध्यान दें कि कंट्रोल ट्री में समान नोड ReferenceRect , इसलिए, ReferenceAxis/2D भी काम कर सकता है।

अभी इस मुद्दे को पसंद कर रहे हैं। बाद में इससे नफरत हो सकती है जब टूटना वास्तव में हिट हो;)

विनम्र Array वर्ग के लिए कुछ प्रस्ताव:

• duplicate → या तो copy या clone । मैं ऐसी किसी भी भाषा के बारे में नहीं जानता जो इस अवधारणा को "डुप्लिकेटिंग" कहती हो। copy वह है जिसे इसे पायथन और सी ++ में कहा जाता है, इसलिए यह गोडोट के लिए स्वाभाविक विकल्प होगा। clone जावा और जावास्क्रिप्ट से है और शायद थोड़ा अधिक सटीक है।
• 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 - शायद: डी

कृपया वर्ग का नाम बदलने पर विचार करें JavaScript से HTML5 या कुछ और।
इस वर्ग में एकल विधि है और यह Script से विस्तारित नहीं है और इसका उपयोग अन्य प्लेटफार्मों में नहीं किया जाता है।

JavaScript का उपयोग भविष्य में जावास्क्रिप्ट भाषा बाइंडिंग के वर्ग नाम के रूप में किया जा सकता है।

जैसा कि @clayjohn द्वारा इंगित किया गया है, WORLD_MATRIX कैनवास इटैम शेडर्स में वास्तव में एक मॉडलव्यू मैट्रिक्स है। @reduz इस बात से सहमत है कि 4.0 में हमें इसे वास्तविक मॉडल से बदलना चाहिए और मैट्रिक्स देखना चाहिए, जैसे 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 (इनपुट इवेंट)
खेल के लिए एक इनपुटइवेंट फ़ीड करता है। कोड से इनपुट ईवेंट को कृत्रिम रूप से ट्रिगर करने के लिए उपयोग किया जा सकता है।

पार्स भ्रामक है, पार्स प्राप्त होगा और प्रसंस्करण होगा लेकिन विवरण एक इनपुट भेजने या ट्रिगर करने का संकेत देता है

#24153 के अनुसार - CanvasLayer परत का उपयोग यह वर्णन करने के लिए करता है कि किस परत पर इसके नोड्स को खींचना है। लेकिन लगभग हर दूसरा 2D नोड एक ही चीज़ का वर्णन करने के लिए "Z इंडेक्स" ( z_index ) शब्दावली का उपयोग करता है (जो पहले प्रतीत होता है)। जैसा कि @swarnimarun ने https://github.com/godotengine/godot/issues/24153#issuecomment -444950584 परतों के नामों में सुधार करने का सुझाव दिया।

क्या OS.has_feature() / Platform.has_feature() ProjectSettings जैसी किसी चीज़ में अधिक समझदार होंगे, क्योंकि वे विशेष रूप से OS के बारे में कुछ भी नहीं बताते हैं?

ग्रिडमैप को टाइलमैप के साथ एकीकृत करने के लिए set_cell_item का नाम बदलकर set_cell किया जा सकता है?

ग्रिडमैप को टाइलमैप के साथ एकीकृत करने के लिए set_cell_item का नाम बदलकर set_cell किया जा सकता है?

इसके बारे में सोचने के लिए आओ, शायद ग्रिडमैप्स के लिए भी set_cellv होना चाहिए?

एआरवीआरइंटरफ़ेस:

• ar_is_anchor_detection_enabled -> anchor_detection या समान
• interface_is_initialized -> is_initialized या is_interface_initialized

एनिमेशन प्लेयर:

• play_backwards को हटाया जा सकता है क्योंकि play पास इसके लिए एक वैकल्पिक बूल है।

बेसबटन / टकराव आकार / टकराव बहुभुज / टक्कर आकार 2 डी / टकराव पॉलीगॉन 2 डी:

• disabled बूल को enabled बूल में बदलें।

बोन2डी:

• get_index_in_skeleton -> get_skeleton_index

• play_backwards को हटाया जा सकता है क्योंकि play पास इसके लिए एक वैकल्पिक बूल है।

यह पठनीयता के लिए बुरा होगा, कम से कम जब तक #6866 लागू नहीं किया जाता है। यह सी # में कोई समस्या नहीं है क्योंकि यह नामित पैरामीटर का समर्थन करता है।

id_pressed( int ID ) और id_focused( int ID ) में आईडी लोअर केस होना चाहिए।

^
वह परिवर्तन वास्तव में किसी भी अनुकूलता को नहीं तोड़ेगा। इसे शायद एक अलग मुद्दा मिल सकता है।

^
वह परिवर्तन वास्तव में किसी भी अनुकूलता को नहीं तोड़ेगा। इसे शायद एक अलग मुद्दा मिल सकता है।

ये सही है!

28746 - Node.replace_by एक नाम के रूप में भ्रमित करने वाला हो सकता है। सुनिश्चित नहीं है कि वास्तव में एक बेहतर नाम क्या हो सकता है।

@ बोजिदार-बीजी शायद 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 , क्योंकि "अनुवाद" का उपयोग स्थानिक नोड्स में "स्थिति" के लिए किया जाता है न कि "भाषा" के लिए।

set_as_toplevel() का नाम बदलकर set_as_top_level() किया जा सकता है , लेकिन इसके व्यवहार

TouchScreenButton को 4.0 के लिए देखा जाना चाहिए, क्योंकि यह परिवर्तन टूट सकता है: https://github.com/godotengine/godot/issues/28814

CanvasItem विधि:

आरआईडी get_canvas_item() const
इस आइटम के लिए VisualServer द्वारा उपयोग किया गया कैनवास आइटम RID देता है।

फिर इसका नाम बदलकर get_rid() दिया जाना चाहिए।

get_canvas_item() भ्रमित करने वाला है क्योंकि मैं पहले से ही CanvasItem नोड पर हूं। यह स्थिरता भी सुनिश्चित करता है क्योंकि अन्य वर्गों में समान get_rid() विधि पहले से ही है: CollisionObject , Resource ।

क्या Label को TextLabel बदला जाना चाहिए? कई बार अब मैं एक टेक्स्ट ऑब्जेक्ट डालना चाहता था और भूल गया कि इसे क्या कहा जाता था, इसलिए मैं "टेक्स्ट" की खोज करता हूं और केवल RichTextLabel दिखाता है। TextLabel RichTextLabel साथ अधिक संगत होगा क्योंकि यह अभी भी टेक्स्ट है लेकिन अमीर के बिना।

संदर्भ के लिए, एकता के पास Text और TextMesh , और मैं व्यक्तिगत रूप से इसे लेबल के बजाय टेक्स्ट के रूप में संदर्भित करता हूं।

मैं Tree और GraphNode का नाम बदलकर TreeView और GraphEditNode बारे में भी सोच रहा हूं।
Tree , इसका कारण यह है कि यह वैश्विक जीयूआई नोड आईएमओ के लिए एक नाम का बहुत व्यापक है, अन्य सभी जीयूआई ढांचे जिन्हें मैं जानता हूं TreeView का उपयोग करता हूं।
GraphNode , ऐसा इसलिए है क्योंकि मैंने हाल ही में वास्तविक ग्राफ संरचनाओं को शामिल करने वाले कुछ प्रोटोटाइप पर काम किया था, और मैं न तो Node और न ही GraphNode कर सकता था जो काफी कष्टप्रद था।

@Zylann चूंकि ग्राफ़ नोड्स ग्राफ़ (पेड़ नहीं) के लिए दृश्य/नियंत्रण हैं, ग्राफ़कॉन्टेनर बेहतर हो सकता है। 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 होना चाहिए, क्योंकि यह 3D है। और Area2D तो होना चाहिए Area । एक क्षेत्र स्वभाव से 2D है।

GridMap शायद CubeMap होना चाहिए। इस पर निश्चित नहीं है, बस वह "ग्रिड" मेरे लिए एक 2D चीज़ की तरह लगता है।

CheckButton नियंत्रण SwitchButton या कुछ और होना चाहिए। यह भ्रमित करने वाला है क्योंकि Checkbox । या शायद इसे पूरी तरह से हटा दिया जाना चाहिए। यह वैसे भी चेकबॉक्स के समान कार्य करता है, जहां तक ​​​​मैं कह सकता हूं।

मैं फिर से सहमत हूं: चेकबटन, और अन्य सिर्फ कॉस्मेटिक हैं।

या शायद इसे पूरी तरह से हटा दिया जाना चाहिए। यह वैसे भी चेकबॉक्स के समान कार्य करता है, जहां तक ​​​​मैं कह सकता हूं।

समान कार्यक्षमता होने के बावजूद, UX-वार, CheckBox और CheckButton अलग-अलग चीज़ें हैं।
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@ रोडियो-मैककेबे एरिया को 2डी समकक्ष के साथ संगति के लिए इस तरह कहा जाता है, area की परिभाषाओं में से एक a particular extent of space or surface ।
Cubemaps 3D छवियां हैं, वाक्य रचना शुद्धता संदर्भ पर होनी चाहिए या यह केवल भ्रम जोड़ती है।

grabber_area -> slider_progress
slider -> slider_background

या केवल:
grabber_area -> progress
slider -> background ?

शायद:
grabber_area -> progress_area या progressed_area
slider -> progress_background ?

Cubemaps 3D छवियां हैं, वाक्य रचना शुद्धता संदर्भ पर होनी चाहिए या यह केवल भ्रम जोड़ती है।

@ ईऑन-एस मेला काफी, मुझे यह नहीं पता था।

क्षेत्र को 2डी समकक्ष के साथ संगति के लिए ऐसा कहा जाता है

समस्या यह है कि 2डी समकक्ष भी असंगत है। गणित में एक क्षेत्र लंबाई * ऊंचाई है, बस कोई तीसरा आयाम नहीं है। इसलिए एरिया 2 डी कहने का कोई मतलब नहीं है, क्योंकि यह एक एरिया होने के कारण 2डी होना चाहिए। "क्षेत्र" की एक और, अधिक गणितीय परिभाषा है:

सतह को लाइनों के एक सेट के भीतर शामिल किया गया है, विशेष रूप से: सतह के माप के बराबर इकाई वर्गों की संख्या

इसी तरह, गणित में 3D स्पेस को "वॉल्यूम" कहा जाता है। मैं पहली बार भ्रमित था जब मैंने पाया कि क्षेत्र वास्तव में एक 3D नोड था, इसके बजाय क्षेत्रों को अजीब तरह से "Area2D" कहा जाता था। चूंकि यह एक गेम इंजन है, इसलिए हमें गणित की परिभाषाएं लेनी चाहिए।

जबकि मैं तर्क को समझता हूं, मुझे नहीं पता कि नाम बदलने से कोई विशेष लाभ होगा, खासकर नए लोगों को। मैं सहमत हूं कि "वॉल्यूम" इसके लिए अधिक उपयुक्त शब्द हो सकता है, लेकिन मुझे लगता है कि 3D के लिए "वॉल्यूम" और 2D के लिए "एरिया" थोड़ा भ्रमित करने वाला हो सकता है। आखिरकार, बहुत सारे नोड्स जिनके 2D और 3D दोनों प्रकार हैं, उनके नाम होंगे "

मुझे लगता है कि नामकरण योजना पहली जगह में वहाँ जा रहा है इसका मतलब है कि हम नियम का एक अपवाद नहीं होना चाहिए (ज्यादा के रूप में वहाँ कुछ नोड्स जो केवल ज्यादातर योजना से चिपके रहे हैं), यहां तक कि जहां एक संस्करण के लिए एक और शब्द बनाना होगा अधिक समझदारी, अन्यथा यह उपयोगकर्ताओं को भ्रमित करने की संभावना है।

अगर मैं, हालांकि... शायद Area2D से Area , और Area से Area3D नाम बदल सकता हूं?

संपादित करें: ऐसा लगता है कि <> से घिरा हुआ पाठ तब तक प्रकट नहीं होता जब तक आप <> . से बच नहीं जाते

@ रोडियो-मैककेबे मुझे यह आभास होता है कि नोड नामकरण का इरादा मानव भाषा में चीजों को व्यक्त करना है न कि गणितीय। तो "क्षेत्र" का मतलब ज्यामितीय नहीं है, बल्कि एक जगह है, जैसे किसी स्तर या मंच के अंदर। आईई - क्षेत्र 1.

नोड में सीधे तौर पर कोई ज्यामिति नहीं होती है या स्वयं एक ज्यामिति होती है, इसलिए मेरे जैसे अन्य लोगों को आश्चर्य होगा कि इसे बनाते समय इसका क्षेत्र/मात्रा कहां है, और फिर मुझे क्षेत्र और वॉल्यूम (आकृतियां) को एक क्षेत्र में क्यों संलग्न करना होगा और आयतन?

यदि इसे ज्यामितीय क्षेत्र के साथ भ्रमित करने से बचने के लिए नाम बदलने से गुजरना पड़ा, तो पर्यायवाची शब्द शायद जाने का रास्ता होगा।

उन्हें कहा जा सकता है:

• क्षेत्र2डी/3डी
• स्पेस2डी/3डी
• जोन2डी/3डी
• फील्ड2डी/3डी
• आदि।

बीटीडब्ल्यू, इसके अलावा यह ट्रैकर केवल विधि, गुणों और संकेतों (नोड्स के लिए नहीं) के लिए है, @reduz ने हाल ही में उल्लेख किया है कि 4.0 पर संगतता टूटने को कम करने के इरादे हैं, इसलिए शायद इस विशाल सूची को जोड़ने से पहले कोर देवों से समीक्षा की आवश्यकता हो सकती है चीजें हमेशा के लिए...

ऐसा लगता है कि लक्ष्य चीजों को उतना ही छोड़ना है जितना वे अभी हैं, इसलिए इस तरह की चीजें 4.0 के बाद अगले प्रमुख संस्करण तक वापस लात मारी जा सकती हैं?

कृपया इस मुद्दे को मुख्य योगदानकर्ताओं के लिए छोड़ दें, यह हर जगह बड़े नामों के सुझाव देने का स्थान नहीं है, इसका उद्देश्य वास्तविक विसंगतियों को ठीक करना है जो एपीआई को बोझिल बनाते हैं।

ओपी में उल्लिखित परिवर्तन एक बड़ा संगतता टूटना नहीं है और अधिकांश 4.0 के लिए किया जाएगा, जिसे @reduz ने संदर्भित किया है वह "आपकी परियोजना को अब और नहीं खोला जा सकता" की संगतता टूटना है जैसे कि 2.1 और 3.0 के बीच (बहुत अधिक) बदले में सिर्फ चीजों का नाम बदला जा रहा है, जैसे कि ऑडियो और पार्टिकल सिस्टम पूरी तरह से फिर से लिखे जा रहे हैं, आयात प्रणाली बदल रही है, आदि)।

वहाँ, 4.0 में कुछ संगतता टूटना होगा अन्यथा यह 4.0 बुलाया नहीं किया जाएगा। यह उचित होगा और पोर्टिंग आसान होगी, संभवतः एक कनवर्टर के साथ यह सुनिश्चित करने के लिए कि दृश्यों और स्क्रिप्ट में उपयोग किए जाने पर नामित गुणों, विधियों और संकेतों को ठीक से परिवर्तित किया जाता है। यह किसी भी मामले में इस पर चर्चा करने की जगह नहीं है :)

Control के _set_anchor() को भी शुरुआत "_" को छोड़ देना चाहिए।

पॉपअपमेनू में index_pressed(index) और id_pressed(id) जो ठीक काम करता है, लेकिन id_focused जो वास्तव में आइटम की आईडी के बजाय इंडेक्स के साथ उत्सर्जित होता है।

इसके लिए अभी तक कोई मुद्दा नहीं है लेकिन आज एकियन को यह सुझाव देने के बाद सूची में डालने लायक है।

ARVRServer को रिफलेक्टर करें, इसलिए इसे XRServer कहा जाता है। जब हमने इसे डिज़ाइन किया था तो VR और AR दोनों को इंगित करने के लिए XR शब्द अभी तक व्यापक उपयोग में नहीं था। और नहीं, मैं MRServer के लिए नहीं जा रहा हूँ;)

क्या रेकास्ट में "सक्षम" के बजाय "अक्षम" संपत्ति होनी चाहिए? CollisionShape में एक "अक्षम" है जो डिफ़ॉल्ट रूप से false है (जिसका अर्थ है कि वे डिफ़ॉल्ट रूप से सक्षम हैं)। इसके विपरीत, रेकास्ट की "सक्षम" संपत्ति डिफ़ॉल्ट रूप से false है, जो उन्हें डिफ़ॉल्ट रूप से अक्षम कर देती है।

या, सकारात्मक रूप का उपयोग करने के लिए (जो मुझे लगता है कि समग्र रूप से कम भ्रमित है), क्या CollisionShape में "अक्षम" के बजाय "सक्षम" संपत्ति (डिफ़ॉल्ट रूप से true ) होनी चाहिए?

@Calinou मुझे पता नहीं है कि इसके लिए एक अलग मुद्दे की आवश्यकता होगी, लेकिन अगर हमें लगातार बने रहने की आवश्यकता है, तो मैं वास्तव में ऐसे बूलियन हमेशा Enabled होना पसंद करूंगा। कुछ अक्षम करने के लिए बूलियन को true पर सेट करना मुझे अक्सर भ्रमित करता है।

@Calinou मैं सहमत हूं @Zylann डबल नकारात्मक भ्रमित कर रहे हैं और जब भी संभव हो इससे बचा जाना चाहिए। हमें इसके बजाय "अक्षम" बूल को "सक्षम" वाले में बदलना चाहिए। यह ठीक है अगर किसी चीज़ का डिफ़ॉल्ट मान "सत्य" है। मेरी यह चर्चा #17212 और #21822 में हुई थी।

माउस और टच इनपुट ईवेंट की speed प्रॉपर्टी का नाम बदलकर velocity दिया जाना चाहिए क्योंकि यह वेक्टर2 है।

InputMap : get_action_list( String action ) फ़ंक्शन का नाम यह नहीं बताता कि यह क्या करता है।
चूंकि यह किसी दिए गए क्रिया से जुड़े EventInputs लौटाता है, यह get_action_events(String action)

संभावित भ्रम से बचने में भी मदद मिल सकती है क्योंकि InputMap में get_actions( ) नामक एक और फ़ंक्शन है और दोनों नामों का अर्थ संदर्भ से बाहर एक ही बात हो सकता है।

#30736 से संबंधित, हमें दो गोडोट भौतिकी इंजनों का नाम बदलकर "GodotPhysics2D" और "GodotPhysics3D" करना चाहिए, क्योंकि यह कहना कि "GodotPhysics" के साथ कुछ टूट गया है, दो बहुत अलग चीजें हो सकती हैं।

Object._init() से Object._new() नाम बदलने के बारे में क्या?

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

new — _init

मुझे लगता है कि _init वास्तव में पायथन के __init__ , जबकि new कक्षा की एक विधि है, उदाहरण नहीं।

क्या String : empty() -> is_empty() जैसा कुछ इस धागे के लिए उपयुक्त है? मुझे हमेशा लगता है कि यह पहली बार में एक स्ट्रिंग को साफ़ करने का एक कार्य है।

@vortexofdoom अगर विधि नाम विसंगतियों और/या उनका नाम कैसे रखा जाना चाहिए, तो हाँ।

मैं जोड़ सकता हूं कि String और NodePath में क्रमशः empty और is_empty तरीके हैं जो एक ही काम करते हैं। बाकी कोर बिल्ट-इन प्रकार empty नाम पसंद करते हैं, इसलिए हो सकता है कि is_empty का नाम बदलकर NodePath कर दिया जाए ताकि इसे सभी बिल्ट-इन प्रकारों में सुसंगत बनाया जा सके, लेकिन यह मुझे लगता है कि संभावित रूप से कुछ गंभीर संगतता टूटना शामिल हो सकता है।

मुझे हमेशा लगता है कि यह पहली बार में एक स्ट्रिंग को साफ़ करने का एक कार्य है।

अधिकांश विधियां उसके लिए गोडोट में clear नाम का उपयोग करती हैं।

@Xrayez ,

अधिकांश विधियाँ उसके लिए गोडोट में स्पष्ट नाम का उपयोग करती हैं।

मुझे पता है, केवल इस तथ्य का जिक्र करते हुए कि empty एक क्रिया के साथ-साथ एक विशेषण भी है, और is_ जोड़ने से यह स्पष्ट हो जाता है कि कौन सा अर्थ है।

मैं उस बूल के लिए सभी बिल्ट-इन में is_empty का उपयोग करने के पक्ष में हूं।

गोडोट 3.0 और 3.1 में, हमारे पास C# में Set तरीके थे। हालांकि, ये वास्तव में केवल एक कंस्ट्रक्टर और असाइनमेंट का उपयोग करने की तुलना में कोई वास्तविक कार्यक्षमता नहीं जोड़ते हैं, फिर भी कोड को चुपचाप विफल होने की अनुमति देते हैं, इसलिए उन्हें अप्रचलित कर दिया गया है। वे ज्यादातर मेरे द्वारा कोशिश करने और सुसंगत होने के लिए जोड़े गए थे, क्योंकि क्वाट के लिए एक विधि पहले से मौजूद थी, जो कोर से सेट विधियों से आई थी। अधिक जानकारी के लिए देखें #30744

GDScript में set_euler और set_axis_angle , लेकिन एक ही काम करने के लिए कंस्ट्रक्टर भी हैं ( q.set_axis_angle(myvec3, myval) को q = Quat(myvec3, myval) बदला जा सकता है। कोर में भी ये तरीके हैं। आधार के लिए, लेकिन वे GDScript के संपर्क में नहीं हैं।

सवाल यह है कि इसके बारे में क्या किया जाना चाहिए? क्या क्वाट सेट विधियों को रचनाकारों के पक्ष में बहिष्कृत किया जाना चाहिए और सी # के अनुरूप होना चाहिए, या क्या उन्हें प्रदर्शन किए जा रहे ऑपरेशन के बारे में स्पष्ट रखना उचित है? यदि उत्तरार्द्ध, क्या आधार विधियों को भी उजागर किया जाना चाहिए?

@aaronfranke मुझे हमेशा यह अजीब लगता था कि उन

@aaronfranke यह मुद्दा एपीआई में चीजों का नाम बदलने के बारे में है, न कि इंजन की कार्यक्षमता या बग के बारे में।

Geometry के 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 के instance_create2() को वास्तव में यह वर्णन करने के लिए बदला जाना चाहिए कि यह instance_create() से अलग क्या करता है।

ऑब्जेक्ट-रिलेटिव अनुवादों के लिए, Spatial में translate_object_local जो Vector3 लेता है, और Node2D में move_local_x और move_local_y , जो तैरता है। दोनों Spatial और Node2D ऐसे तरीके होने चाहिए जो क्रमशः Vector3 और Vector2 लेते हों, और या तो translate_local या local_translate translate_object_local से सरल नाम हो।

@leonkrause render_width और render_height बजाय इसे viewport_width और viewport_height या शायद canvas_width और canvas_height , क्योंकि यह कैनवास व्यूपोर्ट के लिए उपयोग किया जाने वाला संदर्भ रिज़ॉल्यूशन है, और वास्तव में रेंडरिंग को प्रभावित नहीं करता है।

@ akien-mga कृपया अपनी सूची में ट्री नेविगेशन विधियों को जोड़ने पर विचार करें। वे बहुत भ्रमित रूप से नामित हैं और अच्छी तरह से प्रलेखित नहीं हैं।

जब मैंने पहली बार उनका सामना किया तो मैंने सोचा कि get_child () और get_next (), get_prev () ने एक पुनरावर्तक संचालित किया जैसे वे निर्देशिका काम करते हैं। मुझे यह पता लगाने के लिए अपना खुद का परीक्षण करना पड़ा कि वे जो कुछ भी करते हैं वह हर बार एक ही पॉइंटर उत्पन्न करते हैं।

get_child() का नाम बदलकर 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* विधियों की तरह ही काम करता है।

इसका नाम बदलकर क्या रखा जाना चाहिए? मुझे यकीन नहीं है। जावास्क्रिप्ट इसके लिए JSON.stringify का उपयोग करता है। PHP में json_encode फ़ंक्शन है। सीधे GDScript में एक समान कार्य होता है - to_json ।

यूपीडी. JSON.serialize भी संभव है, लेकिन वर्णों की संख्या से यह JSON.stringify जैसा ही है। :मुस्कुराओ:

मैं "serialize" शब्द के खिलाफ सुझाव दूंगा क्योंकि यह आमतौर पर बाइनरी सीरियलाइजेशन के लिए उपयोग किया जाता है, और इस तरह के आउटपुट को उस फॉर्म में आने के लिए और कदम उठाने की आवश्यकता होगी।

चूंकि इस वर्ग में JSON और वेरिएंट प्रकारों के बीच जाने के लिए केवल दो तरीके हैं, इसलिए मैं json शब्द वाले तरीकों के खिलाफ सुझाव दूंगा क्योंकि यह व्यर्थ है।

अब, चीजें हैं जो एक अच्छा नाम होगा के लिए, मौजूदा parse विधि वास्तव में एक स्पष्ट विपरीत शब्द (नहीं है यहाँ देख )। शायद इनमें से एक: encode , create , compose , generate ? यदि encode का उपयोग किया जाता है तो दूसरी विधि का नाम बदलकर decode करना समझदारी होगी।

मैंने format और write को parse व्युत्क्रम के रूप में उपयोग करते देखा है। हालाँकि, जावास्क्रिप्ट में उपयोग किए जाने के कारण stringify को डेवलपर्स के बीच बेहतर-ज्ञात होने का लाभ है।

मैंने format और write को parse व्युत्क्रम के रूप में उपयोग करते देखा है। हालाँकि, जावास्क्रिप्ट में उपयोग किए जाने के कारण stringify को डेवलपर्स के बीच बेहतर-ज्ञात होने का लाभ है।

str2var VariantParser और var2str VariantWriter आंतरिक रूप से

तो मैं write लिए हूं, निरंतरता जीतती है। मैं

@Xrayez print को write बदलें? पायथन से पास्कल तक? :हस रहा:

जैसा कि https://github.com/godotengine/godot-proposals/issues/252#issuecomment -557901552 में सुझाया गया है, यह clear_color से background_color से संबंधित हर चीज का नाम बदलने का अर्थ हो सकता है (इसमें शामिल हैं परियोजना सेटिंग्स)।

मुझे उम्मीद है कि 4.0 बेहतर प्रदर्शन, जीआई जांच सुधार, सामान्य प्रचार आदि के कारण गोडोट में नए लोगों की एक बड़ी लहर लाएगा।

यदि वे परिवर्तन 4.0 के साथ किए जाते हैं, तो इन लोगों को एक कठिन लैंडिंग मिलेगी क्योंकि लगभग कोई मौजूदा ट्यूटोरियल (आधिकारिक "पहला गेम" ट्यूटोरियल के अलावा) अब उनके लिए काम नहीं करेगा।

यदि वे परिवर्तन 4.0 के बाद किए जाते हैं, मान लीजिए 4.1 में, यह उन लोगों के लिए एक अत्यंत ऊबड़-खाबड़ सवारी होगी। उन्होंने बस एक नया इंजन मूल बातें सीखीं, जिसे अब उन्हें फिर से सीखना होगा। शुरुआत कठिन होती है, एक के बाद एक दो बार बहुत जल्दी इससे गुजरना पड़ता है, पूरी तरह से हार मानने के लिए पर्याप्त निराशा हो सकती है।

इसलिए 4.0 रिलीज से पहले "3.3" या "3.9" संस्करण होने का कोई मतलब नहीं होगा, जिसमें उन सभी संगतता को तोड़ने वाले एपीआई परिवर्तन हैं, हालांकि ट्यूटोरियल रचनाकारों को नए उपयोगकर्ताओं के अपेक्षित बड़े पैमाने पर आने से पहले कुछ ट्यूटोरियल बनाने के लिए पर्याप्त समय देता है?

सुनिश्चित नहीं है कि यह सही जगह है या नहीं, लेकिन चूंकि यह नाम बदलने के मुद्दों का संभावित आंशिक समाधान हो सकता है, इसलिए मैं इसे यहां पेश करूंगा।
क्यों न सभी आवश्यक नामकरण परिवर्तन करें और फिर अनुवाद में एक नई भाषा जोड़ें जिसे GodotOldNames/GodotPre4.0 कहा जाता है जिसमें सभी परिवर्तनों के लिए सभी पुराने नाम हैं।
इस प्रकार यदि किसी को पुराने ट्यूटोरियल में मौजूद पुराने नाम नहीं मिलते हैं, तो वे भाषा को बदलकर GodotPre4.0 कर सकते हैं। इससे नए नामों पर स्विच करना भी आसान हो जाएगा।
यह पूरी समस्या का समाधान नहीं करता है लेकिन #4397 के साथ काम कर सकता है।

@Anutrix यह बहुत जटिलता जोड़ देगा (गैर-अंग्रेज़ी भाषाओं के बारे में क्या?) इसके अलावा, संपादक में प्रदर्शित सभी तार पहले स्थान पर स्थानीयकरण योग्य नहीं हैं।

भौतिकी " परत ", रेंडर " परत "

मुझे याद है कि गोडोट सीखने के अपने पहले कुछ हफ्तों के दौरान मैं ठीक उसी भ्रम से गुजर रहा था, जिस तरह से यह गरीब व्यक्ति था।

भौतिकी "लेयर", रेंडर "लेयर" ऑब्जेक्ट ओरिएंटेड डिज़ाइन से आने वाले किसी व्यक्ति के लिए समझ में
परतें (बहुवचन, एक परत के विपरीत), ऐसा प्रतीत होता है कि उन सभी मामलों में एक दूसरे के ऊपर ढेर किया जा रहा है।

कई लोगों के लिए "लेयरिंग" विशेष रूप से 2डी ग्राफिक्स या एनीमेशन के साथ काम करने का अर्थ है एक अग्रभूमि, पृष्ठभूमि और परतों के बीच या शीर्ष पर काम करना। बहुत से लोग परतों को एक पृष्ठभूमि के शीर्ष पर सेलोलॉइड फिल्मों के रूप में सोचते हैं, जब वास्तव में कई अन्य गेम इंजन की तरह गोडोट इस कार्य को पूरा करने के लिए "सॉर्टिंग" के विभिन्न तरीकों का उपयोग करता है।

तथ्य यह है कि हम अमूर्त समानता को कहते हैं कि भौतिक वस्तुएं या रेंडर ऑब्जेक्ट "परतें" साझा कर सकते हैं, जबकि साथ ही इन अमूर्त समानताओं का दृश्य परतों की स्टैकिंग उपस्थिति से कोई लेना-देना नहीं है (यह "सॉर्टिंग") है, जो इसे बनाता है कुछ के लिए इतना भ्रमित।

जब मुझे भौतिकी "लेयर", रेंडर "लेयर" का वास्तविक उपयोग और अर्थ समझ में आया, तो मुझे तुरंत आश्चर्य हुआ कि ये फिजिक्स ग्रुप, रेंडर ग्रुप क्यों नहीं हैं, और ईमानदारी से कहूं तो मुझे अभी भी पता नहीं है। उनका निश्चित रूप से एक-दूसरे से कोई शीर्ष-स्थिर संबंध नहीं है, जिसका अर्थ है कि उनका आदेश या एक-दूसरे से संबंध पूरी तरह से अप्रासंगिक है। उन्हें परत का नामकरण, इम्हो ने लोगों को भ्रमित करने के अलावा कुछ भी नहीं, "समूह", "समूह द्वारा प्रभावित" मास्क के लिए, या शायद कुछ अन्य शब्द जो मैं अभी नहीं सोच सकता, अधिक सटीक होगा।

एनिमेशनप्लेयर विधि
.stop(false) को .pause(true) कहा जाना चाहिए
क्योंकि यह वही करता है।

प्रोजेक्ट> प्रोजेक्ट सेटिंग्स> डिस्प्ले> विंडो> स्ट्रेच> मोड:

स्ट्रेच मोड "2D" को स्ट्रेच मोड "डिस्प्ले" या "सामान्य उद्देश्य" कहा जाना चाहिए
क्योंकि इसे 2D कहना भ्रमित करने वाला है जब यह 3D उपयोग के मामलों के लिए भी काम करता है, लेकिन सभी 2D उपयोग मामलों के लिए वास्तव में अच्छा नहीं है (जैसे पिक्सेलर्ट प्रोजेक्ट, जबकि गोडोट 2D प्रोजेक्ट को लगभग आधा करना पिक्सेलर्ट प्रतीत होता है।)
"डिस्प्ले" वास्तव में जो करता है उसके लिए अधिक वर्णनात्मक होगा: डिस्प्ले रिज़ॉल्यूशन पर सभी ग्राफिक्स को 2 डी ग्राफिक्स, 3 डी ऑब्जेक्ट्स, 2 डी मेश, लाइन 2 डी और पॉलीगॉन प्रस्तुत करना।
उस पर और अधिक यहाँ ।

एनीमेशनप्लेयर, टाइमर और इसी तरह के नोड्स के लूप, रिपीट, ऑनशॉट को स्पष्ट किया जा सकता है।

लूपिंग, दोहराना, और एक शॉट नहीं होना, सभी एक ही चीजें हैं।

मुझे लगता है कि
is_a_parent_of()
का नाम बदलकर कर देना चाहिए
is_parent_of()

@KoBeWi #19801 पर चर्चा देखें।

मुझे लगता है कि
is_a_parent_of ()
का नाम बदलकर कर देना चाहिए
is_parent_of ()

मुझे ऐसा नहीं लगता, is_parent_of() सुझाव देता है कि यह केवल पहले माता-पिता को ध्यान में रखता है, जबकि फ़ंक्शन सभी माता-पिता के लिए दोबारा जांच करता है।

@groud उस स्थिति में, इसे is_ancestor_of() कहा जाना चाहिए। अगर दूसरी तरफ के लिए भी कोई संबंधित फ़ंक्शन है, तो इसे is_descendant_of() कहा जाना चाहिए।

@groud उस स्थिति में, इसे is_ancestor_of() कहा जाना चाहिए। यदि अन्य तरीकों के लिए भी संबंधित फ़ंक्शन है, तो इसे is_descendant_of() कहा जाना चाहिए।

हां, लेकिन इसके बारे में सोचने के लिए दोनों कार्यों की आवश्यकता नहीं है, क्योंकि अंतर केवल "कॉलिंग" ऑब्जेक्ट और फ़ंक्शन तर्क को स्विच करने का मामला होगा। हो सकता है कि हम फ़ंक्शन को is_descendant_of() जैसे किसी चीज़ से आसानी से बदल सकें और हम कर चुके हैं।

हम क्रमशः push_error() और push_warning() से print_error() और print_warning() का नाम बदलना चाह सकते हैं। यह उन्हें स्वत: पूर्णता के लिए और अधिक खोज योग्य बना देगा :slightly_smiling_face:

@Calinou print_error() printerr() साथ भ्रमित हो सकता है

कृपया, TreeItem.get_children() पद्धति का नाम बदलने पर विचार करें, क्योंकि नाम का तात्पर्य है कि बच्चों के संग्रह को वापसी मूल्य माना जाता है, जब व्यवहार में यह पहला बच्चा होता है जो लौटाया जाता है और फिर आपको शेष पर पुनरावृति करनी होती है उन्हें get_next() (जैसा कि #19796 में वर्णित है) का उपयोग कर रहा है।

#31404 से @Zylann का हवाला देते हुए:

[नाम बदलें rpc() / rset() से] 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
• सीपीयूपार्टिकल्स Flags एनम -> ParticleFlags
• ARVRPositionalTracker get_type -> get_tracker_type
• ARVRPositionalTracker get_name -> get_tracker_name
• PathFollow2D rotate -> कुछ और
• ArrayMesh ArrayType enum -> इसे हटा दें
• मेष BlendShapeMode एनम -> ArrayMesh को दें

https://github.com/godotengine/godot/issues/15763#issuecomment -568908661 में स्पष्टीकरण

RichTextLabel के meta_hover_started और meta_hover_ended संकेतों का नाम बदलकर अन्य समान नामकरण परंपराओं से मेल खाना चाहिए: meta_hover_entered और meta_hover_exited । यह न केवल इसे बाकी गोडोट एपीआई की अधिक बारीकी से नकल करता है, बल्कि वर्तमान नामकरण योजना, वर्णानुक्रमिक छँटाई के कारण, उनके क्रम को उलट देता है। जब आप दस्तावेज़ पढ़ रहे होते हैं तो यह थोड़ा विचलित करने वाला होता है, स्पष्ट रूप से, संचालन का कालानुक्रमिक प्रवाह पहले प्रवेश करना और फिर बाहर निकलना है। यह चारों ओर इसे बदलने के लिए पठनीयता और स्थिरता में सुधार करता है।

मैंने देखा कि कोई Texture.size संपत्ति नहीं है। मुझे इसके बजाय Texture.get_size() गेट्टर को कॉल करने की आवश्यकता थी।

मैंने डिस्कोर्ड में पूछा कि क्या यह इरादा था या नहीं। एक सुझाव यहां पोस्ट करना था कि क्या इसे किसी संपत्ति में परिवर्तित करने की आवश्यकता है, दूसरा सुझाव यह था कि इसके लिए कोई 'सेटर' नहीं है, get_size() का उपयोग वर्तमान में अपेक्षित व्यवहार है।

@jmbjr क्या हमारे पास गुणों के रूप में उजागर कोई भी केवल-पढ़ने योग्य गुण हैं (केवल

हाँ, मुझे लगता है कि यदि आप केवल-पढ़ने के लिए उजागर संपत्तियों का समर्थन करना शुरू करने जा रहे थे, तो आपको इसके लिए उपयोग ध्वज की आवश्यकता होगी और जीडीस्क्रिप्ट पार्सर/कंपाइलर कोड भी जोड़ना होगा जो इसका समर्थन करता है।

SoftBody में एक areaAngular_stiffness जो area_angular_stiffness (सभी संबंधित विधियों के लिए समान) होना चाहिए।

Input.joy_connection_changed (विधि) ऐसा लगता है कि इसे स्क्रिप्टिंग एपीआई के संपर्क में नहीं आना चाहिए, इसे प्रत्येक प्लेटफ़ॉर्म के जॉयस्टिक हैंडलिंग कोड द्वारा आंतरिक रूप से कहा जाता है।

@ akien-mga जब मैंने पहली बार उस विधि को देखा, गोडोट की खोज के बहुत पहले, मेरे पास समान विचार थे, तब मुझे याद आया कि कैसे कोजिमा ने मेटलगियर सॉलिड में कुछ पौराणिक गेमप्ले का निर्माण एक विधि के आसपास किया है जो कि इसके समान ही रहा होगा और मैंने सोचा: " गोडोट मुझे कोड की एक पंक्ति के साथ कोजिमा की तरह चौथी दीवार को चोंच मारने का साधन भी देता है, वह कितना बढ़िया है!"

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, क्षेत्र क्षेत्र, int area_shape, int self_shape)
area_shape_exited (int area_id, क्षेत्र क्षेत्र, int area_shape, int self_shape)
body_shape_entered (int body_id, नोड बॉडी, int body_shape, int area_shape)
body_shape_exited (int body_id, नोड बॉडी, int body_shape, int area_shape)

मुझे लगता है कि इन अंतिम दो में area_shape self_shape होना चाहिए? या ...

सख्त शरीर:

body_shape_entered (int body_id, नोड बॉडी, int body_shape, int local_shape)
body_shape_exited (int body_id, नोड बॉडी, int body_shape, int local_shape)

यहाँ इसे local_shape कहा जाता है ...

@FrederickDesimpel जहाँ तक मुझे पता है, संगतता को तोड़े बिना तर्कों का नाम बदला जा सकता है। इसके लिए एक पुल अनुरोध खोलने के लिए स्वतंत्र महसूस करें: थोड़ा_मुस्कुराते हुए_फेस:

संस्करण में:

वास्तविक -> फ्लोट
शून्य -> ​​शून्य?

मुझे व्यक्तिगत रूप से "असली" नाम पसंद है, क्योंकि "फ्लोट" शब्द अक्सर 32-बिट फ्लोट्स के लिए विशेष रूप से उपयोग किया जाता है, लेकिन वेरिएंट का असली डबल है, और अधिकांश इंजन real_t का उपयोग करता है जो या तो हो सकता है।

पीएस हमने पहले ही 2017 में दूसरे तरीके से नाम बदल दिया है।

क्या हमने इनका नाम बदलने पर विचार किया:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial को पहले से ही Master में StandardMaterial3D नाम दिया गया था।

चाहिए limit_ पर मान Camera2D एक के लिए बदला जा Rect2i ? अभी वे सिर्फ चार इंच के हैं।

संपादित करें: ड्रैग मार्जिन को 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

हालांकि "जस्ट" शब्द गायब है, 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 सी) एक गणितीय डिस्क (सतह) है।

एपीआई के संदर्भ में, यह draw_rect(bool filled) और draw_circle(bool filled) तुलना में draw_rect() , draw_filled_rect() , draw_circle() और draw_disk() के लिए IMO अधिक उपयोगकर्ता के अनुकूल है

संपादित करें: वास्तव में draw_circle() अभी तक filled तर्क नहीं है। मुझे लगता है कि हमें एक जोड़ना चाहिए, ताकि इसका उपयोग सर्कल (परिधि) और डिस्क (भरा हुआ सर्कल) दोनों को आकर्षित करने के लिए किया जा सके।

अच्छा धन्यवाद। मेरे अधिकांश छात्र फ्रेंच हैं और वे सभी इससे भ्रमित थे, और मैं भी ऐसा ही था, और उन्होंने गोडोट को दोषी ठहराया और मैं उन्हें निश्चित रूप से ऐसा नहीं करने दे सकता था।

भरे हुए आयत का गणितीय नाम क्या होगा?

यह एक बहुत अच्छा सवाल है; मैं केवल "आयताकार क्षेत्र" या "आयत आंतरिक" पा सकता हूं, और कोई भी पर्याप्त नहीं है। विकि में यह भी कहा गया है कि अधिकांश लोग _बहुभुज_ शब्द का दुरुपयोग करते हैं, जिसका अर्थ बहुभुज के _आंतरिक_ से है, इसके लिए कोई अन्य शब्द प्रदान किए बिना।

मुझे लगता है कि filled तर्क अस्पष्टता को कम करने में मदद कर सकता है, लेकिन यह तय करने में दर्द होगा कि इसे तर्कों की सूची में कहां रखा जाए।

@ गौटे लेकिन यह तय करने में दर्द होगा कि इसे तर्कों की सूची में कहां रखा जाए।

चूंकि यह एक वैकल्पिक तर्क है (इसका एक डिफ़ॉल्ट मान है), और साथ ही निरंतरता के लिए draw_rect , इसे अंत में जाना चाहिए।

ऐसे मामले हैं जिनमें नियंत्रण नोड्स को मोडल नोड्स के रूप में संदर्भित किया जाता है। https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal ज्यादातर Viewport.get_modal_stack_top() फ़ंक्शन के संबंध में

EditorInterface की get_selected_path और get_current_path विधियां नाम और कार्य में भ्रमित कर रही हैं। उनके पास दस्तावेज का भी अभाव है।

ये विधियां एक ही नाम की FileSystemDock की विधियों के शीर्ष पर केवल एक पतली परत हैं:

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

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

उन्हें या तो "चयनित" या "वर्तमान" (या कुछ और, लेकिन उन दोनों के लिए) को अनुकूलित करना चाहिए, जिसमें एक get_*_path और दूसरा get_*_dir ।

@Goutte क्या सॉलिड रेक्टेंगल भरे हुए आयत का विकल्प नहीं है?

क्या ओपी को 2019 के जून के बाद पोस्ट किए गए सुझावों से अपडेट किया जाएगा? मैं समझता हूं कि यह बहुत काम का है, लेकिन इस प्रकार का ट्रैकर योगदानकर्ताओं के लिए एक साथ निपटने के लिए भी सही है। और मुझे लगता है कि यह पहले से ही समय है जब हम और सामान का नाम बदलने पर काम कर सकते हैं?

ओपी को अपडेट करने का मतलब यह भी होगा कि पोस्ट किया गया सुझाव टीम द्वारा सार्थक के रूप में स्वीकार किया जाता है।

@Anutrix "भरा" "ठोस" की तुलना में उपयोग करने के लिए एक बेहतर शब्द है, क्योंकि "ठोस" का अर्थ "तरल या गैस नहीं" हो सकता है।

@pycbouh प्रत्येक मुद्दे के लिए

मुझे नहीं पता कि इसे उठाया गया था या नहीं , लेकिन मुझे यह नहीं पता था कि मैं कितनी बार इसके लिए डॉक्टर को देखने के लिए रुकता हूं:

• Array.remove => remove_at (जैसे C#) अनुक्रमणिका द्वारा हटाने के लिए
• Array.erase => remove_value , या केवल remove (जैसे C#) मूल्य के आधार पर निकालने के लिए

(या इसके वेरिएंट erase )

क्योंकि अभी, erase और remove मतलब मेरे लिए एक ही है, सिवाय एक इंडेक्स के, दूसरा वैल्यू के हिसाब से, मैं भूलता रहता हूं कि कौन सा है।

पहले से ही उठाया गया था, मेरा बुरा। ध्यान नहीं दिया, जीथब धागे को मोड़ रहा है, मेरी Ctrl + F खोज ने इसे याद किया xD
अभी तक ओपी में नहीं

@Zylann यहाँ आप जाएँ :

Zylann को सेकेंडिंग करते हुए, मैं यह भूलता रहता हूं कि इंडेक्स द्वारा हटा दिया गया है ...

ButtonList एनम की संभावना का नाम बदलकर MouseButtonList कर दिया जाना चाहिए क्योंकि वे माउस बटन हैं।

क्या JoystickList एनम को विभाजित किया जाना चाहिए? इसमें बटन और कुल्हाड़ी दोनों शामिल हैं, यह JoypadButtonList और JoypadAxisList या इसी तरह के रूप में अधिक समझ में आता है।

बस एक सवाल, क्यों नहीं MouseButton ?
अगर बटन == माउसबटन। बाएं:
से अच्छा पढ़ता है
अगर बटन == माउसबटन सूची। बाएं:

अच्छा विचार। उस स्थिति में, KeyList -> Key , MidiMessageList -> MidiMessage , और जॉयस्टिक वाले को List निकालना होगा .

मैंने देखा कि कुछ विधियां/गुण normal_map उपयोग करते हैं, जबकि अन्य normalmap । हमें इनमें से किसी एक पर समझौता करना चाहिए, लेकिन शायद दोनों पर नहीं। मैं normal_map पसंद करूंगा, लेकिन मैं normalmap भी ठीक हूं।

जीडीस्क्रिप्ट

रेंज_लेरप () = नक्शा ()
बीज = set_seed ()

map() शायद नई कार्यात्मक प्रोग्रामिंग सुविधाओं के लिए आरक्षित है।

Vector2.tangent() को डॉक्स में इस प्रकार वर्णित किया गया है: Returns a perpendicular vector. , यह orthogonal या orthonormal की परिभाषा है यदि लौटाए गए वेक्टर को सामान्यीकृत किया जाता है। चूंकि Vector2.tangent() एक गैर-सामान्यीकृत वेक्टर देता है, मेरा प्रस्ताव है कि हमें इसका नाम बदलकर Vector2.orthogonal() या यहां तक ​​​​कि Vector2.perpendicular() यदि लोगों के पास गणित नामकरण के खिलाफ कुछ है या शायद Vector2.normal() , लेकिन लोग normalized() और normal() बीच भ्रमित हो सकते हैं

मेरी ओर से उपाख्यान, लेकिन पहली बार इसकी तलाश में, दस्तावेज़ों में मेरी पहली खोजें _perpendicular_ के लिए थीं।

आप .tangent() को .perpendicular() लिए सिर्फ एक उपनाम के रूप में भी रख सकते हैं, नहीं?

मुझे orthogonal नाम पसंद नहीं है क्योंकि यह दूसरों की तुलना में एक सामान्य अंग्रेजी शब्द नहीं है। मुझे पहले tangent साथ कोई समस्या नहीं दिखाई दी, लेकिन मुझे लगता है कि perpendicular वैसे भी एक बेहतर नाम है।

हाँ, ओर्थोगोनल दुर्लभ है। मैं .perpendicular() के लिए वोट करता हूं, लेकिन साथ ही साथ संगत के लिए स्पर्शरेखा() उपनाम रखते हुए, यह छोटा है।

@ Zireael07 मैं पसंद करूंगा यदि हमारे पास स्पर्शरेखा प्राप्त करने का केवल एक ही तरीका हो। मुझे नहीं लगता कि यह एक बहुत ही सामान्य ऑपरेशन है।

आपको आश्चर्य होगा कि मैं इसे अपनी प्रोजेन स्क्रिप्ट में कितनी बार उपयोग करता हूं :)

मुझे उम्मीद नहीं थी कि यह एक बहस पैदा करेगा, लेकिन मैं व्यक्तिगत रूप से 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 से संबंधित

"टकराव की परतें ", "विजुअल इंस्टेंस लेयर्स ", "रेंडर लेयर ", ect का नाम बदलें
"टकराव समूह ", "विजुअल इंस्टेंस समूह ", " समूह प्रस्तुत करें", "प्रकाश समूह "

वे "लेयर्स" स्टैकिंग क्यों नहीं कर रहे हैं, इस बारे में भ्रम सामुदायिक चैनलों पर मिनट की घड़ी की तरह सामने आता है।

ध्यान दें कि उन्हें माया, लंबरयार्ड और एकता में परतें कहा जाता है।

सिर्फ इसलिए कि कोई और कुछ करता है इसका मतलब यह नहीं है कि यह अभी भी कारण नहीं है
भ्रम और एक अच्छा विचार है।

सोम, मई 18, 2020 पर, 1:09 PM पर Jummit [email protected] लिखा है:

ध्यान दें कि उन्हें माया, लंबरयार्ड और एकता में परतें कहा जाता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

मुझे आश्चर्य है कि अभी तक किसी ने इसका उल्लेख नहीं किया है
Camera2D.zoom
ज़ूम अधिक होने पर कैमरा ज़ूम आउट हो जाता है, ऐसा नहीं है कि "ज़ूम" कैसे काम करता है और यह काउंटर-सहज ज्ञान युक्त है। सुनिश्चित नहीं है कि इसका नाम क्या है, शायद view_scale या कुछ इसी तरह।

@KoBeWi नाम बदलने के बजाय zoom , क्या हमें इसके पैमाने को उल्टा नहीं करना चाहिए ताकि जब आप मूल्य बढ़ाते हैं तो यह ज़ूम इन हो जाता है?

यह संपत्ति का नाम बदलने की तरह ही अनुकूलता को तोड़ देगा। अगर हम "इनवर्ट स्केल" रूट पर जाते हैं, तो दुर्भाग्य से इसे स्वचालित रूप से ठीक नहीं किया जा सकता है। फिर भी, इसके परिणामस्वरूप लंबी अवधि में कम भ्रम हो सकता है।

@Calinou @KoBeWi क्या इस ज़ूम प्रॉपर्टी का सीधे उपयोग करने के लिए कोई उपयोग-मामला है, या क्या हर किसी को स्केल पर लागू करने के लिए इसे हर बार उलटा करना होगा?

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

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

हो सकता है, लेकिन हम इसके साथ रेखा कहाँ खींचते हैं और Node2D.get_position_2d() जैसी कोई चीज़?

हो सकता है कि हम Viewport2D वर्ग का नाम दे सकते हैं, लेकिन जब तक हम Viewport3D नहीं बनाते, तब तक इसकी आवश्यकता नहीं होगी।

@nathanfranke मैंने इस पद्धति का प्रस्ताव दिया क्योंकि अकेले नाम में यह बताने का कोई तरीका नहीं है कि यह 2D या 3D है, यह देखते हुए कि 2 प्रकार के Transform । (जबकि अन्य सदस्यों के पास canvas_ या mouse_ पहले से है)

@Zylann यह विधि वास्तव में वास्तव में अजीब है। canvas_transform और global_canvas_transform नामक गुण हैं, और canvas_transform का विवरण यह है:

व्यूपोर्ट का कैनवास रूपांतरण, सभी चाइल्ड कैनवास आइटम्स की ऑन-स्क्रीन स्थिति बदलने के लिए उपयोगी है। यह व्यूपोर्ट के वैश्विक कैनवास रूपांतरण के सापेक्ष है।

तो, आप उम्मीद करेंगे कि get_final_transform इन दोनों रूपांतरणों को संयुक्त रूप से प्राप्त करेगा। हालाँकि, यदि आप कोड को देखते हैं, तो वास्तव में यह ऐसा नहीं करता है।

इसके लिए कोड return stretch_transform * global_canvas_transform; । मैं यह पता लगाने की कोशिश कर रहा हूं कि stretch_transform क्या है और मुझे नहीं पता, यह उजागर नहीं हुआ है, और canvas_transform बदलते समय यह निश्चित रूप से सेट नहीं है। _stretch_transform नामक एक विधि भी है जो stretch_transform उपयोग नहीं करती है। इसे set_size द्वारा बुलाया जाता है, जो _stretch_transform द्वारा उत्पन्न मान लेता है और इसे stretch_transform असाइन करता है। canvas_transform_override जिसका मैंने उल्लेख भी नहीं किया है और उजागर नहीं किया है, लेकिन आंतरिक रूप से उपयोग किया जाता है।

अंत में मुझे लगता है कि इस पूरी कक्षा को देखा जाना चाहिए। व्यूपोर्ट में 4 अलग-अलग Transform2D सदस्य, 4 Rect2 (i) सदस्य, 9 वेक्टर2 (i) सदस्य और 2 ट्रांसफ़ॉर्म (3D) सदस्य हैं। यदि आप सभी पॉइंटर्स जोड़ते हैं और यह संभवतः 1 केबी के करीब है, तो यह पहले से ही 264 बाइट्स (एकल-सटीक फ़्लोट्स के साथ) केवल डेटा संरचनाओं में परिवर्तन की जानकारी संग्रहीत करता है। हो सकता है कि व्यूपोर्ट को इस सब की आवश्यकता हो, लेकिन यह जटिल लगता है, और कम से कम टिप्पणियां होनी चाहिए (इस फ़ाइल में बहुत कम हैं)।

क्या Node2D/Node3D to_global और to_local को हटा दिया जाना चाहिए? मैंने #38902 पर फीडबैक दिया जिसमें उन तरीकों को जोड़ने का प्रस्ताव था जो केवल आधार के साथ काम करते हैं, लेकिन इनके साथ कुछ मुद्दे हैं।

डेमो प्रोजेक्ट में, to_local का कहीं भी उपयोग नहीं किया जाता है, और $ grep -RIn "to_global" केवल 5 परिणाम देता है, जो सभी 3D डेमो में GUI में हैं, और डेमो के प्रदर्शन को बदलकर सुधार किया जा सकता है यह इतना है कि यह कैश वैश्विक बदलने और का उपयोग करता है xform उपयोग करने के बजाय to_global ।

संक्षेप में, इन विधियों के साथ चिंता यह है कि वे असामान्य रूप से उपयोग किए जाते हैं, और यह भी कि वे लेखन कोड को प्रोत्साहित करते हैं जो खराब प्रदर्शन करता है क्योंकि यह कई बार वैश्विक परिवर्तन की पुनर्गणना करता है।

27509

AnimationPlayer के animation_started और animation_finished थोड़े प्रति-सहज हैं। पहले को कतार में सभी एनिमेशन के लिए बुलाया जाता है जबकि बाद वाले को केवल कतार के बहुत अंत तक पहुंचने पर ही बुलाया जाता है। दस्तावेज़ीकरण में इसका स्पष्ट रूप से उल्लेख नहीं किया गया है।

यदि हम यह पता लगाना चाहते हैं कि कोई विशेष एनीमेशन कब समाप्त होता है, तो हमें animation_changed और animation_finished दोनों का उपयोग करना होगा जो सुविधाजनक नहीं है।

मैं वास्तव में उस मुद्दे से @txiग्रेमैन के सुझाव को पसंद करता हूं: जब भी कतार में कोई एक एनीमेशन समाप्त होता है तो हम 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 जो 2D, 3D, स्क्रिप्ट संपादकों और एसेट लाइब्रेरी को रखने वाला केंद्रीय होता है। रिकॉर्ड के लिए, लौटाया गया नोड एक VBoxContainer* , लेकिन इसे अलग कर दिया गया है (फिर भी यह जानना महत्वपूर्ण है, क्योंकि यह आपकी सेटिंग्स की पसंद को प्रभावित करता है)।
दस्तावेज़ भी गलत है, क्योंकि इसका विवरण Viewport वर्ग से लिंक है। https://docs.godotengine.org/hi/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() बहुत गलत दिखता है, पहले यह प्लेसहोल्डर नहीं लौटाता है जैसा कि नाम से पता चलता है, लेकिन एक बूल और दूसरा यह बिना किसी वास्तविक आवश्यकता के बेस क्लास में विरासत में प्राप्त कार्यान्वयन का विवरण लीक करता है (प्रकार के लिए परीक्षण नोड का अन्य तरीकों से संभव है)

RayShape → SeparationRayShape , जैसा कि शुरुआत में godotengine/godot-proposals#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 लोग नियमित रूप से चीजों का नाम बदलने के लिए पुल अनुरोध खोलते हैं। यह एक बार में सभी के बजाय वृद्धिशील रूप से किया जाता है।

बनावट (Texture2D) और छवि

• बनावट में get_data() (Texture2D) को get_image() नाम दिया जाना चाहिए और छवि में get_data() को स्व-वर्णन करने के लिए get_bytes() नाम दिया जाना चाहिए।

आईएमओ: get_image हाँ, get_bytes नहीं।

texture.get_image().get_data()

मेश / मेश इंस्टेंस

• मेष में आप उन विधियों के साथ सामग्री प्राप्त/सेट करते हैं:
  surface_get_material/surface_set_material
• MeshInstance में आप उन विधियों से प्राप्त/सेट करते हैं:
  get_surface_material/set_surface_material

यह वही नामकरण होना चाहिए जो मुझे लगता है?

@Coldragon यह get_surface_material / set_surface_material और surface_material संपत्ति होनी चाहिए।

@Coldragon यह get_surface_material / set_surface_material और surface_material संपत्ति होनी चाहिए।

यह "सामान्य" सेट/प्राप्त नहीं है, उनके पास लक्ष्य सतह के लिए एक अनुक्रमणिका है (यह मेष वर्ग के अंदर एक वेक्टर है)

Array हमें empty() से is_empty() का नाम बदलना चाहिए ताकि यह बूलियन को बेहतर ढंग से चित्रित कर सके

String हमें find_last() को rfind() पक्ष में छोड़ देना चाहिए। बिल्कुल एक नाम नहीं है, लेकिन यह अभी भी चर्चा के लायक है कि कौन सा नाम रखना है।

एकल संख्याओं के लिए, हमारे पास stepify । वेक्टर 2/वेक्टर 3 के लिए, हमारे पास snapped ।

वे वही काम करते हैं, वेक्टर प्रत्येक घटक के लिए stepify हैं। एक नाम चुना जाना चाहिए, लेकिन कौन सा?

पोल: :दिल: = दोनों stepify होने चाहिए, :रॉकेट: = दोनों snapped होने चाहिए, :-1: = नाम न बदलें।

AABB में intersection , जबकि Rect2 में clip । वे वही काम करते हैं। एक नाम चुना जाना चाहिए, लेकिन कौन सा?

पोल: :दिल: = दोनों intersection होने चाहिए, :रॉकेट: = दोनों clip होने चाहिए, :-1: = नाम न बदलें।

@aaronfranke हाँ, मैंने पहले https://github.com/godotengine/godot/issues/16863#issuecomment -449628319 में intersection नाम का सुझाव दिया था। हम तो है intersects जो नाम दिया जा सकता है overlaps में Rect2 , लेकिन नहीं जानते कि के बारे में AABB के बारे में intersects → overlaps नाम बदलें।

मुझे लगता है कि find_node और/या get_node का नाम बदल दिया जाना चाहिए क्योंकि नाम इंगित नहीं करते हैं कि वे 2 के बीच बिल्कुल अंतर करते हैं।
चूँकि 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 वैसे ही रहना चाहिए जैसा वह है। इसमें एपीआई दस्तावेज़ों के व्यवहार में स्पष्ट दस्तावेज अंतर होना चाहिए।

गोडोट 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 का तात्पर्य है कि गोडोट का उपयोग केवल खेलों के लिए किया जा सकता है। बहुत से लोग गैर-गेम अनुप्रयोगों के लिए सफलतापूर्वक गोडोट का उपयोग कर रहे हैं, इसलिए मैं एक अधिक समावेशी शब्द का उपयोग करना पसंद करूंगा :slightly_smiling_face:

साथ ही, यह वास्तव में आत्म-व्याख्यात्मक नहीं है: लोग सोच सकते हैं कि यह अभी भी संपादक से चल रही परियोजनाओं पर लागू होता है (आप संपादक से "गेम" चला रहे हैं)। वही app ।

"स्वतंत्र" के बारे में क्या?

शनिवार, 25 जुलाई, 2020, 5:49 बजे ह्यूगो लोकुरसियो, सूचनाएं @github.com
लिखा था:

@willnationsdev https://github.com/willnationsdev गेम का मतलब है गोडोट
केवल खेलों के लिए उपयोग किया जा सकता है, जो साबित नहीं हुआ है

इसके अलावा, यह वास्तव में आत्म-व्याख्यात्मक नहीं है: लोग इसे अभी भी सोच सकते हैं
संपादक से चल रहे प्रोजेक्ट्स पर लागू होता है। वही ऐप के लिए जाता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/16863#issuecomment-663835822 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AFMN5DM5U3KLXVUVIC2OGHTR5KTDXANCNFSM4ERRCEZA
.

@MuffinManKen independent मेरे लिए बहुत आत्म-व्याख्यात्मक नहीं लगता है।

संपादक बनाम स्टैंडअलोन शायद मानक नामकरण है (कम से कम एक मैं कई अलग-अलग इंजनों में देखता हूं) इसलिए पहिया इम्हो को फिर से शुरू करने का कोई कारण नहीं है।

Get_node वंशज प्राप्त करने तक सीमित नहीं है, इसलिए यह बहुत ही होगा
भ्रामक नाम। 2 विधियों को बहुत अलग नामों की आवश्यकता है क्योंकि वे क्या हैं
करना बहुत अलग है।

शनिवार, 25 जुलाई, 2020, दोपहर 3:14 बजे गोल्डडॉट्सप्रश्न, <
सूचनाएं@github.com> ने लिखा:

मुझे याद है कि शुरुआत में मैं लंबे समय से उलझन में था
find_node और get_node. मुझे वास्तव में find_descendant पसंद है और
get_descendant, क्योंकि ये सत्य और ज्ञानवर्धक होंगे @willnationsdev
https://github.com/willnationsdev @Coldragon
https://github.com/Coldragon
हो सकता है कि "वर्डीनेस" हर किसी के लिए चाय की तरह न हो, लेकिन इम्हो वास्तव में नहीं है
समस्या के रूप में स्वत: पूर्ण और आशुलिपि "$" है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/16863#issuecomment-663890652 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA
.

मुझे लगता है कि Transform और Transform2D तरीकों में inverse और xform_inv का नाम बदल दिया जाना चाहिए / हटा दिया जाना चाहिए क्योंकि ये विधियां वास्तव में वह नहीं करती हैं जो लोग उनसे करने की उम्मीद करते हैं . अधिक जानकारी: https://github.com/godotengine/godot/issues/39433#issuecomment -664024521।

RayCast.cast_to का नाम बदलकर RayCast.segment या कुछ और कर दिया जाना चाहिए। मैंने बस किसी ने कहा था कि उसे यह महसूस करने में 40 मिनट लगे कि यह एक संपत्ति है और एक समारोह नहीं है। शायद इसलिए कि यह एक क्रिया भी है।

RayCast.target बारे में क्या?

@ razcore-art मैंने हाल ही में रे कास्टिंग से संबंधित एक प्रश्न का उत्तर दिया है , और मैंने इसका वर्णन करने के लिए segment शब्द का उपयोग किया है, इसलिए मुझे लगता है कि यह समझ में आता है। लेकिन इसे direction और length रूप में भी लिखा जा सकता है, इसलिए यह वास्तव में एक खंड के बजाय किरण के करीब कुछ बन जाएगा, ज्यामितीय रूप से बोल रहा है (या केवल वैकल्पिक गुण प्रदान करें जो सह-अस्तित्व में हो सकते हैं) . समस्या यह है कि निरीक्षक में सामान्यीकृत दिशा वेक्टर आसानी से सेट करने का कोई तरीका नहीं है। मैंने कम से कम 2D के लिए एक बनाने का प्रस्ताव लिखा: godotengine/godot-proposals#397, लेकिन शायद यह बहुत दूर की कौड़ी है।

संपादित करें: आगे सोचने पर, segment RayCast नोड के संदर्भ में ज्यादा समझ में नहीं आता है, लेकिन Physics2DDirectSpaceState.intersect_ray() संदर्भ में समझ में आता है।

RayCast.target बारे में क्या?

@nathanfranke मैं लक्ष्य को Node या NodePath मानूंगा । तो कम से कम यह RayCast.target_position । शायद RayCast.cast_position या RayCast.cast_offset । यह मत भूलो कि रे कास्ट घूम सकता है, जो वास्तविक कास्ट स्थिति को वैश्विक निर्देशांक में स्थानांतरित कर सकता है।

PhysX API रेकास्ट को कॉन्फ़िगर करने के लिए यूनिट दिशा + लंबाई के मेरे विचार की पुष्टि करता है। मैं

उस ने कहा, मैं cast_position की ओर झुक रहा हूं ... क्योंकि रे कास्टिंग कैसे काम करता है, इसे फिर से लिखने के लिए और अधिक मुख्य परिवर्तनों की आवश्यकता होती है।

@Xrayez मैं संपत्ति की शुरुआत में "कास्ट" शब्द का उपयोग करने से cast_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() बदलने पर विचार करना चाहिए।

जावा, सी #, पायथन, जावास्क्रिप्ट इत्यादि में ऐसा ही है।

बगस्क्वाड संपादित करें: https://github.com/godotengine/godot/issues/16863#issuecomment -596069130

bool , float , int केवल ऐसे प्रकार/वर्ग हैं जिनके नाम लोअरकेस अक्षर से शुरू होते हैं। मुझे लगता है कि उनका नाम बदलकर (जीडीस्क्रिप्ट में) कर दिया जाना चाहिए Bool , Float , Int । यह गलत प्रकार के सिंटैक्स हाइलाइटिंग के साथ समस्या को स्वचालित रूप से ठीक कर देगा।

और bool , float , int का उपयोग केवल @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 विभिन्न भाषाओं में यह अलग है। उदाहरण के लिए, कोटलिन, हक्स, एडा में सभी प्रकार के नाम बड़े अक्षरों में लिखे गए हैं।

इसके अलावा, प्रधानता एक सशर्त अवधारणा है। मेरे लिए String , Color , Vector2 , आदि आदिम प्रकार हैं, खासकर जब से वे मूल्य से पारित होते हैं न कि संदर्भ द्वारा।

एकमात्र बाधा पिछड़ी संगतता का उल्लंघन है।

चूंकि String परिवर्तनशील नहीं है

हैरानी की बात है कि GDScript में स्ट्रिंग्स परिवर्तनशील हैं:

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

Vector2 एक आदिम नहीं है क्योंकि यह 2 float द्वारा रचित है। हालांकि, Vector2 और float अंतर्निर्मित प्रकार हैं।

@Zylann क्या यह इतना मौलिक अंतर है कि इसे टाइप नाम में प्रतिबिंबित किया जाना चाहिए?

(मेरे लिए, 'आदिम' 'सरल' है, 'एक टुकड़ा' नहीं।)

मैं अपने पक्ष में इसकी व्याख्या नहीं करना चाहता, लेकिन:

आदिम प्रकारों के नाम पूंजीकृत हैं। :मुस्कुराओ:

यहाँ वे शर्तें हैं जो मैं उन्हें समझता हूँ:

| नाम टाइप करें | आदिम प्रकार | मान प्रकार | परिवर्तनशील प्रकार | अंतर्निर्मित प्रकार |
| ------------- | ------------- | ------------- | ------------- | ------------- |
| इंट | हाँ | हाँ | एन/ए | हाँ |
| वेक्टर2 | नहीं | हाँ | एन/ए | हाँ |
| नोड | नहीं | नहीं | हाँ | हाँ |
| स्ट्रिंग | नहीं | नहीं | नहीं | हाँ |

बावजूद इसके ये नाम नहीं बदले जा रहे हैं। वे वैसे ही ठीक हैं, और विभिन्न भाषाओं के प्रोग्रामर से परिचित हैं। इस ट्रैकर को व्यर्थ की चर्चाओं से भरने से बचने के लिए हमें चर्चा यहीं समाप्त करनी चाहिए।

म्यूटेबल टाइप कॉलम गलत है: केवल ऑब्जेक्ट-व्युत्पन्न, डिक्शनरी और ऐरे म्यूटेबल हैं। ( Vector2 परिवर्तनशील लग सकता है क्योंकि आप vec2.x = 0 कर सकते हैं, लेकिन यह वास्तव में vec2 = vec2.with_x(0) जैसी किसी चीज़ का अनुवाद करता है)

ShortCut का नाम बदलकर Shortcut

निम्नलिखित विधियों को बदला जाना चाहिए
के बीच विसंगतियां

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

प्रति

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

संगति के लिए
तथा

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

ठीक करने की जरूरत है।

पुनश्च मैं सिद्धांत से आगे बढ़ा "कम समान तरीके, बेहतर"।

@dalexeev बूलियन पैरामीटर अक्सर अलग-अलग तरीकों की तुलना में कम पठनीय होते हैं, क्योंकि true और false का कोई संदर्भ नहीं है।

हाँ, लेकिन निरंतरता भी अच्छी होगी। फिर इनपुटएवेंट में बूलियन पैरामीटर से छुटकारा पाएं?

@Calinou ज्यादातर मामलों में, आपको गूंज घटनाओं की जांच करने की आवश्यकता नहीं है।

मैं इसे एक बड़ी समस्या के रूप में नहीं देखता। जब आप कोड टाइप करते हैं, तो तर्क संकेत प्रकट होता है। कोड पढ़ते समय, आप Shift + Click का उपयोग कर सकते हैं। अक्सर उपयोग किए जाने वाले फ़ंक्शंस के तर्क याद रखने के लिए त्वरित होते हैं (उदाहरण के लिए, String.split )।

इसके अलावा, doc/classes निर्देशिका में 208 वैकल्पिक बूलियन तर्क पाए गए (यह केवल कोर है, और 16 मॉड्यूल में नेस्टेड निर्देशिका doc_classes )।

AcceptDialog.xml

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

AnimatedSprite2D.xml

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

AnimationNode.xml

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

AnimationPlayer.xml

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

Animation.xml

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

Array.xml

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

AStar2D.xml

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

AStar.xml

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

Camera3D.xml

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

CanvasItem.xml

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

ClassDB.xml

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

CodeHighlighter.xml

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

Color.xml

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

Control.xml

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

CryptoKey.xml

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

Curve2D.xml

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

Curve3D.xml

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

Dictionary.xml

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

Directory.xml

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

DisplayServer.xml

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

EditorInterface.xml

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

EditorNode3DGizmoPlugin.xml

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

EditorNode3DGizmo.xml

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

EditorProperty.xml

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

Expression.xml

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

File.xml

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

Font.xml

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

GIProbe.xml

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

HTTPClient.xml

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

HTTPRequest.xml

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

ImageTexture.xml

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

Image.xml

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

ImmediateGeometry3D.xml

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

InputEvent.xml

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

Input.xml

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

InstancePlaceholder.xml

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

ItemList.xml

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

JavaScript.xml

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

JSONRPC.xml

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

JSON.xml

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

KinematicBody2D.xml

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

KinematicBody3D.xml

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

Marshalls.xml

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

Navigation2D.xml

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

Navigation3D.xml

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

NavigationServer3D.xml

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

Node2D.xml

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

Node.xml

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

Object.xml

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

OS.xml

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

PacketPeerDTLS.xml

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

PacketPeer.xml

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

PCKPacker.xml

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

PhysicsDirectSpaceState2D.xml

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

PhysicsDirectSpaceState3D.xml

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

PhysicsServer2D.xml

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

PhysicsServer3D.xml

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

PopupMenu.xml

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

ProjectSettings.xml

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

Rect2.xml

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

RenderingDevice.xml

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

RenderingServer.xml

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

ResourceLoader.xml

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

Resource.xml

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

RigidBody2D.xml

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

SceneState.xml

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

SceneTree.xml

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

ScriptCreateDialog.xml

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

Script.xml

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

Skeleton3D.xml

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

SkeletonIK3D.xml

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

StreamPeerSSL.xml

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

StreamPeer.xml

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

String.xml

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

SurfaceTool.xml

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

TextEdit.xml

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

Texture2D.xml

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

TileMap.xml

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

TileSet.xml

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

TreeItem.xml

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

UndoRedo.xml

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

Viewport.xml

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

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

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

@dalexeev क्या आप हमारे लिए स्क्रॉलिंग को आसान बनाने के लिए इसे स्पॉइलर में डालने पर विचार कर सकते हैं?

@dalexeev ऐसे कई मामले हैं जहां आपको यह जांचने की आवश्यकता है कि क्या कोई कुंजी दबाई गई है और न केवल अगर इसे दबाया गया था। उदाहरण के लिए, एक चरित्र को स्थानांतरित करने के लिए एक स्क्रिप्ट को WASD या तीर कुंजियों के साथ ऐसा करने की आवश्यकता होती है। इनपुट को संसाधित करने के लिए हर गेम की बहुत आवश्यकता होती है, इसलिए मुझे नहीं लगता कि इन चीजों के लिए सिर्फ दो तरीके अपनाना बेकार है।

कोड पढ़ते समय, आप Shift + Click का उपयोग कर सकते हैं।

यदि आप GitHub पर अंतर नहीं देख रहे हैं। यदि कोड को पढ़ने योग्य IDE की आवश्यकता है, तो यह अच्छा कोड नहीं है।

@aaronfranke अन्य 207 मामलों के लिए, क्या आप अलग-अलग फ़ंक्शन बनाने का भी सुझाव देते हैं? यदि नहीं, तो यह तर्क निर्णायक नहीं है। इसके अलावा, मैंने ऊपर लिखा है कि यदि आप पैरामीटर नाम निर्दिष्ट कर सकते हैं, तो यह आईडीई के बिना पठनीय हो जाता है।

ऐसे कई मामले हैं जहां आपको यह जांचने की आवश्यकता होती है कि क्या कोई कुंजी दबाई गई है और न केवल अगर इसे अभी दबाया गया है।

अक्सर, लेकिन बिना प्रतिध्वनि के अधिक बार नहीं।

तीन विधियों ( 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() और इको 2 अलग चीजें हैं। आप स्वयं जांच सकते हैं कि इको इवेंट्स पहली प्रेस के बाद थोड़ी देरी के बाद प्राप्त होते हैं, जबकि is_action_pressed() में कोई देरी नहीं होती है।

@KoBeWi आप सही हो सकते हैं और

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

में बदला जाना चाहिए

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

चूंकि यह संगत नहीं है

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

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

@dalexeev जो आप प्रस्तावित करते हैं वह सही नहीं है। जब हम इको घटनाओं के बारे में बात करते हैं, तो हम एक कुंजी दबाते समय बार-बार कीबोर्ड ईवेंट के बारे में बात करते हैं, यहां शब्द का उपयोग करना थोड़ा समझ में आता है, क्योंकि एक्शन सिस्टम सीधे ईवेंट पर निर्भर नहीं करता है, यह स्थिति प्रति-फ्रेम फैशन में अपडेट की जा रही है। साथ ही, क्रियाएं अन्य उपकरणों जैसे नियंत्रकों या माउस बटनों के साथ भी काम कर सकती हैं, जहां "गूंज" घटना मौजूद नहीं है।

ट्रीइटम का get_children() केवल पहला बच्चा लौटाता है और सभी बच्चे जैसे नाम (या डॉक्स में विवरण) का सुझाव नहीं देते हैं।

[संपादित करें]
एनवीएम डॉक्स। विधि विवरण मास्टर में अद्यतन किया गया है, क्षमा करें।

मेरा सुझाव है कि संसाधन का 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 GDScript में load को हटाने के लायक भी हो सकता है: https://github.com/godotengine/godot-proposals/issues/263

ProjectSettings में चर registering_order और संबंधित विधि set_registering_order अप्रयुक्त है।

RandomNumberGenerator का नाम बदलकर Random दिया जाना चाहिए और वैश्विक यादृच्छिक कार्यों जैसे randf और rand_range को हटा दिया जाना चाहिए या हटा दिया जाना चाहिए।

मैं संभावित मुद्दों को देखता हूं जहां कोई एक अविश्वसनीय फ़ंक्शन को कॉल करता है जबकि यादृच्छिक बीज निर्दिष्ट होता है

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

वैश्विक यादृच्छिक कार्य जैसे randf और rand_range को हटा दिया जाना चाहिए या हटा दिया जाना चाहिए।

Godotengine/godot-proposals#1590 के भाग के रूप में चर्चा की गई।

मैं इन बुनियादी यादृच्छिक तरीकों को एक्सेसिबिलिटी और प्रोटोटाइप उद्देश्यों के लिए वैश्विक दायरे में रखना पसंद करूंगा, उनमें से कम से कम कुछ। लेकिन seed() और rand_seed() को निश्चित रूप से हटाया जा सकता है।

ऐसा लगता है कि 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 मुझे वर्तमान व्यवहार असामान्य लगता है। यह दृश्य सेटअप उत्पन्न करता है "चाइल्ड 2 पर क्लिक करें, दृश्य पर क्लिक करें"

(ध्यान दें, सभी पास करने के लिए तैयार हैं)

: मुस्कान: प्रस्ताव ए : शायद वर्तमान व्यवहार के लिए Control.MOUSE_FILTER_PASSPARENTS जैसा कुछ, क्योंकि इनपुट ईवेंट केवल माता-पिता को भेजे जाते हैं।

:रॉकेट: प्रस्ताव बी : स्थिरांक को इनमें बदलें:

• रोकें: वर्तमान व्यवहार - घटना लें और सभी प्रचार को रोकें
• PASS_PARENT: वर्तमान में PASS के समान व्यवहार
• PASS_ALL: IGNORE, लेकिन इवेंट लेता है
• इग्नोर: वर्तमान व्यवहार - घटना न लें, लेकिन फिर भी प्रचार करें

: आंखें: प्रस्ताव सी : नोड gui इनपुट लेता है या नहीं, यह वास्तव में प्रासंगिक नहीं है, क्योंकि कोई किसी भी सिग्नल को कनेक्ट नहीं कर सकता है (या बूलियन ध्वज का उपयोग कर सकता है)। हम विकल्प को Control.propagation_mode बदल सकते हैं और ये स्थिरांक हैं:

• कोई नहीं
• माता-पिता
• सब

मेरी राय में यह बहुत साफ दिखाई देगा।

यह नाम बदलने से परे है और इस पर एक प्रस्ताव के रूप में चर्चा की जानी चाहिए।

ये सभी नाम इतने लंबे क्यों हैं? आप कुछ सरल और संक्षिप्त को वास्तव में लंबे समय में बदल रहे हैं।

आप टाइप करने के लिए clip से intersection दोगुने लंबे समय तक बदल रहे हैं।
आप Control.MOUSE_FILTER_PASS को Control.MOUSE_FILTER_PASSTHROUGH भी बदल रहे हैं
आदि

मैं सरल और छोटे कम वर्बोज़ परिवर्तन पसंद करूंगा। यह एक फ़ंक्शन नाम है जो फ़ंक्शन का विवरण भी नहीं है।

मैं सरल और छोटे कम वर्बोज़ परिवर्तन पसंद करूंगा। यह एक फ़ंक्शन नाम है जो फ़ंक्शन का विवरण भी नहीं है।

हालांकि नाम वर्णनात्मक होना चाहिए। यदि आप स्वतः पूर्णता (जो गोडोट संपादक में अंतर्निहित है) का लाभ उठाते हैं तो लंबाई भी कोई मायने नहीं रखती।

मैंने IRC पर एक बार इसका उल्लेख किया था और मुझे कोई उत्तर नहीं मिला, लेकिन TextureRect में "स्केल ऑन एक्सपैंड (कॉम्पेट)" नामक एक खिंचाव मोड है। यह कुछ ऐसा लगता है जिसे हटाया जा सकता है।

यदि हम अपने गोडोट प्रोजेक्ट्स में मजबूत कोडबेस रखना चाहते हैं, तो निश्चित रूप से "कम वर्बोज़" मेनू में नहीं है। आधुनिक कोडिंग टूल स्वतः पूर्णता और अन्य बुद्धिमान सुविधाएँ प्रदान करते हैं जो आपको नाम लंबा होने पर भी जल्दी टाइप करने की अनुमति देते हैं। साथ ही, यदि आप उन परिवर्तनों के तर्कों को पढ़ते हैं, तो उन कार्यों को उनका उपयोग करने वाले डेवलपर्स के लिए कम अस्पष्ट बनाने का एक लक्ष्य है। संक्षिप्त नाम मीठा हो सकता है, लेकिन भ्रमित करने वाला और कम खोजने योग्य हो सकता है।

और हमेशा याद रखें: टाइपिंग कोड सॉफ्टवेयर विकास का त्वरित हिस्सा है। बाद में कोड को पढ़ना और समझना ज्यादा महत्वपूर्ण है। यह क्रमशः एक बच्चे को गर्भ धारण करने और पालने जैसा है।

मैं आप दोनों से असहमत हूं। मैं एक गोडोट उपयोगकर्ता हूं और मैं विशेष रूप से गोडोट का उपयोग करता हूं क्योंकि जीडीस्क्रिप्ट संक्षिप्त और लिखने में तेज है। यदि आप उन्हें दो बार लंबा बनाने जा रहे हैं तो गति लाभ खो गया है क्योंकि मुझे दो बार लिखने के लिए मजबूर किया जाएगा और क्षैतिज रूप से कोड की पूरी पंक्ति को देखने के लिए दो बार स्क्रॉल करना होगा।

जब आप कोडिंग कर रहे होते हैं तो आप अविश्वसनीय रूप से लंबे फ़ंक्शन या चर नाम टाइप नहीं करना चाहते हैं। इन प्रस्तावित परिवर्तनों में से कुछ परिवर्तन अन्य सभी चीज़ों की कीमत पर "स्पष्टता" के लिए बहुत लंबे फ़ंक्शन और चर नाम जोड़ते हैं। यदि आपको कोई संदेह है तो आप बिल्ट इन हेल्प को पढ़ सकते हैं। प्लस प्रोग्रामिंग एक एपीआई सीखने के बारे में है। नाम की परवाह किए बिना पहली बार उपयोग करने पर आप हमेशा किसी फ़ंक्शन को देखेंगे। सी में प्रिंटफ लेना संक्षिप्त और सरल है। गोडोट में आप इसे send_formatted_string_to_standard_out. नाम देंगे न केवल आप सभी को एपीआई को फिर से सीखने के लिए मजबूर कर रहे हैं बल्कि इनमें से कुछ परिवर्तनों में एकीकृत दृष्टि भी नहीं है। मुझे ऐसा लगता है जैसे लोगों का एक पूरा झुंड इकट्ठा हो गया और प्रत्येक ने इंजन के एक हिस्से को बदल दिया।

उदाहरण के लिए ऐरे लें
remove -> remove_at _at यहाँ क्या जोड़ता है? आपके पास पहले से ही remove_value है। आप और क्या हटा सकते हैं?
erase -> remove_value अभी भी पर्याप्त स्पष्ट नहीं है। दस्तावेज़ों से "सरणी से किसी मान की पहली घटना को हटाता है।" साथ ही लोग सोच सकते हैं कि आप संपूर्ण सरणी से एक एकल मान निकाल सकते हैं। स्पष्टता के लिए यह वास्तव में remove_first_occurance_of_value होना चाहिए क्योंकि फ़ंक्शन वास्तव में यही करता है। तो आपने फ़ंक्शन को लंबा और उतना ही भ्रमित करने वाला बना दिया।

आपके पास remove और erase दो अलग-अलग कार्य हैं लेकिन आप उन दोनों को अतिरिक्त अक्षरों के साथ remove पर एक ही भिन्नता में बदल देते हैं। लेकिन वे अलग तरह से काम करते हैं। निकालें एक विशिष्ट अनुक्रमणिका से हटा देता है जहां मिटाए गए मान के पहले उदाहरण को हटा देता है।

ये ठीक हैं बस लोगों को अपना कोड अपडेट करने के लिए मजबूर करने के अलावा वास्तव में उपयोगी नहीं हैं।
उलटा -> उल्टा
डुप्लिकेट -> क्लोन
खाली -> is_empty

अगर टूटा नहीं है तो इसे ठीक न करें।

@CarlGustavAlbertDwarfsteinYung लेकिन आप दोगुना टाइप नहीं करने जा रहे हैं। आपके द्वारा टाइप किए जाने वाले पहले 3 अक्षरों के बाद स्वतः पूर्णता शुरू होने वाली है और आप पूरे शब्दों को टाइप करने के बजाय अपनी जरूरत का चयन करते हैं।

उदाहरण के लिए अन्य नामों के लिए जब आप empty -> is_empty पर एक नज़र डालते हैं तो यह क्या करता है इसका स्पष्टीकरण प्रदान करने के लिए परिवर्तन की आवश्यकता होती है। जब आप empty को देखते हैं तो क्या आप बता सकते हैं कि क्या यह एक तरीका है जो कुछ खाली कर देता है, क्या यह एक किताब की जाँच है कि क्या कुछ खाली है, क्या यह कुछ और है? is_empty आप एक नज़र में देख सकते हैं कि यह एक बूल है जो सच है अगर कुछ खाली है और झूठा नहीं है। आपको केवल उनके नाम को पढ़कर पता होना चाहिए कि कौन से फंक्शन या वेरिएबल करते हैं। आप empty जैसे नाम से ऐसा नहीं कर सकते

@ फेनिक-गेमिंग मैं आपको खाली बता सकता हूं या is_empty समान रूप से भ्रमित कर रहे हैं बस एक दूसरे की तुलना में लंबा है।

@CarlGustavAlbertDwarfsteinYung empty एक क्रिया हो सकती है यदि इसे क्रिया के रूप में पढ़ा जाए। is_empty निश्चित रूप से एक गुणवत्ता है। बेशक यह भ्रम आपके अंग्रेजी के स्तर पर निर्भर हो सकता है।

इसके अलावा, भले ही आधुनिक कोड संपादक में किसी फ़ंक्शन को send_formatted_string_to_standard_out कहा जाता हो, इसे sfstso रूप में टाइप किया जा सकता है, या यदि आप चाहें तो मध्यवर्ती अक्षरों के किसी अन्य संयोजन के रूप में टाइप किया जा सकता है और स्वत: पूर्ण आपको देगा एकमात्र विकल्प।

@pycbouh लोग कितने वर्षों से इस इंजन का उपयोग कर रहे हैं? और मैंने एक व्यक्ति को मेरे पास यह कहते हुए नहीं सुना है कि आप जानते हैं कि इस इंजन में सबसे बड़ी समस्या क्या है। तथ्य यह है कि सरणी में empty बजाय is_empty ।

आप लोग यहां बैठे हैं उन चीजों को ठीक कर रहे हैं जो किसी ने नहीं चाहा या नहीं मांगा। हां शब्दांकन भ्रमित करने वाला है लेकिन वास्तव में कोई समस्या नहीं है और 2015 में इस इंजन का उपयोग शुरू करने के बाद से कभी कोई समस्या नहीं हुई है। कुछ प्रस्तावित परिवर्तनों का काफी स्वागत है और निष्पक्ष होने के लिए मैं is_ का उपयोग करता हूं। खाली है तो ठीक रहेगा। लेकिन कुछ बदलाव बहुत लंबे और समान रूप से भ्रमित करने वाले होते हैं। मैं विशेष रूप से उन सभी परिवर्तनों के बारे में बात कर रहा था।

इस मेगाथ्रेड का पूरा अस्तित्व ही इस बात का प्रमाण है कि लोग इसकी मांग कर रहे हैं। ये समस्याएं आपके या किसी और के लिए महत्वहीन हो सकती हैं, लेकिन खराब नामकरण के कारण लोगों को एपीआई को समझने में समस्या होती है। और इस प्रकार की समस्याएँ इस समस्या को एकत्रित करती हैं। जहां तक ​​समग्र रूप से इन परिवर्तनों के महत्व की बात है, विश्वास करें या न करें, लेकिन इन्हें ट्रैक करना और लागू करना अन्य विकास समय से दूर नहीं है।

और आपके द्वारा दिए गए उदाहरण को देखें और समझाने की कोशिश करें:

निकालें एक विशिष्ट अनुक्रमणिका से हटा देता है जहां मिटाए गए मान के पहले उदाहरण को हटा देता है।

आप इसे लिखते हैं और सभी वर्तमान और भविष्य के गोडोट उपयोगकर्ताओं के लिए नामकरण में सुधार करने का कोई कारण नहीं देखते हैं?

@pycbouh और वास्तव में मैंने सरणी का उदाहरण भी दिया remove_at तथा remove_value । remove_value मिटाने के विवरण के समान नहीं है और अभी भी उतना ही भ्रमित है। मूल्य कहाँ से निकालें? अंत से मान हटाएं, शुरुआत से ही हटाएं? सरणी से किसी मान की सभी आवृत्तियां निकालें?

अगर आपको वास्तव में चीजों को बदलने की जरूरत है तो remove और remove_first_occurence जो इसे संक्षिप्त और वर्णनात्मक दोनों बनाता है।

@pycbouh मैं इसके लिए नहीं पूछ रहा हूँ। इस धागे का अस्तित्व इसलिए है क्योंकि कुछ लोग इंजीनियरिंग से अधिक हैं और उन चीजों को ठीक कर रहे हैं जो शास्त्रीय प्रोग्रामर फैशन नहीं हैं। भविष्य के उपयोगकर्ताओं के बारे में क्या? उनके बारे में क्या? मैं एक बार भविष्य का उपयोगकर्ता था और मैंने एपीआई सीखा। मुझे फ़ंक्शन नामकरण के साथ कोई समस्या नहीं थी। 50% टिप्पणियाँ ऐसे लोग हैं जो प्रस्तावित परिवर्तनों से असहमत हैं। ऐसा लगता है कि इनमें से अधिकांश परिवर्तन कम संख्या में समुदाय के सदस्यों द्वारा इन परिवर्तनों को सभी पर धकेलने से प्रेरित हैं। क्या हम प्रस्तावित परिवर्तनों पर मतदान कर सकते हैं?

वास्तव में यहाँ एक प्रस्ताव है। एपीआई नामकरण में किसी भी बदलाव में योगदानकर्ता/दानकर्ता/उपयोगकर्ता की राय शामिल होनी चाहिए। अगर वे सब सहमत हैं तो मैं भी बोर्ड पर हूं। चुनाव कराएं और देखें कि हर कोई क्या करता है। दूसरे लोग क्या चाहते हैं, इसका अनुमान लगाने की कोशिश न करें। जो आपके लिए अच्छा है वह शायद किसी और के लिए अच्छा न हो।

मैंने जो देखा है, मैं यहां प्रस्तावित परिवर्तनों के लगभग 50% के खिलाफ हूं।

50% टिप्पणियाँ ऐसे लोग हैं जो प्रस्तावित परिवर्तनों से असहमत हैं।

क्या हम तैयार किए गए आँकड़ों को दरवाजे पर छोड़ सकते हैं, कृपया?

क्या हम प्रस्तावित परिवर्तनों पर मतदान कर सकते हैं?

चर्चा और प्रतिक्रियाएं इसी के लिए हैं।

मैंने जो देखा है, मैं यहां प्रस्तावित परिवर्तनों के लगभग 50% के खिलाफ हूं।

यदि आप केवल उनके खिलाफ हैं क्योंकि "मैंने इसे इस तरह से सीखा है, इसलिए मैं चाहता हूं कि मेरे बाद सभी को भी ऐसा ही भुगतना पड़े", तो यह प्रस्ताव की अमान्य आलोचना है और इसे अनदेखा किया जा रहा है।

जो आपके लिए अच्छा है वह शायद किसी और के लिए अच्छा न हो।

ठीक वैसा ही।

क्या हम तैयार किए गए आँकड़ों को दरवाजे पर छोड़ सकते हैं, कृपया?

पूरे समुदाय के बारे में यह दावा पसंद है?

ये समस्याएं आपके या किसी और के लिए महत्वहीन हो सकती हैं, लेकिन खराब नामकरण के कारण लोगों को एपीआई को समझने में समस्या होती है।

आप कैसे जानते हैं कि लोगों को क्या समस्या है? क्या आपने उनसे पूछा? क्या इस बारे में कोई सर्वेक्षण या अध्ययन या कोई प्रश्नावली थी? आप इस जानकारी से कैसे आए?

मैं एक ऐसा उपयोगकर्ता हूं जिसने शून्य से शुरुआत की और एपीआई सीखा। नामकरण में कोई समस्या नहीं थी। सभी एपीआई में कुछ अजीब नामकरण परंपराएं हैं। सभी कार्यों को कुछ हद तक संक्षिप्त करने की आवश्यकता है ताकि आप उन्हें कोड में लिख सकें।

@pycbouh यदि आप मुझे यह समझाने की कोशिश कर रहे हैं कि यहां सभी नामकरण सुझाव अच्छे हैं तो मुझे सम्मानपूर्वक आपसे असहमत होना पड़ेगा। यह एक ऐसा सूत्र है जो परिवर्तनों पर चर्चा करता है और मैं यहां यह कहने के लिए हूं कि कुछ प्रस्तावित परिवर्तन न केवल आवश्यक/या मांगे गए हैं बल्कि केवल लंबे और समान रूप से भ्रमित करने वाले हैं। कुछ वास्तव में अच्छे हैं और स्वागत योग्य हैं। आइए हम सभी सामूहिक रूप से सब कुछ का नाम बदलें, क्योंकि आपके जैसे कुछ लोगों को लगता है कि पूरे समुदाय को एपीआई नामों से समस्या है। मेरे पास नहीं था और कभी नहीं था और मैंने शुरुआत के रूप में शुरुआत की। और मैं मुट्ठी भर अन्य लोगों को जानता हूं जो या तो नहीं करते हैं। मेरा मानना ​​​​है कि इनमें से कुछ परिवर्तन महत्वपूर्ण हैं और पूरे समुदाय द्वारा या कम से कम पूर्ण रिलीज से पहले योगदानकर्ताओं द्वारा समीक्षा की जानी चाहिए।

आप कैसे जानते हैं कि लोगों को क्या समस्या है? क्या आपने उनसे पूछा?

इस धागे में अधिकांश प्रविष्टियाँ समस्याओं के साथ आने वाले लोगों द्वारा उत्पन्न की जाती हैं, चाहे वह यहाँ GitHub पर हो (और उन मामलों में मुद्दे जुड़े हुए हैं) या अन्य समुदाय या व्यक्तिगत चैनलों का उपयोग कर रहे हैं। यह मत समझो कि हम यहाँ बैठे हैं अपने निजी अंगों को चाट रहे हैं क्योंकि हमारे पास इंजन में नाम बदलने के लिए अन्य कार्यों या संपत्ति पर विचार करने के अलावा और कुछ नहीं है।

इसके अलावा, यहां प्रस्तावित बहुत से परिवर्तनों पर कार्रवाई भी नहीं की गई है, कोई पीआर या कोई अन्य गतिविधि नहीं थी। वे सूचीबद्ध हैं और बस इतना ही। पीआर पर नज़र रखें और यदि कोई आपको ठेस पहुँचाता है तो उस पर टिप्पणी करने में संकोच न करें। उसके बाद परिवर्तनों को स्वीकृति और विलय करना गोडोट के प्रधान मंत्री पर निर्भर है। रचनात्मक बनें और आप कुछ अवांछित संशोधनों को रोक सकते हैं, लेकिन यह मत भूलिए कि आपने खुद एक बार क्या कहा था:

जो आपके लिए अच्छा है वह शायद किसी और के लिए अच्छा न हो।

तो भले ही आपको इस बिंदु तक एपीआई के साथ कोई समस्या न हो, इसका मतलब यह नहीं है कि दूसरों के पास न तो था या भविष्य में उन्हें कोई समस्या नहीं होगी।

सभी एपीआई में कुछ अजीब नामकरण परंपराएं हैं।

यह अच्छा है अगर बात करने के लिए एक सम्मेलन है। लेकिन गोडोट में कुछ एपीआई का नाम ओपन सोर्स होने से बहुत पहले रखा गया था और हो सकता है कि यह उतना सोचा न हो जितना कि कोई उम्मीद करेगा। एक बार फिर मैं आपसे यह नहीं मानने के लिए कहता हूं कि यहां के लोग इसके लिए बदलाव का सुझाव देते हैं।

कृपया यहां इस प्रकार की चर्चा न करें। यदि आप विशिष्ट एपीआई परिवर्तनों पर चर्चा करना चाहते हैं, तो यह ठीक है, लेकिन ब्लैंकेट स्टेटमेंट जो आपको यहां दिए गए सुझावों को पसंद नहीं हैं, सहायक नहीं हैं।

कोर डेवलपर इन सुझावों में से प्रत्येक की एक-एक करके समीक्षा करेंगे। यह संभावना है कि कई अंत में स्वीकार नहीं किए जाएंगे।

अस्थायी रूप से लॉक किया जा रहा है, बाद में अनलॉक हो जाएगा।

क्या हम निम्नलिखित बिंदुओं को सूची में जोड़ सकते हैं?

• AnimationPlayer : stop() से pause() नाम बदलें (https://github.com/godotengine/godot/issues/16863#issuecomment-562363660, godotengine/godot-proposals#287)
• AnimatedSprite : stop() का नाम बदलकर pause() (#31168) (पहले ही जोड़ा जा चुका है)
• AnimatedSprite3D : stop() का नाम बदलकर pause() (#31168) (पहले ही जोड़ा जा चुका है)
• Tween : stop() से pause() , stop_all() से pause_all() बदलें (PR #41794, #43442)

बीच: नाम बदलें रोकें () को रोकें (), रोकें_ऑल () से रोकें_ऑल () (#43442)

यह #41794 . द्वारा कवर किया गया है

@opl- इस पर भी यहाँ चर्चा की गई है: https://github.com/godotengine/godot-proposals/issues/287

कुछ नाम जो यह स्पष्ट कर सकते हैं कि ये वैश्विक दायरा RNG कार्य क्या करते हैं:

• seed() -> set_seed() (शायद RandomNumberGenerator से मेल खाने के लिए get_seed() भी जोड़ें) - वर्तमान में, यह स्पष्ट नहीं है कि यह एक सेटर फ़ंक्शन है।
• rand_seed() -> rand_from_seed() - वर्तमान में, ऐसा लगता है कि यह बीज या कुछ और को यादृच्छिक बना सकता है, जब यह वास्तव में प्रदान किए गए बीज के आधार पर एक यादृच्छिक संख्या देता है।

rand_seed () -> rand_from_seed () - वर्तमान में, ऐसा लगता है कि यह बीज या कुछ और को यादृच्छिक बना सकता है, जब यह वास्तव में प्रदान किए गए बीज के आधार पर एक यादृच्छिक संख्या देता है।

सिवाय इसके कि यह बीज को यादृच्छिक करता है। दस्तावेज़ीकरण पढ़ें।

rand_seed () -> rand_from_seed () - वर्तमान में, ऐसा लगता है कि यह बीज या कुछ और को यादृच्छिक बना सकता है, जब यह वास्तव में प्रदान किए गए बीज के आधार पर एक यादृच्छिक संख्या देता है।

सिवाय इसके कि यह बीज को यादृच्छिक करता है। दस्तावेज़ीकरण पढ़ें।

माफ़ करना। मेरा मतलब यह था कि ऐसा लगता है जैसे यह केवल बीज को यादृच्छिक बनाता है। शायद यह rand_int_from_seed() होना चाहिए, क्योंकि यह एक int देता है? असल में, दस्तावेज़ यह निर्दिष्ट नहीं करते कि यह किस प्रकार का रिटर्न देता है, केवल "यादृच्छिक ... संख्या" का उल्लेख करता है। क्या यह एक इंट है?

तो यह आपके द्वारा पारित बीज के आधार पर एक नया बीज उत्पन्न करता है और फिर उस नए बीज के आधार पर एक नई संख्या उत्पन्न करता है? नाम बदलने के बारे में निश्चित नहीं है, लेकिन विवरण वहां कुछ पुनर्विक्रय का उपयोग कर सकता है, अगर ऐसा हो रहा है।

यदि वह ऐसा करता है तो ऐसा लगता है कि इस विधि को 2 छोटे तरीकों में विभाजित किया जाना चाहिए, जिसका नाम बदलने के बजाय एक काम करना चाहिए

नियंत्रण::लंबित_आकार बदलें

अप्रयुक्त।

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

मैं अब समझता हूं कि यह विधि ज्यादातर GDScript is (जो कि extends btw थी) के

भ्रम की स्थिति मैं में भाग जाँच विशेष वस्तु प्रकार मौजूदा (विरासत) के बिना की है या नहीं:

// 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() सामान्य रूप से मुझे भ्रमित कर रहे हैं