Godot: बेहतर कस्टम संपादकप्लगइन नोड्स

मुझे समझ नहीं आ रहा है कि आपका क्या मतलब है

@reduz जब आप दृश्य में एक नोड जोड़ते हैं जो एक प्लगइन द्वारा बनाया गया एक प्रकार है, तो इसमें पहले से ही प्लगइन स्क्रिप्ट संलग्न है। इसलिए कस्टम व्यवहार के साथ एक और स्क्रिप्ट जोड़ना असंभव है।

बिल्कुल नहीं, यह मूल डिजाइन द्वारा है और नहीं बदलेगा।

अगस्त 7, 2016 18:11 पर, "जॉर्ज मार्क्स" नोटिफिकेशन @github.com ने लिखा:

@reduz https://github.com/reduz जब आप दृश्य में एक नोड जोड़ते हैं जो a
एक प्लगइन द्वारा बनाया गया प्रकार, इसमें पहले से ही प्लगइन स्क्रिप्ट संलग्न है। इसलिए
कस्टम व्यवहार के साथ एक और स्क्रिप्ट जोड़ना असंभव है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/6067#issuecomment -238108767,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AF-Z29F5q8PaoBv4OrzAUayzrfNjfHyZks5qdkoUgaJpZM4JejbZ
.

यह दुख की बात है। लेकिन आप स्क्रिप्ट को हमेशा माता-पिता या बच्चे को जोड़ सकते हैं।

वोंटफिक्स के रूप में बंद करना।

हो सकता है कि मैं कुछ गलत समझ रहा हो, लेकिन यदि आपका कस्टम प्रकार एक स्क्रिप्ट है,
इसे बनाए गए नोड में कैसे शामिल नहीं किया जाएगा? इसका कोई मतलब नहीं है
यह अलग होना

7 अगस्त 2016 को रात 9:52 बजे, "जॉर्ज मार्क्स" नोटिफिकेशन @github.com ने लिखा:

यह दुख की बात है। लेकिन आप स्क्रिप्ट को हमेशा माता-पिता या बच्चे को जोड़ सकते हैं।

वोंटफिक्स के रूप में बंद करना।

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

मुझे लगता है कि इसे प्रति नोड दो (या अधिक) स्क्रिप्ट रखने की क्षमता की आवश्यकता होगी, हालांकि यह वास्तव में ज्यादा समझ में नहीं आता है।

गोडोट ने मूल रूप से इसका समर्थन किया, लेकिन यह लाभ से अधिक परेशानी थी

7 अगस्त 2016 को रात 10:36 बजे, "जॉर्ज मार्क्स" नोटिफिकेशन @github.com ने लिखा:

मुझे लगता है कि इसे प्रति दो (या अधिक) स्क्रिप्ट रखने की क्षमता की आवश्यकता होगी
नोड, हालांकि यह वास्तव में ज्यादा समझ में नहीं आता है।

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

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

मुझे लगता है कि दृश्य पर वापस जाने के लिए + स्क्रिप्ट को फिर कॉम्बो का विस्तार करने के लिए।

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

सोम, अगस्त 8, 2016 को सुबह 10:40 बजे, डोमिनिक बनासज़क सूचनाएं @github.com
लिखा था:

समस्या यह है कि कस्टम नोड्स बेकार के बगल में हैं क्योंकि वे वास्तव में नहीं हैं
"कस्टम नोड्स", वे केवल पूर्व-सेट स्क्रिप्ट के साथ बेस नोड्स हैं और अलग हैं
चिह्न। मुझे लगता है कि दृश्य पर वापस जाने के लिए + स्क्रिप्ट को फिर कॉम्बो का विस्तार करने के लिए।

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

मुझे अच्छा लगेगा अगर इसे UI के माध्यम से स्वचालित/आसान बनाया जा सके।

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

• कस्टम आइकन, कस्टम पहचानकर्ता
• नोड विजेट जोड़ें के माध्यम से तत्काल (और मुझे लगता है कि स्क्रिप्ट के माध्यम से, ग्लोबल स्कोप के संपर्क में है?)
• एक स्क्रिप्ट के माध्यम से एक कस्टम एपीआई कोड किया गया है (उदाहरण के लिए RedNode2D का विस्तार Node2D होगा, और एक कस्टम स्क्रिप्ट के माध्यम से परिभाषित एक लाल मॉड्यूलेशन होगा)
• फिर इस कस्टम नोड को एक अंतर्निर्मित नोड की तरह व्यवहार करना चाहिए, यानी उपयोगकर्ता इसे बिना किसी स्क्रिप्ट के उदाहरण देने में सक्षम होना चाहिए (कस्टम एपीआई सीधे उपयोगकर्ता के सामने नहीं आएगा, जैसे अंतर्निहित स्क्रिप्ट के लिए जहां इसे हार्डकोड किया गया है C++ में), और उसमें एक स्क्रिप्ट संलग्न करें जो कस्टम नोड का विस्तार करेगी (उदाहरण के लिए extends RedNode2D )।

कस्टम नोड घोषित करते समय यह "स्वाभाविक" अपेक्षा होगी, और यह एक बहुत ही शक्तिशाली विशेषता होगी; मैं ऊपर से इकट्ठा करता हूं कि यह अब तक इस तरह से काम नहीं करता है, आंशिक रूप से डिजाइन निर्णयों के कारण। यदि कार्यक्षमता का कोई तरीका है जैसे मैंने ऊपर वर्णित किया है, तो मुझे पूरा यकीन है कि इसमें बहुत सारे अनुप्रयोग होंगे। एसेटलिब कस्टम नोड्स से भरा होगा जो बॉक्स से बाहर बहुत काम करते हैं और इसका उपयोग इस तरह किया जा सकता है जैसे कि वे बिल्ट-इन हों।

क्या किया जा सकता है या क्या नहीं, इस पर आम सहमति होने तक फिर से खोलना।

+1
यह मेरे लिए पहली बड़ी बाधाओं में से एक था जब मैंने एक मौजूदा प्रोजेक्ट को "OtherEngine(tm)" से गोडोट में पोर्ट करने का प्रयास किया। कस्टम प्रकार, जैसे @ akien-mga ऊपर समझाया गया है, पंजीकरण के बाद किसी भी अन्य प्रकार के अंतर्निहित प्रकार की तरह व्यवहार करना चाहिए।

कृपया बताएं कि आप किस तरह से विश्वास करते हैं कि वे नहीं करते हैं

अगस्त 8, 2016 11:50 पूर्वाह्न पर, "राल्फ होल्ज़ेमर" नोटिफिकेशन @github.com ने लिखा:

+1
जब मैंने पोर्ट करने की कोशिश की तो यह मेरे लिए पहली बड़ी बाधाओं में से एक थी
गोडोट के लिए "OtherEngine(tm)" से मौजूदा परियोजना। कस्टम प्रकार, जैसे
@ akien-mga https://github.com/akien-mga ऊपर बताया गया है, बस
पंजीकरण के बाद किसी अन्य निर्मित प्रकार की तरह व्यवहार करें।

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

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

लेकिन "नया नोड/संसाधन बनाएं" संवादों में कस्टम नोड्स के साथ इनहेरिटेंस ट्री बनाना भी असंभव है क्योंकि वे केवल इन पेड़ों में दिखाई देते हैं जब आप उन्हें add_custom_type के माध्यम से माता-पिता के रूप में एक अंतर्निहित प्रकार के साथ पंजीकृत करते हैं।

उदाहरण के लिए, मान लें कि मैं अपने प्रोजेक्ट में अपने सभी कस्टम प्रकारों को एक बेस प्रकार से प्राप्त करना चाहता हूं।

बेस.जीडी

extends Node
export (Color) var color

type_a.gd

extends base.gd

type_b.gd

extends base.gd

जैसा कि अभी है, मुझे इस तरह के प्रकारों को पंजीकृत करना होगा। इस मामले में, add_custom_type का दूसरा तर्क "नोड" होना चाहिए, अन्यथा वे संवादों में दिखाई नहीं देंगे।

func _enter_tree():
    add_custom_type("Base", "Node", preload("base.gd"), preload("base.png"))
    add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
    add_custom_type("TypeB", "Node", preload("type_b.gd"), preload("type_b.png"))

... और यह परिणाम है।

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

अब, यदि कस्टम प्रकारों को वैश्विक दायरे में पूरी तरह से पंजीकृत किया जा सकता है, जैसे कि @ akien-mga ऊपर उल्लेख किया गया है, तो चीजों को समझना और उपयोग करना बहुत आसान होगा।

सबसे पहले, आप फ़ाइल पथ/नाम के बजाय प्रकार नाम से संदर्भित कस्टम प्रकार से प्राप्त कर सकते हैं।

बेस.जीडी

extends Node
export (Color) var color

type_a.gd

extends Base

type_b.gd

extends Base

... फिर, कस्टम प्रकारों के पंजीकरण को इस तरह सरल बनाया जा सकता है। Add_custom_type के अनुपलब्ध दूसरे पैरामीटर पर ध्यान दें।

func _enter_tree():
    add_custom_type("Base", preload("base.gd"), preload("base.png"))
    add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
    add_custom_type("TypeB", preload("type_b.gd"), preload("type_b.png"))

... और आपको "नया नोड/संसाधन बनाएं" संवादों में एक बहुत अच्छा अवलोकन मिलेगा:

... और निश्चित रूप से एक कस्टम स्क्रिप्ट के साथ संपादक में उन प्रकारों को विस्तारित करने की क्षमता:

... जिसे स्क्रिप्ट नाम/पथ के बजाय टाइप नाम से भी संदर्भित किया जाएगा

extends Base

यहाँ ऊपर से उदाहरण प्लगइन चारों ओर खेलने के लिए है।
Addons.zip

ओह, मैं देख रहा हूँ .. इन दो थिग्स को निश्चित रूप से ठीक किया जाना चाहिए, साथ में
स्क्रिप्ट बनाने के लिए इनहेरिटेंस सपोर्ट जोड़ना डायलॉग

अगस्त 8, 2016 1:54 अपराह्न पर, "राल्फ होल्ज़ेमर" नोटिफिकेशन @github.com ने लिखा:

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

लेकिन कस्टम नोड्स के साथ इनहेरिटेंस ट्री बनाना भी असंभव है
"नया नोड/संसाधन बनाएं" संवाद क्योंकि वे केवल इनमें दिखाई देते हैं
पेड़ जब आप उन्हें एक अंतर्निहित प्रकार के साथ माता-पिता के रूप में पंजीकृत करते हैं
add_custom_type.

उदाहरण के लिए, मान लें कि मैं अपने सभी कस्टम प्रकारों को my . में इनहेरिट करना चाहता हूं
एकल आधार प्रकार से परियोजना।

_base.gd http://base.gd_

नोड बढ़ाता है
निर्यात (रंग) वर रंग

_type_a.gd http://type_a.gd_

आधार बढ़ाता है। जीडी

_type_b.gd http://type_b.gd_

आधार बढ़ाता है। जीडी

जैसा कि अभी है, मुझे इस तरह के प्रकारों को पंजीकृत करना होगा। इसमें
मामले में, add_custom_type का दूसरा तर्क "नोड" होना चाहिए, अन्यथा
वे संवादों में दिखाई नहीं देंगे।

func _enter_tree ():
add_custom_type ("बेस", "नोड", प्रीलोड ("बेस.जीडी"), प्रीलोड ("बेस.पीएनजी"))
add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", "Node", preload("type_b.gd"), preload("type_b.png"))

... और यह परिणाम है।

[छवि: add_node_flat]
https://cloud.githubusercontent.com/assets/8785013/17486294/9bcc029c-5d90-11e6-81e6-6fce6b0e7cf0.png

हालांकि इस तरह के कस्टम प्रकारों को पंजीकृत करने में सक्षम होना अच्छा है,
संवाद उन प्रकार की विरासत की प्रकृति को प्रतिबिंबित नहीं करते जैसे
अन्य प्रकार में निर्मित। किसी भी प्रकार के बिल्ट इन के लिए, मैं उस पेड़ को देख सकता हूँ और
एक नज़र में देखें कि मैं किसके साथ काम कर रहा हूं। उदाहरण के लिए, मैं यह सुनिश्चित कर सकता हूँ कि
स्प्राइट _is a_ Node2D है और इसके लिए सभी फ़ंक्शन _प्रदान किए गए हैं
by_ Node2D. कस्टम प्रकारों के लिए भी यही सच नहीं है।

अब, यदि कस्टम प्रकारों को वैश्विक दायरे में पूरी तरह से पंजीकृत किया जा सकता है, जैसे
@ akien-mga https://github.com/akien-mga ऊपर उल्लेख किया गया है, चीजें होंगी
समझने और उपयोग करने में बहुत आसान हो।

सबसे पहले, आप _type name_ द्वारा संदर्भित एक कस्टम प्रकार से इनहेरिट कर सकते हैं
फ़ाइल पथ/नाम के बजाय।

_base.gd http://base.gd_

नोड बढ़ाता है
निर्यात (रंग) वर रंग

_type_a.gd http://type_a.gd_

आधार बढ़ाता है

_type_b.gd http://type_b.gd_

आधार बढ़ाता है

... फिर, कस्टम प्रकारों के पंजीकरण को सरल बनाया जा सकता है जैसे
यह। Add_custom_type के अनुपलब्ध दूसरे पैरामीटर पर ध्यान दें।

func _enter_tree ():
add_custom_type ("बेस", प्रीलोड ("बेस.जीडी"), प्रीलोड ("बेस.पीएनजी"))
add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", प्रीलोड ("type_b.gd"), प्रीलोड ("type_b.png"))

... और आपको "नया बनाएं" में एक बहुत अच्छा अवलोकन मिलेगा
नोड/संसाधन" संवाद:

[छवि: add_node_tree]
https://cloud.githubusercontent.com/assets/8785013/17487264/619f4da0-5d94-11e6-880f-a00791e30125.png

... और निश्चित रूप से संपादक में उन प्रकारों को विस्तारित करने की क्षमता a
कस्टम स्क्रिप्ट:

[छवि: custom_type_no_script]
https://cloud.githubusercontent.com/assets/8785013/17487807/b54aced2-5d96-11e6-90e5-ee838b6a1335.png

... जिसे स्क्रिप्ट के बजाय _type name_ द्वारा भी संदर्भित किया जाएगा
नाम/पथ

आधार बढ़ाता है

यहाँ ऊपर से उदाहरण प्लगइन चारों ओर खेलने के लिए है।
addons.zip https://github.com/godotengine/godot/files/407291/addons.zip

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

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

8 अगस्त 2016 को दोपहर 2:02 बजे, "जुआन लिनिएत्स्की" [email protected] ने लिखा:

ओह, मैं देख रहा हूँ .. इन दो थिग्स को निश्चित रूप से ठीक किया जाना चाहिए, साथ में
स्क्रिप्ट बनाने के लिए इनहेरिटेंस सपोर्ट जोड़ना डायलॉग

अगस्त 8, 2016 1:54 अपराह्न पर, "राल्फ होल्ज़ेमर" नोटिफिकेशन @github.com ने लिखा:

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

लेकिन कस्टम नोड्स के साथ इनहेरिटेंस ट्री बनाना भी असंभव है
"नया नोड/संसाधन बनाएं" संवाद क्योंकि वे केवल इनमें दिखाई देते हैं
पेड़ जब आप उन्हें एक अंतर्निहित प्रकार के साथ माता-पिता के रूप में पंजीकृत करते हैं
add_custom_type.

उदाहरण के लिए, मान लें कि मैं अपने सभी कस्टम प्रकारों को my . में इनहेरिट करना चाहता हूं
एकल आधार प्रकार से परियोजना।

_base.gd http://base.gd_

नोड बढ़ाता है
निर्यात (रंग) वर रंग

_type_a.gd http://type_a.gd_

आधार बढ़ाता है। जीडी

_type_b.gd http://type_b.gd_

आधार बढ़ाता है। जीडी

जैसा कि अभी है, मुझे इस तरह के प्रकारों को पंजीकृत करना होगा। इसमें
मामले में, add_custom_type का दूसरा तर्क "नोड" होना चाहिए, अन्यथा
वे संवादों में दिखाई नहीं देंगे।

func _enter_tree ():
add_custom_type ("बेस", "नोड", प्रीलोड ("बेस.जीडी"), प्रीलोड ("बेस.पीएनजी"))
add_custom_type("TypeA", "Node", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", "Node", preload("type_b.gd"), preload("type_b.png"))

... और यह परिणाम है।

[छवि: add_node_flat]
https://cloud.githubusercontent.com/assets/8785013/17486294/9bcc029c-5d90-11e6-81e6-6fce6b0e7cf0.png

हालांकि इस तरह के कस्टम प्रकारों को पंजीकृत करने में सक्षम होना अच्छा है,
संवाद उन प्रकार की विरासत की प्रकृति को प्रतिबिंबित नहीं करते जैसे
अन्य प्रकार में निर्मित। किसी भी प्रकार के बिल्ट इन के लिए, मैं उस पेड़ को देख सकता हूँ और
एक नज़र में देखें कि मैं किसके साथ काम कर रहा हूं। उदाहरण के लिए, मैं यह सुनिश्चित कर सकता हूँ कि
स्प्राइट _is a_ Node2D है और इसके लिए सभी फ़ंक्शन _प्रदान किए गए हैं
by_ Node2D. कस्टम प्रकारों के लिए भी यही सच नहीं है।

अब, यदि कस्टम प्रकारों को वैश्विक दायरे में पूरी तरह से पंजीकृत किया जा सकता है,
जैसे @ akien-mga https://github.com/akien-mga ऊपर बताया गया है, चीज़ें
समझने और उपयोग करने में बहुत आसान होगा।

सबसे पहले, आप _type name_ द्वारा संदर्भित एक कस्टम प्रकार से इनहेरिट कर सकते हैं
फ़ाइल पथ/नाम के बजाय।

_base.gd http://base.gd_

नोड बढ़ाता है
निर्यात (रंग) वर रंग

_type_a.gd http://type_a.gd_

आधार बढ़ाता है

_type_b.gd http://type_b.gd_

आधार बढ़ाता है

... फिर, कस्टम प्रकारों के पंजीकरण को सरल बनाया जा सकता है जैसे
यह। Add_custom_type के अनुपलब्ध दूसरे पैरामीटर पर ध्यान दें।

func _enter_tree ():
add_custom_type ("बेस", प्रीलोड ("बेस.जीडी"), प्रीलोड ("बेस.पीएनजी"))
add_custom_type("TypeA", preload("type_a.gd"), preload("type_a.png"))
add_custom_type("TypeB", प्रीलोड ("type_b.gd"), प्रीलोड ("type_b.png"))

... और आपको "नया बनाएं" में एक बहुत अच्छा अवलोकन मिलेगा
नोड/संसाधन" संवाद:

[छवि: add_node_tree]
https://cloud.githubusercontent.com/assets/8785013/17487264/619f4da0-5d94-11e6-880f-a00791e30125.png

... और निश्चित रूप से संपादक में उन प्रकारों को विस्तारित करने की क्षमता a
कस्टम स्क्रिप्ट:

[छवि: custom_type_no_script]
https://cloud.githubusercontent.com/assets/8785013/17487807/b54aced2-5d96-11e6-90e5-ee838b6a1335.png

... जिसे स्क्रिप्ट के बजाय _type name_ द्वारा भी संदर्भित किया जाएगा
नाम/पथ

आधार बढ़ाता है

यहाँ ऊपर से उदाहरण प्लगइन चारों ओर खेलने के लिए है।
addons.zip https://github.com/godotengine/godot/files/407291/addons.zip

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

@reduz
क्या यह स्पष्ट करने के लिए कोई तकनीकी कारण है कि नोड स्क्रिप्टेड है और यदि हां, तो क्या इसे एक अधिकृत स्क्रिप्ट स्लॉट होना चाहिए?

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

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

इसके बजाय, इसे नोड ट्री में एक कस्टम प्रकार के रूप में या अलग-अलग रंग, कुछ आइकन या कुछ और के माध्यम से गुण संपादक के रूप में इंगित किया जा सकता है, बिना खाली स्क्रिप्ट स्लॉट का त्याग किए।

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

यहां मुद्दा यह है कि कस्टम नोड _चाहिए_ को परिभाषित करने वाली स्क्रिप्ट को छिपाया जाना चाहिए, क्योंकि यह _instanced_ नोड की नहीं बल्कि इसके प्रकार की संपत्ति है। तो इस स्क्रिप्ट को कस्टम नोड को गुण प्रदान करना चाहिए, लेकिन यह इंस्टेंस नोड के उपयोगकर्ता के लिए अदृश्य होना चाहिए क्योंकि अंतर्निहित नोड्स के सी ++ वर्ग हैं। यह एक एपीआई प्रदान करेगा, लेकिन संशोधित नहीं होगा, केवल विस्तार योग्य होगा। जैसे जब आप स्प्राइट को इंस्टेंस करते हैं, तो आपको इंस्टेंस नोड की स्क्रिप्ट के रूप में scenes/2d/sprite.cpp संलग्न नहीं मिलता है, आपको my_custom_node.gd को इंस्टेंस कस्टम नोड की संशोधित स्क्रिप्ट के रूप में संलग्न नहीं करना चाहिए।

अब, मुझे नहीं पता कि यह अभी तकनीकी रूप से _possible_ है, लेकिन यह प्राकृतिक उपयोग का मामला AFAIU होगा। यदि आप कस्टम प्रकार की स्क्रिप्ट को संशोधित करते हैं, तो यह स्वयं प्रकार को संशोधित करेगा, और इस प्रकार इस प्रकार के सभी उदाहरणों को प्रभावित करेगा। लेकिन कस्टम प्रकार का उपयोग करने वाले इंस्टेंस नोड्स की अपनी स्क्रिप्ट होनी चाहिए कि extends CustomNode ।

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

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

क्षमा करें, यदि नोड में कोई स्क्रिप्ट है तो मैं एक स्क्रिप्ट को छिपाने के खिलाफ हूं। क्या है
कुछ ऐसा अनुकरण करने का बिंदु जो नहीं है?

तथ्य यह है कि इसमें एक स्क्रिप्ट है इसका मतलब यह नहीं है कि स्लॉट व्यस्त है या इसकी आवश्यकता है a
दूसरी स्क्रिप्ट, क्योंकि आप बस इनहेरिट करने वाली एक नई स्क्रिप्ट बना सकते हैं
मौजूदा एक।

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

10 अगस्त 2016 को रात 11:01 बजे, "मार्क" नोटिफिकेशन @github.com ने लिखा:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।

इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/godotengine/godot/issues/6067#issuecomment -239055986,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AF-Z2xLGOhgMk__ZoRW1neRu1aRb5Qr_ks5qeoJogaJpZM4JejbZ
.

@reduz मुझे लगता है कि यह काफी अच्छा होगा: मुस्कान:

@reduz मैं सहमत हूं, और मैंने यह नहीं कहा कि हमें दूसरी स्क्रिप्ट चाहिए। मैं बस सोच रहा था कि क्या होगा यदि आप पहले वाले (प्लगइन द्वारा परिभाषित कस्टम) को विरासत में मिली एक स्क्रिप्ट जोड़ते हैं, लेकिन फिर इसे हटाने का निर्णय लेते हैं। फिर यह बिना किसी स्क्रिप्ट के नोड को मूल इंजन प्रकार में वापस कर देगा?

मुझे लगता है कि हम इस संबंध में किसी तरह इसे और अधिक उपयोगकर्ता के अनुकूल बना सकते हैं

11 अगस्त 2016 06:10 को, "मार्क" नोटिफिकेशन @github.com ने लिखा:

@reduz https://github.com/reduz मैं सहमत हूं, और मैंने यह नहीं कहा कि हमें a . की आवश्यकता है
दूसरी लिपि। मैं बस सोच रहा था कि अगर आप एक स्क्रिप्ट जोड़ते हैं तो क्या होगा
पहले वाले (प्लगइन द्वारा परिभाषित कस्टम) को इनहेरिट करना, लेकिन फिर निर्णय लेना
इसे हटा दो। यह तब नोड को बिना किसी के मूल इंजन प्रकार में वापस कर देगा
फिर स्क्रिप्ट?

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

मैं इस टिप्पणी https://github.com/godotengine/godot/issues/6067#issuecomment -238299152 पर वर्णित पथ के बजाय नोड परिभाषित प्रकार द्वारा विस्तार का हिस्सा खोदता हूं।

जोड़ने के लिए कुछ और सुझाव:

• node.get_type() एक ऐडऑन प्रकार पर प्रकार का नाम वापस करना चाहिए।

उदाहरण:

add_custom_type("MyCustomNode", "Node2D", preload("my_custom_node.gd"), preload("icon.png"))

node.get_type() should return "MyCustomNode" instead of "Node2D"

• एक प्लगइन अपने प्रकार के अनुसार दूसरे प्लगइन का विस्तार कर सकता है

उदाहरण:
उपयोगकर्ता A Node2D पर आधारित अधिक सटीक दृश्यता नोटिफ़ायर के लिए एक प्लगइन बनाता है
add_custom_type("PreciseNotifier", "Node2D", preload("precise_notifier.gd"), preload("icon.png"))

फिर उपयोगकर्ता बी किसी अन्य कॉन्फ़िगरेशन के साथ किसी अन्य एडऑन फ़ोल्डर पर सटीक नोटिफ़ायर के आधार पर एक ट्रिगर एडऑन विकसित करता है।
add_custom_type("Trigger", "PreciseNotifier", preload("trigger.gd"), preload("icon.png"))
और ट्रिगर.जीडी स्क्रिप्ट पर उसे इसे टाइप नाम के साथ भी विस्तारित करना चाहिए
extends PreciseAddon
बेशक उपयोगकर्ता को ट्रिगर वन का उपयोग करने के लिए दोनों ऐडऑन जोड़ना चाहिए

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

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

यह प्रस्ताव शायद कम सहज होगा क्योंकि यह अभी भी कस्टम नोड्स को उनके इन-इंजन समकक्षों से कुछ अलग तरीके से मानता है। विचार?

इस चर्चा पर बाद में अपना 2 सेंट देते हुए, मुझे लगता है कि समस्या यह है कि एक ऐडऑन विरासत में मिले कई नोड्स डिफ़ॉल्ट रूप से एक ही मूल स्क्रिप्ट को साझा करते हैं; मुझे कोड दृश्यता पर कोई आपत्ति नहीं है, जैसा कि जुआन ने इस धागे की शुरुआत में तर्क दिया था, एक डिज़ाइन विकल्प है और एडऑन का उपयोग करके डेवलपर के लिए नोड व्यवहार को पारदर्शी बनाने के लिए भी कुछ महत्वपूर्ण है। लेकिन आमतौर पर आप कोड में विभिन्न नोड्स के व्यवहार को बदलना चाहते हैं, और अभी ऐसा करने का एकमात्र तरीका मूल स्क्रिप्ट संदर्भ को हटाकर, एक नई स्क्रिप्ट बनाना और मूल स्क्रिप्ट कोड को कॉपी-पेस्ट करना है। आप नए एडऑन नोड की स्क्रिप्ट को नई .gd फ़ाइल में save as भी नहीं कर सकते, क्योंकि यह मूल स्क्रिप्ट का उपयोग करके अन्य सभी नोड्स के संदर्भ को बदल देगा, इसलिए यह तीन-चरण कॉपी-पेस्ट है प्रक्रिया विचित्र।

फिर से, यह जटिल नहीं है, बस इस विशेष मामले में, GDScript संपादक पर save as विकल्प वैसा व्यवहार नहीं करता जैसा मैं अपेक्षा करता हूं, और मुझे लगता है कि यह अधिक UI अनुकूल होगा कि एक ' एडॉन्स के त्वरित अनुकूलन की अनुमति देने के लिए जीडीस्क्रिप्ट संपादक पर 'कॉपी एंड सेव' बटन (और आर्किटेक्चर-वार, इस बटन को दृश्यमान बनाना समझ में आता है क्योंकि यह विरासत में मिली स्क्रिप्ट का उपयोग किए बिना गोडोट पर गेम बनाने का एक अच्छा तरीका है)।

@henriquelalves मैंने सोचा कि कोड में कस्टम नोड्स को अनुकूलित करना मूल रूप से विरासत है? जैसे, extends "addons/thing/thing.gd" ? विरासत में मिली स्क्रिप्ट अभी भी वही काम करेगी जो एडऑन संस्करण करता है, बशर्ते आप जानते हैं कि आप क्या ओवरराइड कर रहे हैं। कॉपी/पेस्ट करने की कोई जरूरत नहीं है।

@Zylann आप सही हैं, लेकिन आमतौर पर मुझे कोड दृश्यता और ऑटो-पूर्णता क्विर्क के कारण यह विशेष दृष्टिकोण पसंद नहीं है (कम से कम 2.1 पर, मैंने अब तक इसका परीक्षण नहीं किया है)। और अधिकांश समय मैं विधियों को ओवरराइड नहीं करना चाहता, केवल उन विशेष चीजों को बदलें जो मूल एडऑन स्क्रिप्ट पर विस्तारित चर नहीं हैं। यही मुझे वर्तमान save as व्यवहार पर परेशान करता है, मैं ऐसी स्क्रिप्ट के प्रत्येक नोड संदर्भ को बदले बिना किसी स्क्रिप्ट की प्रतिलिपि जल्दी से नहीं बना सकता; और यूआई के अनुकूल तरीके से इसे हल करने से कई नोड्स को अनुकूलित करने की मूल समस्या हल हो जाती है, साथ ही कोड दृश्यता और इस तरह (कम से कम मेरे वर्कफ़्लो में, मैं इस तरह की सोच रखने वाला अकेला हो सकता हूं)।

@henriquelalves अच्छी तरह से मैं tbh xD कॉपी/पेस्ट नहीं कर सकता और आप प्लगइन को वर्जनिंग कंट्रोल के साथ फोर्क भी कर सकते हैं और इसके बजाय पहले स्थान पर इसका इस्तेमाल कर सकते हैं।

@Zylann एक प्लगइन को फोर्क करना कुछ और भी कदम जोड़ रहा है जो मृत सरल होना चाहिए, हाहा। मुझे लगता है कि अगर यह प्राथमिकता नहीं है तो मैं मैन्युअल कॉपी-पेस्टिंग के साथ रहूंगा, भले ही मुझे अभी भी लगता है कि save as व्यवहार अजीब है।

@henriquelalves आईएस फोर्किंग ^^ कॉपी/पेस्ट करना, लेकिन यदि संस्करण नियंत्रण के बिना किया जाता है, तो प्लगइन अपडेट होने पर यह भविष्य में आपको पीछे की ओर काट देगा।

कस्टम नोड से जुड़ी एक स्क्रिप्ट होने का वर्तमान व्यवहार उस कस्टम नोड को एक ऐडऑन के रूप में रखने के लिए लगभग कोई लाभ नहीं देता है, बस स्क्रिप्ट को नोड से जोड़ता है। एकमात्र लाभ यह है कि यह नोड संवाद में दिखाई देता है, जो वास्तव में कोई लाभ नहीं है।

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

@RodeoMcCabe समस्या यह है कि हुड के तहत, कस्टम प्रकार अभी भी अभ्यास में एक इन-इंजन नोड के शीर्ष पर स्तरित स्क्रिप्ट हैं, और इसे बदला नहीं जा सकता क्योंकि कस्टम प्रकार नोड्स सीधे इंजन स्रोत में संकलित नहीं होते हैं। हमें जो करने की आवश्यकता है, वह चरणों / सुविधाओं का एक ठोस सेट तैयार करना है जो इन स्क्रिप्टेड नोड्स को उपयोगकर्ता की नज़र में, इन-इंजन नोड के व्यवहार का अनुकरण करने की अनुमति देगा। उदाहरण के लिए...

1. नोड को "एक नोड बनाएं" विंडो में जोड़ना (किया गया)
2. उपयोगकर्ता को "नोड बनाएं" विंडो के लिए नोड का टेक्स्ट "संक्षिप्त विवरण" प्रदान करने की अनुमति देना (ऐसा प्रतीत नहीं होता है? - कम से कम, यह add_custom_type का हिस्सा नहीं है)।
3. उपयोगकर्ता को नोड पदानुक्रम प्रदर्शित करने और "नोड बनाएं" विंडो में अमूर्त कस्टम प्रकारों को परिभाषित करने की अनुमति देना। इसमें संभवतः add_custom_type फ़ंक्शन में एक बूल जोड़ना शामिल होगा कि यह एक सार प्रकार है या नहीं। तदनुसार सार कस्टम प्रकारों के निर्माण को अवरुद्ध करने के लिए "नोड बनाएं" विज़ार्ड को अद्यतन करने की आवश्यकता होगी।

4. नोड को ऐसे देखें जैसे कि उसके पास कोई स्क्रिप्ट नहीं है।

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

   बी। स्क्रिप्ट प्रॉपर्टी जो इंस्पेक्टर में प्रदर्शित होती है, डिफ़ॉल्ट रूप से, खुद को खाली दिखाना चाहिए, जब तक कि उपयोगकर्ता उस पर एक स्क्रिप्ट लोड नहीं करता है, उस स्थिति में स्क्रिप्ट को कस्टम प्रकार के रूप में उपयोग किए जाने वाले स्क्रिप्ट प्रकार से प्राप्त होना चाहिए। उपयोगकर्ता को कस्टम प्रकार की स्क्रिप्ट फ़ाइल का स्थान जानने की आवश्यकता नहीं होनी चाहिए (यह अवधारणा कि यह एक स्क्रिप्ट है, उनसे छिपी होनी चाहिए)। इसका मतलब यह है कि या तो कस्टम वर्ग के लिए स्ट्रिंग नाम को अन्य इन-इंजन वर्गों की तरह जीडीस्क्रिप्ट पार्सर द्वारा पहचाना जाना चाहिए (सुनिश्चित नहीं है कि यह कितना आसान/कठिन होगा) या रिकॉर्ड लाने के लिए किसी प्रकार का वैश्विक कार्य होना चाहिए वर्ग का नाम, उदाहरण के लिए add_custom_type("MyClass", "Node", load(res://addons/git-repo/api/my_class.gd), load(res://addons/git-repo/icons/icon_myclass.svg) में स्क्रिप्ट के लिए, उपयोगकर्ता extends MyClass या extends custom("MyClass") के साथ एक स्क्रिप्ट बना सकता है।

   सी। यदि कोई उपयोगकर्ता नोड पर एक कस्टम-प्रकार-व्युत्पन्न स्क्रिप्ट लोड करता है, तो केवल "इस नोड में एक स्क्रिप्ट है" आइकन दृश्य डॉक में दिखाई देना चाहिए।

5. स्क्रिप्ट के लिए जो भी संपादक आइकन उपयोग किया जाता है, उसे वर्तमान में स्क्रिप्ट के लिए उपयोग किए जाने वाले सफेद-बॉक्स-जैसे आइकन के बजाय श्रेणी ब्लॉक में जोड़ा जाना चाहिए ( property_editor.cpp में)। यह कस्टम प्रकार नोड ऑब्जेक्ट के लिए __meta__ डिक्शनरी प्रॉपर्टी का हिस्सा होना चाहिए।

6. जब आप एक कस्टम प्रकार पर "एक स्क्रिप्ट जोड़ें" पर क्लिक करते हैं, तो इसे "इनहेरिट्स" फ़ील्ड को 4b में उपयोग की जाने वाली किसी भी विधि से भरना चाहिए।
7. यदि आप किसी स्क्रिप्ट को हटाते हैं, तो कस्टम प्रकार की स्क्रिप्ट अभी भी हुड के नीचे मौजूद होनी चाहिए और उसे हटाया नहीं जाना चाहिए। कस्टम प्रकार के नोड प्रभावी रूप से कस्टम टाइप स्क्रिप्ट का उपयोग बैकअप स्क्रिप्ट के रूप में उन मामलों में करेंगे जहां लोड की गई स्क्रिप्ट को शून्य पर सेट किया गया है। जैसे, आपको अभी भी संपादक के दृश्य डॉक और इंस्पेक्टर डॉक में मूल प्रकार के संपादक चिह्न और स्क्रिप्ट गुण दिखाई देने चाहिए। मैं पहले से ही "स्क्रिप्ट वेरिएबल्स" को वास्तविक स्क्रिप्ट के नामों से बदलने के लिए एक फीचर में विलय की प्रक्रिया में हूं, हालांकि इन सभी परिवर्तनों को जोड़े जाने पर इसे अपडेट करने की आवश्यकता होगी।
8. Object::get_script() को कस्टम प्रकार की स्क्रिप्ट वाले नोड्स के लिए null लौटाना चाहिए और कोई लोडेड स्क्रिप्ट नहीं है।
9. Object::get_property_list , और विधियों और संकेतों के अनुरूप कार्यों में कस्टम प्रकार की स्क्रिप्ट की सामग्री शामिल होनी चाहिए, भले ही कोई लोड की गई स्क्रिप्ट न हो।
10. Object::get_custom_script() या कुछ और जैसे दूसरे C++ ऑब्जेक्ट फ़ंक्शन की आवश्यकता होगी ताकि इंजन देख सके कि क्या कोई स्क्रिप्ट है, भले ही स्क्रिप्टिंग पक्ष को इस दूसरी स्क्रिप्ट के बारे में कोई जानकारी न हो।
11. किसी ऑब्जेक्ट पर एक गैर-कस्टम-प्रकार-व्युत्पन्न स्क्रिप्ट लोड करने का प्रयास स्पष्ट रूप से विफल होना चाहिए और यह पुष्टि करने के लिए कि ऑब्जेक्ट को इसे करने की अनुमति है या नहीं, एक त्रुटि (शायद संबंधित फ़ंक्शन में &is_valid संदर्भ बूल) की रिपोर्ट करनी चाहिए। इस जानकारी पर फ़ीडबैक प्रदान करने वाले संबद्ध गोडोट संपादक परिदृश्यों को भी इसके लिए खाते में अद्यतन करने की आवश्यकता होगी।

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

क्या इनमें से कोई अच्छा लगता है? मुझे यकीन है कि और भी चीजें हैं जो मुझे याद आ रही हैं क्योंकि मैं इसे थोड़ा सोच रहा हूं। अगर यह पागल लगता है, तो बस मुझे बताएं। ;-)

संपादित करें: आह, लेकिन यदि स्क्रिप्ट कस्टम प्रकार की स्क्रिप्ट से मेल खाती है, तो स्क्रिप्ट आइकन को सीन डॉक में छुपाने का reduz का सुझाव भी मूल्यवान हो सकता है। केवल, get_script() विधि को अभी भी कुछ भी नहीं लौटाना चाहिए। हो सकता है कि ऑब्जेक्ट पर एक अलग स्क्रिप्ट प्रॉपर्टी बनाए बिना इसे करने का कोई तरीका हो? Idk, क्योंकि प्रति ऑब्जेक्ट 1 स्क्रिप्ट के लिए कोडबेस में पहले से ही बहुत सारी धारणाएं हैं, जो मुझे लगता है कि हम रखना चाहते हैं, लेकिन custom_type स्क्रिप्ट अवधारणा के साथ बनाए रखना मुश्किल है।

अच्छे सुझाव, सुविचारित। मुझे लगता है कि अगर यह सब लागू किया गया तो यह वह व्यवहार देगा जिसकी हम तलाश कर रहे हैं, हालांकि मुझे लगता है कि 1 स्क्रिप्ट प्रति नोड नियम को तोड़ना बुरी खबर हो सकती है जो कोड के कई अप्रत्याशित भागों के माध्यम से प्रतिध्वनित हो सकती है। इसे नमक के दाने के साथ लें क्योंकि मैं उस कोडबेस को अच्छी तरह से नहीं जानता और मेरा C++ औसत दर्जे का है। Reduz ने ऊपर कहा है कि उन्होंने मूल रूप से प्रति नोड में एक से अधिक स्क्रिप्ट रखने की कोशिश की और "यह अधिक परेशानी थी कि यह इसके लायक था", जो मुझे उचित लगता है।

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

बिंदु 6 भी अच्छा है, और यहाँ पर मुझे लगता है कि हम इससे दूर हो सकते हैं। बिंदु 6 के अनुसार एक नई स्क्रिप्ट बनाने से वर्तमान में कस्टम नोड से जुड़ी स्क्रिप्ट को नई (व्युत्पन्न) स्क्रिप्ट में बदल दिया जाएगा। पुरानी (आधार) स्क्रिप्ट को नोड से हटा दिया जाता है। चूंकि नई संलग्न स्क्रिप्ट मूल से ली गई है, इसलिए सभी कार्यक्षमता बनी हुई है। मैं अक्सर ऐसा करता हूं, जहां मेरे पास बेस क्लास (सार या नहीं) है और व्युत्पन्न स्क्रिप्ट को नोड्स में संलग्न करता है। यहां अंतर यह है कि नई स्क्रिप्ट को केवल कस्टम नोड के नाम के बजाय extends "res://addons/path/to/base-script.gd" कहना पड़ सकता है, क्योंकि कस्टम प्रकार में अब वह स्क्रिप्ट संलग्न नहीं है .... हालांकि दूसरे विचार पर, remove_custom_type() को नहीं बुलाया गया था, और संलग्न स्क्रिप्ट अभी भी पुराने से निकली है, तो शायद यह आवश्यक नहीं है? कृपया इस बिंदु पर मेरे लिए स्पष्ट करें।

अंक 7, 8, और 9 अच्छे हैं, और संभवत: 1-स्क्रिप्ट नियम को ध्यान में रखते हुए बहुत कठिन नहीं हैं। यदि हम 1-स्क्रिप्ट नियम रखते हैं तो 10 आवश्यक नहीं है। 11 अच्छा है, क्योंकि इस तरह से अंतर्निहित नोड्स व्यवहार करते हैं यदि आप उन्हें एक स्क्रिप्ट संलग्न करने का प्रयास करते हैं जो नोड प्रकार का विस्तार नहीं करता है।

किसी भी मामले में, यह बहुत काम की तरह लगता है, और हम पहले से ही बीटा में हैं, इसलिए मुझे लगता है कि यह 3.1 या 3.2 के लिए भी होगा (हाल ही में रोडमैप को नहीं देखा है)।

@RodeoMcCabe हाँ, यह निश्चित रूप से 3.0 के लिए नहीं होगा।

1 स्क्रिप्ट प्रति नोड नियम को तोड़ना बुरी खबर हो सकती है जो कोड के कई अप्रत्याशित भागों के माध्यम से प्रतिध्वनित हो सकती है

मेरे विचार से भी। मैं एक सार्वजनिक इंटरफ़ेस के बारे में सोच रहा हूं जिसमें ऑब्जेक्ट अपनी कस्टम बैकअप स्क्रिप्ट से अवगत है, लेकिन अन्य ऑब्जेक्ट्स इससे अनजान हैं, और ऑब्जेक्ट को केवल एक स्क्रिप्ट के रूप में देखते हैं। यह चाल स्क्रिप्ट संपत्ति के लिए सेटर और गेटर को संपादित करने में होगी। गेटर को शून्य की जांच करनी चाहिए। यदि यह शून्य है, तो इसे इसके बजाय बैकअप स्क्रिप्ट वापस करनी चाहिए। इसी तरह सेटर को दोबारा जांच करनी चाहिए कि कोई नई स्क्रिप्ट बैकअप स्क्रिप्ट का विस्तार करती है, अन्यथा इसे किसी तरह विफलता की रिपोर्ट करनी चाहिए।

सार कस्टम प्रकार स्पष्ट रूप से कोई समस्या नहीं हैं क्योंकि आप उन्हें किसी भी तरह से तत्काल नहीं कर सकते हैं और इसलिए उपयोगकर्ता संपादक में एक स्क्रिप्ट नहीं जोड़ सकता है।

स्क्रिप्टिंग पक्ष (afaik) पर कोई सार प्रकार नहीं हैं। क्या आप कह रहे हैं कि आप जानते हैं कि स्क्रिप्ट को सार कैसे बनाया जाता है? can_instance विधि स्क्रिप्टिंग पक्ष के संपर्क में है, लेकिन यह केवल यह जांचता है कि क्या स्क्रिप्ट स्वयं मान्य है और, यदि यह एक उपकरण है, तो क्या ScriptServer में इस समय स्क्रिप्टिंग सक्षम है। इसका स्क्रिप्ट प्रकार की अमूर्तता से कोई लेना-देना नहीं है, मुझे नहीं लगता।

आपको यह जांचने में सक्षम होना चाहिए कि CreateDialog::_update_search विधि के लिए कक्षा सार है या नहीं, यह जानने के लिए कि टेक्स्ट को ग्रे-आउट/अचयन योग्य, आदि कब बनाया जाए।

एफवाईआई, मैंने समस्या के सार भाग (#13401) के बारे में एक मुद्दा बनाया है।

मुझे लगता है कि कुल मिलाकर यह संभव होगा यदि हमारे पास backup_script निजी सदस्य को Object प्रकार में जोड़ा जाए, और उसके बाद script संपत्ति जांच करने के लिए इसका उपयोग करें।

मैं अपने कस्टम नोड्स पर जो करता हूं वह मूल स्क्रिप्ट को प्राप्त करना है, जो कस्टम नोड स्क्रिप्ट को डिफ़ॉल्ट रूप से खाली कर देता है ...

ऑटो-इनहेरिट प्लगइन को ही प्रभावित करेगा, और प्लगइन को डुप्लिकेट किए बिना एक से अधिक बनाना संभव नहीं होगा, है ना?।

मल्टीस्क्रिप्ट को इस साल दूसरी बार जोड़ा गया था और इसे फिर से मारना आसान था (कई मुद्दों को उठाता है)।

स्क्रिप्ट के बजाय कस्टम नोड के लिए एक दृश्य को आधार के रूप में अनुमति देने से रूट स्क्रिप्ट से मुक्त हो सकता है।

मैं अपने कस्टम नोड्स पर जो करता हूं वह मूल स्क्रिप्ट को प्राप्त करना है, जो कस्टम नोड स्क्रिप्ट को डिफ़ॉल्ट रूप से खाली कर देता है ...

क्षमा करें, क्या आप कह रहे हैं कि यह किसी तरह से अमूर्तता या मेरे द्वारा पहले किए गए किसी अन्य सुझाव को प्रभावित करता है? मैं नहीं देख रहा कि यह कहाँ जुड़ता है ...

ऑटो-इनहेरिट प्लगइन को ही प्रभावित करेगा, और प्लगइन को डुप्लिकेट किए बिना एक से अधिक बनाना संभव नहीं होगा, है ना?

क्या आप यह कहने की कोशिश कर रहे हैं कि प्लगइन को /addons/ फ़ोल्डर में दो बार शामिल करने और प्रोजेक्ट सेटिंग्स के प्लगइन अनुभाग में दोनों को सक्षम करने का प्रयास किसी भी तरह से समस्याएं पैदा करेगा (मेरा मतलब है, यदि आप प्लगइन कस्टम जोड़ रहे हैं तो यह बहुत सामान्य लगता है प्रकार। एक ही नाम से परिभाषित एक से अधिक कस्टम प्रकार नहीं हो सकते हैं)।

सुनिश्चित नहीं है कि आपका क्या मतलब है "प्लगइन को डुप्लिकेट किए बिना एक से अधिक बनाना संभव नहीं होगा।" आप एक कस्टम प्रकार नोड के कई उदाहरण बना सकते हैं ठीक (?) क्योंकि यह केवल नोड बनाएगा और परिभाषित कस्टम प्रकार स्क्रिप्ट को स्वतः संलग्न करेगा। मेरे सुझाव में CreateDialog की स्क्रिप्ट निर्माण प्रक्रिया को बदलना शामिल होगा ...

1. नोड की अंतर्निहित स्क्रिप्ट को यह तय करने दें कि नोड को इंस्टाल किया जा सकता है या नहीं (सार)।
2. अंतर्निहित नोड प्रकार बनाएं।
3. कस्टम स्क्रिप्ट को नोड की backup_script संपत्ति के रूप में सेट करें (स्क्रिप्टिंग एपीआई के संपर्क में नहीं)।
4. नोड के अपने Object कोड को backup_script को ऑब्जेक्ट पर आधिकारिक script संपत्ति के रूप में देखने के लिए हर किसी को बरगलाने के कार्य को संभालने दें।
5. संपादक आइकन के लिए मेटाडेटा अपडेट करें
6. संक्षिप्त विवरण के लिए मेटाडेटा अपडेट करें(?)

...के बजाए...

1. अंतर्निहित नोड बनाएं।
2. कस्टम प्रकार की स्क्रिप्ट को script संपत्ति के रूप में संलग्न करें।
3. कस्टम संपादक आइकन के लिए मेटा डेटा अपडेट करें।

मल्टीस्क्रिप्ट को इस साल दूसरी बार जोड़ा गया था और इसे फिर से मारना आसान था (कई मुद्दों को उठाता है)।

मैं सहमत हूँ। मुझे लगता है कि इस बिंदु पर मल्टीस्क्रिप्टिंग ऑब्जेक्ट्स एक बुरा विचार होगा (और वैसे भी वास्तव में इसकी आवश्यकता नहीं है)। मैं यही सुझाव नहीं दे रहा हूं। सार्वजनिक दृश्य में, Object में अभी भी केवल 1 स्क्रिप्ट होनी चाहिए, लेकिन मैं एक बैकअप स्क्रिप्ट उपलब्ध होने की अनुशंसा कर रहा हूं जो स्क्रिप्ट होने की भूमिका लेता है (इसलिए खुद को script संपत्ति के लिए असाइन करता है) जब भी मुख्य script संपत्ति को शून्य/अनलोड आदि पर सेट किया जाता है। यह हमें ऑब्जेक्ट क्लास की ओर कोडबेस के इंटरफ़ेस को बदले बिना "कस्टम प्रकार" का अधिक प्रभावी ढंग से समर्थन करने की अनुमति देगा। इसके बाद हमारे पास इस बैकअप स्क्रिप्ट प्रॉपर्टी के लिए एक समर्पित सेटर/गेटर हो सकता है जो कोड की अनुमति देता है (जैसे कि CreateDialog में कस्टम टाइप स्क्रिप्ट असाइन करने वाला कोड) इसके अस्तित्व को जोड़ने या हटाने की अनुमति देता है। इस तरह, यह script संपत्ति के काम करने के तरीके में एक ऑप्ट-इन संशोधन है और इसके परिणामस्वरूप इंजन में तुलनात्मक रूप से कम आवश्यक परिवर्तन होंगे।

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

क्या केवल "बदलें और इनहेरिट स्क्रिप्ट" संपादक टूल को जोड़ना आसान और अधिक पारदर्शी नहीं है? मेरा मतलब है, यह केवल एक समस्या है क्योंकि जब हम एक एडन नोड बनाते हैं, तो हम उम्मीद करते हैं कि यह स्क्रिप्ट रहित होगा - लेकिन एडऑन नोड्स वास्तव में केवल अनुकूलित नोड्स हैं जिन्हें आप नोड ट्री बनाएं में जोड़ रहे हैं, और उपयोगकर्ता को यह पता होना चाहिए। यूएक्स परिप्रेक्ष्य से (हालांकि मैं कोई विशेषज्ञ नहीं हूं), मुझे नहीं लगता कि हमें सुविधा के लिए पारदर्शिता का त्याग करना चाहिए।

@MarianoGnu @henriquelalves उनमें से कोई भी वास्तव में वही नहीं है। "कस्टम प्रकार" का निहितार्थ यह है कि आप एक इन-इंजन नोड प्रकार का अनुकरण कर रहे हैं। इसका मतलब यह होगा कि स्क्रिप्ट को ही हटाया नहीं जा सकता। यह जिस तरह से नोड में काम करता है वह अंतर्निहित है, ठीक उसी तरह जैसे आप एक Node2D के Node2D-ness को निकालने में सक्षम नहीं होंगे ताकि यह एक शुद्ध Node की तरह काम कर सके।

ऊपर दिए गए एकियन की लोकप्रिय अपवोट पोस्ट में समान विवरण शामिल हैं:

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

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

वास्तव में, सामग्री को gdscript_parser और अन्य स्क्रिप्टिंग सामग्री से एक्सेस करने के लिए, यह सुनिश्चित करना सबसे अच्छा हो सकता है कि कस्टम प्रकार की जानकारी केवल EditorNode::get_editor_data().get_custom_types() के बजाय ClassDB सिंगलटन में शामिल है मॉड्यूल की उस जानकारी तक पहुंच नहीं होगी, लेकिन वास्तव में उस तक पहुंच होनी चाहिए ।

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

@willnationsdev मैं देख रहा हूँ, मैं पूरी तरह से इन-इंजन नोड्स के रूप में व्यवहार किए जाने वाले कस्टम-प्रकारों से सहमत नहीं हूँ। मेरे लिए संपादक एडॉन्स की 'शक्तिशालीता' इस बात पर है कि कस्टम नोड्स और संपादक टूल का "पैक" बनाना और इसे जीथब के माध्यम से साझा करना कितना आसान है; वे सभी उपकरण और नोड्स, वास्तव में, केवल दृश्य और स्क्रिप्ट हैं जिन्हें आप कॉपी-पेस्ट कर सकते हैं, लेकिन गोडोट इसे सुविधाजनक बनाने के लिए एडऑन एपीआई प्रदान करता है। जब मैंने पहली बार इसका इस्तेमाल किया तो मुझे भी एडॉन्स के स्क्रिप्ट रहित होने की उम्मीद थी, लेकिन केवल इसलिए कि इंजन खुद ऐसा लग रहा था कि यह उन्हें इन-इंजन नोड्स के रूप में मान रहा है, और यह एक यूएक्स समस्या है, आर्किटेक्चरल नहीं। मुझे लगता है कि यह सही होगा:

1. नोड ट्री बनाएं में कस्टम-प्रकार एक अलग रंग के साथ दिखाता है (स्पष्ट रूप से दर्शाता है कि वे कस्टम-प्रकार हैं)।
2. जब आप उन्हें अपने दृश्य में जोड़ते हैं, तो स्क्रिप्ट आइकन होता है, लेकिन थोड़ा पारदर्शी होता है (यह दर्शाता है कि उनके पास एक डिफ़ॉल्ट स्क्रिप्ट है, लेकिन इसे प्रतिस्थापित किया जा सकता है)। स्क्रिप्ट आइकन पर क्लिक करने से संपादक पर कस्टम-प्रकार की स्क्रिप्ट दिखाई देगी।
3. कस्टम-प्रकारों पर "स्क्रिप्ट जोड़ना" बटन कस्टम-प्रकार की स्क्रिप्ट के साथ "इनहेरिट्स" विकल्प को स्वतः भर देगा।

फिर से, मैं निश्चित रूप से कोई विशेषज्ञ नहीं हूं, इसलिए कस्टम-प्रकार की मेरी मूल धारणा! = इन-इंजन नोड्स गलत हो सकते हैं; इसके अलावा, आपका समाधान सबसे स्पष्ट है जो मैंने इस धागे पर देखा है, इसलिए मैं पूरी तरह से समझता हूं कि क्या गोडोट विकास इस तरह से होता है।

संपादित करें: मैंने इसे फिर से पढ़ा, और मेरा "समाधान" मूल रूप से आपका पहला 6 समाधान चरण है, हाहा।

@henriquelalves @MarianoGnu मुझे लगता है कि उनमें से एक मिश्रण निश्चित रूप से आवश्यक होगा। कस्टम टाइप क्लास को ClassDB में जोड़ा जाना एक आवश्यक imo है। वास्तव में आपको हेनरिक के तीनों सुझावों से प्यार है। विशेष रूप से विचार 2 (मेरे अलग कस्टम-प्रकार के आइकन सुझाव से बहुत बेहतर)। और मैं आपसे सहमत हूं कि हमें यह सुनिश्चित करने की आवश्यकता है कि "कस्टम प्रकार क्या हैं" कुछ हद तक पारदर्शी रहे। मुझे लगता है कि एक संतुलन बनाए रखने की जरूरत है: लोगों को यह समझने में सक्षम होना चाहिए कि क्या कुछ एक कस्टम प्रकार है और इसका क्या मतलब है, लेकिन हमें कस्टम प्रकारों को इंजन प्रकारों की तरह महसूस करने के लिए जितना हो सके उतना करना चाहिए।

@willnationsdev मैंने इसे एसेटलिब से लिया, कस्टम नोड के कोड को "आधार" स्क्रिप्ट में स्थानांतरित कर दिया:
Collision_path_2d-1-modified.zip

उस पर जो तात्कालिक मुद्दा मैं देख रहा हूं वह यह है कि प्लगइन स्क्रिप्ट को लोड करता है, और वह स्क्रिप्ट अद्वितीय है, अगर मैं एक और कस्टम नोड जोड़ता हूं, तो इसमें _the वही_ स्क्रिप्ट होगी।

फिर, उस मामले में प्लगइन के लिए स्क्रिप्ट प्रतिस्थापन का क्या अर्थ है? (शायद कुछ नहीं, मुझे यकीन नहीं है)।

यदि स्क्रिप्ट को बदलने में कोई समस्या नहीं है (कुछ मामलों में टूल मोड खुश नहीं हो सकता है), कस्टम नोड्स के लिए मेनू उस प्रतिस्थापन प्रक्रिया को करने के लिए "कस्टम स्क्रिप्ट का विस्तार करें" की प्रविष्टि जोड़ सकता है।

@ henriquelalves @ eon-s मुझे लगता है कि हम वही चीजें सोच रहे हैं। मैं इसके साथ बोर्ड पर हूं क्योंकि यह किसी भी चीज़ से अधिक यूएक्स मुद्दा है। अब तक मैं इस दृष्टिकोण के लिए आंशिक हूं क्योंकि मुझे लगता है कि यह चीजों को यथासंभव सरल रख रहा है, जो हमेशा अच्छा आईएमओ है।

यदि स्क्रिप्ट को बदलने में कोई समस्या नहीं है (कुछ मामलों में टूल मोड खुश नहीं हो सकता है), कस्टम नोड्स के लिए मेनू उस प्रतिस्थापन प्रक्रिया को करने के लिए "कस्टम स्क्रिप्ट का विस्तार करें" की प्रविष्टि जोड़ सकता है।

मुझे लगता है कि चूंकि विस्तारित स्क्रिप्ट को प्लगइन स्क्रिप्ट से विरासत में मिला है, इसलिए इसे बदलने से कोई समस्या नहीं होगी। लेकिन, फिर से, मैं कोडबेस से बहुत परिचित नहीं हूं। वैसे भी, मैंने अपने 2 सेंट दिए हैं, मैं इसे यहां से असली देवों पर छोड़ दूंगा;)

@willnationsdev क्षमा करें, मैं अमूर्त सामान के बारे में मिश्रित हो गया हूं। मेरे "अमूर्त" आधार वर्गों में बस _init() में एक प्रिंट स्टेटमेंट है, मुझे यह बताने के लिए कि क्या मैंने इसे दुर्घटना से तुरंत चालू कर दिया है ....

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

यह दिखाने के मुद्दे के संबंध में कि यह एक "कस्टम" नोड है, मैं प्रस्ताव करता हूं कि नोड में "शो इन हेल्प" के ऊपर इंस्पेक्टर के ड्रॉपडाउन में एक प्रविष्टि है जो ऑब्जेक्ट की मूल स्क्रिप्ट फ़ाइल दिखाती है। उपयोगकर्ता और डेवलपर दृष्टिकोण से, आपको पता होना चाहिए कि यह केवल इसका उपयोग करके एक कस्टम नोड है (इसे प्रोजेक्ट में और किसने जोड़ा?), और "कस्टम" नोड्स (आईएमओ) का लक्ष्य जीडीस्क्रिप्ट में परिभाषित प्रकारों की अनुमति देना है जो अप्रभेद्य हैं अंतर्निर्मित इंजन प्रकारों से।

@ वेब-ईवर्क्स मैं वास्तव में इस पर काम कर रहा हूं (इस क्षण में) और मुझे इसका एक अच्छा हिस्सा मिल गया है (हालांकि अभी भी जाने के कुछ तरीके हैं)। मैंने ऑब्जेक्ट क्लास में एक बैकअप स्क्रिप्ट सेटअप की है और नए एपीआई का उपयोग करने के लिए EditorPlugin विधियों को अपडेट करने के साथ-साथ ClassDB में कस्टम प्रकारों के लिए स्टोरेज बनाया है। अभी भी संबंधित ClassDB फ़ंक्शंस (जैसे can_instance और get_parent_class , आदि) को अपडेट करना है और सभी संपादक / CreateDialog सामान को अपडेट करना है।

@willnationsdev यह ध्यान दिया जाना चाहिए कि क्लासडीबी में पंजीकरण करने का मतलब यह भी है कि प्लगइन बनाने वाले लोगों को टकराव को रोकने के लिए अपनी कक्षाओं को उपसर्ग करना चाहिए ^^"

@Zylann हाँ, यह आवश्यक होगा, दुर्भाग्य से।

इस बिंदु पर मुझे लगता है कि मैंने अधिकांश बाइंडिंग और मूल परिवर्तनों को सुलझा लिया है। यह अभी संपादक, CreateDialog, और EditorHelp / DocData कक्षाओं (और GDScript कंपाइलर) को अपडेट करने की बात है।

जैसा कि मैंने पहले उल्लेख किया है .. मुझे अभी भी नहीं लगता कि प्रस्तावित समाधान अच्छा है।
कुछ ऐसा करने का प्रयास करने से पहले कृपया मेरे साथ जांचें जो सबसे अधिक संभावना होगी
अस्वीकार कर दिया।

7 फरवरी, 2018 20:05 को, "विल नेशंस" नोटिफिकेशन @github.com ने लिखा:

@Zylann https://github.com/zylann हाँ, यह आवश्यक होगा,
दुर्भाग्य से।

इस बिंदु पर मुझे लगता है कि मैंने अधिकांश बाइंडिंग और कोर को सुलझा लिया है
परिवर्तन। यह केवल Editor, CreateDialog, और . को अपडेट करने की बात है
EditorHelp / DocData कक्षाएं अब।

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

@reduz ठीक है, मैं आपके द्वारा पहले रखी गई चिंताओं को ध्यान में रखने की कोशिश कर रहा हूं।

मैं किसी भी प्रकार की मल्टी-स्क्रिप्ट प्रणाली को लागू नहीं कर रहा हूं। मैं क्लासडीबी में क्लासइन्फो ऑब्जेक्ट्स के रूप में स्क्रिप्ट को मुखौटा नहीं बना रहा हूं। मैंने अब तक जो कुछ भी किया है, वह क्लासडीबी में विरासत पदानुक्रमों में एक स्क्रिप्ट (RefPtr के माध्यम से) संलग्न करता है। जब भी नियमित स्क्रिप्ट असाइनमेंट बैकअप स्क्रिप्ट के इनहेरिटेंस पदानुक्रम का उल्लंघन करने का प्रयास करता है, तो ऑब्जेक्ट क्लास केवल "बैकअप_स्क्रिप्ट" का उपयोग करेगा।

ओह, मैं देखता हूं .. इसके लिए उपयोग का मामला क्या है?

7 फरवरी, 2018 20:32 को, "विल नेशंस" नोटिफिकेशन @github.com ने लिखा:

@reduz https://github.com/reduz ठीक है, मैं इसमें लेने की कोशिश कर रहा हूं
उन चिंताओं को ध्यान में रखें जिन्हें आपने पहले रखा था।

मैं किसी भी प्रकार की मल्टी-स्क्रिप्ट प्रणाली को लागू नहीं कर रहा हूं। मैं भी नहीं हूँ
क्लासडीबी में क्लासइन्फो ऑब्जेक्ट्स के रूप में स्क्रिप्ट को मुखौटा बनाना। मेरे पास सब कुछ है
इस प्रकार अब तक विरासत में एक स्क्रिप्ट (RefPtr के माध्यम से) संलग्न है
ClassDB में पदानुक्रम। ऑब्जेक्ट क्लास केवल कभी भी a . का उपयोग करेगा
"बैकअप_स्क्रिप्ट" जब भी नियमित स्क्रिप्ट असाइनमेंट उल्लंघन करने का प्रयास करता है
बैकअप स्क्रिप्ट के वंशानुक्रम पदानुक्रम पर।

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

उपयोग का मामला तब होता है जब कोई संपादक प्लगइन का उपयोग करके इंजन में एक नए प्रकार के नोड को पेश करना चाहता है, लेकिन वे उस नोड के स्क्रिप्टेड प्रकार को संपादन योग्य नहीं चाहते हैं (वे चाहते हैं कि इन-इंजन प्रकार की नकल करने के लिए इसके साथ बातचीत हो ) इसलिए, उदाहरण के लिए, यदि मैं केवल बैकअप स्क्रिप्ट वाले नोड पर get_script() का प्रयास करता हूं, तो यह शून्य हो जाएगा। अगर मैं कोशिश करता हूं set_script(null) , तो स्क्रिप्ट बैकअप स्क्रिप्ट पर सेट हो जाती है। यदि मैं set_script(a_script) का प्रयास करता हूं, तो यह केवल स्क्रिप्ट को सफलतापूर्वक असाइन करेगा यदि नई स्क्रिप्ट बैकअप स्क्रिप्ट के वंशानुक्रम पदानुक्रम में है।

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

मुझे यह स्वीकार करना होगा कि मुझे वास्तव में इसका लाभ नहीं दिख रहा है, तो फिर क्या है
विशिष्ट उपयोग के मामलों के बारे में आप सोच रहे हैं?

7 फरवरी, 2018 20:46 को, "विल नेशंस" नोटिफिकेशन @github.com ने लिखा:

उपयोग का मामला तब होता है जब कोई नए प्रकार के नोड को पेश करना चाहता है
संपादक प्लगइन का उपयोग करने वाला इंजन, लेकिन वे स्क्रिप्टेड प्रकार की इच्छा नहीं रखते हैं
वह नोड संपादन योग्य होना चाहिए (वे चाहते हैं कि इसके साथ बातचीत एक नकल करने के लिए)
इन-इंजन प्रकार)। इसलिए, उदाहरण के लिए, यदि मैं नोड पर get_script() करने का प्रयास करता हूं
केवल इसकी बैकअप स्क्रिप्ट के साथ, फिर यह अशक्त हो जाएगा। अगर मैं करने की कोशिश करता हूँ
set_script(null), फिर स्क्रिप्ट बैकअप स्क्रिप्ट पर सेट हो जाती है। अगर मुझे
set_script(a_script) करने का प्रयास करें, तो यह केवल सफलतापूर्वक असाइन करेगा
स्क्रिप्ट यदि नई स्क्रिप्ट बैकअप के वंशानुक्रम पदानुक्रम में है
स्क्रिप्ट

UX के लिए, मैं संपादक में स्क्रिप्ट आइकन को a . के रूप में प्रदर्शित करने की योजना बना रहा हूं
पारदर्शी आइकन यदि केवल बैकअप स्क्रिप्ट मौजूद है। उस मामले में,
एक स्क्रिप्ट जोड़ने के लिए बटन अभी भी एक के बजाय एक "एक स्क्रिप्ट जोड़ें" बटन होगा
"स्क्रिप्ट हटाएं" बटन, और उस पर क्लिक करने पर नाम के साथ टेक्स्ट पहले से भर जाएगा
प्रकार का (हालाँकि, मुझे इसे स्क्रिप्ट पथ के साथ पहले से भरने की आवश्यकता हो सकती है
यदि उपयोगकर्ता स्क्रिप्ट के प्रकार को GDScript/VisualScript से दूर बदलता है,
आदि।)। एक बार एक अलग स्क्रिप्ट सौंपे जाने के बाद, पारदर्शी आइकन
फिर से अपारदर्शी हो जाएगा। किसी भी स्थिति में स्क्रिप्ट आइकन पर क्लिक करने से
आपको सक्रिय स्क्रिप्ट स्रोत कोड पर ले जाता है (बैकअप स्क्रिप्ट स्रोत कोड if
कोई अन्य लिपि मौजूद नहीं है)।

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

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

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

मुझे लगता है कि यहां जो बात विफल हो रही है, वह यह है कि लक्ष्य कस्टम नोड्स को इंजन नोड्स की तरह व्यवहार करना है, बिना इंजन मॉड्यूल लिखे और इसके खिलाफ संकलन करना।

यह सुधार आवश्यक रूप से एक विशिष्ट विशेषता (हालांकि कई हैं) द्वारा संचालित नहीं है, बल्कि "वर्तमान तरीका पिछड़ा, कमजोर और थकाऊ है" के तर्क से प्रेरित है। यदि पूरी तरह से लागू किया जाता है, तो यह प्रणाली इंजन को फिर से संकलित किए बिना GDScript / GDNative से इंजन के अंतर्निर्मित प्रकारों को विस्तारित करने की एक अत्यंत शक्तिशाली विधि की अनुमति देगी। एक डिजाइन के दृष्टिकोण से, यह वस्तुतः वर्तमान प्रणाली पर एक सीधा सुधार है।

यदि आप इन सब के बाद किसी विशेष उपयोग के मामले को चाहते हैं: संपूर्ण प्लगइन / AssetLibrary पारिस्थितिकी तंत्र ।
यही वह दायरा है जो इस बदलाव से लाभान्वित होता है।

ठीक है, तो यहाँ एक स्पष्ट उदाहरण है:

मेरे पास एक प्लगइन है जिस पर मैं काम कर रहा हूं, godot-skills , जो विभिन्न प्रकार के नए नोड्स का परिचय देता है:

प्रभाव: एक फ़नकार की अधिसूचना
लक्ष्यकर्ता: समान, लेकिन बस अन्य नोड्स को ढूंढता है और एकत्र करता है
कौशल: नोड्स को खोजने और उन सभी पर प्रभाव लागू करने के लिए टारगेटर्स और इफेक्ट्स के पदानुक्रम को जोड़ती है
स्किलयूजर: कई स्किल्स का "मालिक" है

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

वर्तमान वर्कफ़्लो के लिए आवश्यक है कि उपयोगकर्ता...

1. एक कस्टम प्रकार नोड जोड़ें
   2ए. इससे जुड़ी स्क्रिप्ट को हटा दें और एक स्क्रिप्ट जोड़ें बटन पर क्लिक करें या
   2बी. नोड पर स्क्रिप्ट गुण सेट करें
2. संवाद विंडो में खोजें जहां EditorPlugin कस्टम प्रकार की स्क्रिप्ट रख रहा है जिसे आप प्राप्त करना चाहते हैं।

यह प्रणाली आपको इन सभी को बस के साथ बदलने की अनुमति देगी:

1. एक कस्टम नोड प्रकार जोड़ें।
2. स्क्रिप्ट के रूप में जोड़ें (जो स्वचालित रूप से कस्टम प्रकार की स्क्रिप्ट प्राप्त करना शुरू कर देता है)

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

ठीक है, तो एक अद्यतन। मेरे पास वर्तमान में निम्नलिखित है।

• ClassDB अब कस्टम प्रकारों को सीधे जोड़ और हटा सकता है।
• EditorPlugin में समान कस्टम प्रकार विधियां हैं जो न केवल कस्टम प्रकार, बल्कि अन्य संपादक-संबंधित डेटा जैसे आइकन को जोड़ती और हटाती हैं। ये विधियां एक नए सिग्नल से जुड़ी हैं जो कि जब भी EditorPlugin को सक्रिय/निष्क्रिय टॉगल किया जाता है तो उत्सर्जित होता है।
• GDScripts अब स्क्रिप्ट से इनहेरिट करने के लिए कस्टम प्रकारों के नामों से सीधे ठीक से इनहेरिट कर सकता है।
• जब वर्तमान स्क्रिप्ट नोड के कस्टम प्रकार की स्क्रिप्ट से मेल खाती है, तो दृश्य डॉक एक पारदर्शी स्क्रिप्ट आइकन बनाएगा। इस पर क्लिक करने पर एडिटर में कस्टम टाइप स्क्रिप्ट खुल जाएगी। इस स्थिति में, "एक स्क्रिप्ट जोड़ें" बटन के बजाय "एक स्क्रिप्ट हटाएं" प्रदर्शित होता है। यदि चयनित है, तो यह बटन "इनहेरिट्स" फ़ील्ड को कस्टम प्रकार की स्क्रिप्ट (यदि गैर-शून्य) के नाम से भर देगा।
• किसी स्क्रिप्ट को निकालने का कोई भी प्रयास कस्टम प्रकार की स्क्रिप्ट को स्क्रिप्ट मान के रूप में फिर से असाइन करने का कारण बनेगा। जैसे, स्क्रिप्ट को हटाने के लिए, आपको पहले कस्टम प्रकार स्क्रिप्ट मान को set_custom_script(RefPtr()); से साफ़ करना होगा।
• एक नोड बनाएँ संवाद कस्टम प्रकारों के लिए इनहेरिटेंस संबंध और सार नोड्स को ठीक से दिखाता है।
• project.godot फ़ाइल सभी कस्टम प्रकारों से भरी हुई है ताकि निष्पादित गेम उन्हें बाकी गेम शुरू होने से पहले main.cpp में सेट कर सकें।

शेष कार्यों को पूरा किया जाना है...

• उपयोगकर्ताओं को कस्टम प्रकारों के लिए कक्षा API दस्तावेज़ जेनरेट करने दें।
• एक अलग बग को पूरी तरह से ठीक करें जो उपयोगकर्ताओं को script_create_dialog.cpp में इनहेरिट्स फ़ील्ड को संपादित करने से रोकता है।
• GDScript वैश्विक मानचित्र/सरणी से कस्टम प्रकारों को गतिशील रूप से जोड़ने और निकालने का तरीका खोजें *
• VisualScript में कस्टम प्रकार का समर्थन लागू करें

* वास्तव में इस बारे में मेरे कुछ प्रश्न हैं।

सबसे पहले, मैं केवल add_global_constant / _add_global को gdscript_compiler.cpp फ़ाइल में GDScriptLanguage वर्ग से ग्लोबल्स को हटाने के किसी भी साधन के बिना देखता हूं। जब भी सिंगलेट जोड़े या हटाए जाते हैं तो क्या यह पूरी तरह से फिर से शुरू हो जाता है? वैश्विक पहचानकर्ताओं को गतिशील रूप से कैसे संपादित किया जाता है? ऐसा इसलिए होगा ताकि उपयोगकर्ता स्क्रिप्ट को पहले एक चर में लोड किए बिना MyNode.static_func() कर सकें।

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

extends Node # an in-engine type.
extends \ # triggers an error if left alone, but would prompt a dropdown of the plugin API names for auto-completion as well as the names of any scripts in the current project that are not part of a plugin.
extends \MyPlugin\ # triggers an error if left alone, but would prompt a dropdown of the scripted types that exist for the plugin
extends \MyNode # extends my_node.gd somewhere in res://
extends \MyPlugin\MyNode # extends my_node.gd somewhere in res://addons/[my_plugin_something?]/

func _ready():
    print(\MyNode.CONSTANT) # would print CONSTANT in the current project's my_node.gd script

वैसे भी यह सब ^ इस समय सिर्फ विचारों को इधर-उधर फेंका जा रहा है। यदि नेमस्पेसिंग शुरू की गई थी, तो आप EditorNode resource_saved सिग्नल का उपयोग करके स्क्रिप्ट को स्वचालित रूप से उनके फ़ाइल नाम के आधार पर नाम से जोड़ सकते थे। वे अनिवार्य रूप से कस्टम प्रकार नहीं होंगे (इस अर्थ में कि आप ऑब्जेक्ट से स्क्रिप्ट को नहीं हटा सकते हैं), लेकिन वे अकेले नाम से पहुंच योग्य होंगे जो बेहद उपयोगी और सहज ज्ञान युक्त होगा। शीर्ष पर एक नामस्थान शीर्षक प्रदान करके स्क्रिप्ट डिफ़ॉल्ट ऑटो-नामकरण ( filename.capitalize().replace(" ", "") ?) को भी ओवरराइड कर सकती है, उदाहरण के लिए \MyPlugin\mynode । अब अचानक "\MyPlugin\mynode" उस स्क्रिप्ट के लिए एक वैश्विक पहचानकर्ता है।

यहाँ मेरी अब तक की प्रगति का एक अंश है।

@willnationsdev कृपया \ चयन न करें, यह पहले से ही भागने और मल्टीलाइन के लिए उपयोग किया जाता है। . , : या :: बेहतर दिखें।

@Zylann मैंने परियोजना में जोड़े जाने वाले किसी भी नोड के लिए उपसर्ग के रूप में सीमांकक का उपयोग करने की योजना बनाई है। तो फिर, उदाहरण के लिए, res://container.gd पर एक स्क्रिप्ट वास्तविक Container वर्ग के साथ टकराव नहीं करना चाहेगी। यदि हम एक अवधि (।) का उपयोग करते हैं, तो यह इस तरह दिख सकता है।

var engine_type = Container.new()
var script_type = .Container.new()
var plugin_script_type = .MyPlugin.Container.new()

किसी को उस तरह के प्रारूप पर आपत्ति है?

संपादित करें:

यह व्युत्पन्न वर्ग कार्यों के भीतर मुद्दों में चल सकता है, हालांकि उनके भीतर माता-पिता की विधि को कॉल करें:

func _virtual_method():
    ._virtual_method() # parent stuff
    # my stuff

हम्म ... क्या यह स्थिरांक और/या चर के लिए कोई समस्या उत्पन्न करता है? यदि नहीं, तो हम केवल यह मान सकते हैं कि कोष्ठक का अर्थ है कि यह एक सुपर फ़ंक्शन है और अन्यथा यह एक संभावित नामांकित पहचानकर्ता है।

ईमानदारी से, मैं अभी के लिए नेमस्पेसिंग पर रोक लगाऊंगा - इसे बाद में पेश किया जा सकता है, और मैं वर्तमान प्रणाली को जल्द से जल्द प्राप्त करना चाहूंगा। हमें स्वचालित नाम पंजीकरण के लिए एक _really_ सुविचारित प्रणाली की भी आवश्यकता होगी, जो संभवत: संपूर्ण एडऑन संगठनात्मक संरचना के एक पुनर्कार्य के लिए विस्तारित है, जो कि उचित मात्रा में काम है और इस मुद्दे के दायरे से बाहर है।

व्यक्तिगत रूप से, मैं चाहता हूं कि 'स्वतः पंजीकृत' स्क्रिप्ट का नाम फ़ाइल में एक घोषणा द्वारा नियंत्रित किया जाए, अर्थात

register <NAME> extends <PARENT>

या मौजूदा extend <NAME> प्रोलॉग पर आधारित समान सिंटैक्स जो पहले से ही GDScript के लिए मौजूद है।

संपादित करें: मैं यह भी पूछना चाहता था कि माता-पिता (स्थानिक कहें) से प्राप्त होने वाली स्क्रिप्ट को एक कस्टम बच्चे (स्प्राइट 3 डी-> कस्टम टाइप कहें) को कैसे संभाला जा रहा है? यह पहले से ही इंजन प्रकारों के लिए काम करता है, और कस्टम प्रकार से प्राप्त होने वाली असाइन की गई स्क्रिप्ट को प्रतिबंधित करना बहुत अच्छा काम नहीं करेगा।

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

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

@Zylann मैंने अपने कांटे में जो किया है वह custom_script Object के लिए संपत्ति बना रहा है। यह केवल तभी महत्वपूर्ण हो जाता है जब इसे कोई मान असाइन किया जाता है, लेकिन यदि इसे कोई स्क्रिप्ट असाइन की जाती है , तो यह बैकअप स्क्रिप्ट/बाधा के रूप में कार्य करती है कि मुख्य script संपत्ति क्या हो सकती है। समाशोधन script इसे custom_script पर सेट कर देगा, और यदि आप Script से script को एक नया असाइन करते हैं, तो इसे केवल तभी सफलतापूर्वक असाइन किया जाएगा जब Script उदाहरण custom_script से निकला है। और यह सब पर्दे के पीछे Object द्वारा प्रबंधित किया जाता है, जहां तक ​​​​इंजन का संबंध है, Object s में अभी भी केवल 1 वास्तविक स्क्रिप्ट है।

ClassDB सामग्री में कस्टम प्रकारों का एक द्वितीयक मानचित्र होता है जो पंजीकृत हो जाता है, स्क्रिप्ट को स्वयं मैप करता है और कुछ अन्य जानकारी आपके द्वारा निर्दिष्ट नाम पर रखता है। यह तब संबंधित विरासत विधियों ( get_class_list , is_parent_class , get_parent , आदि) के साथ उस नाम और उसकी विरासत पदानुक्रम प्रदान करता है। और यह कुछ विधियों के लिए ऑप्ट-इन फ़्लैग के रूप में किया जाता है। get_class_list अब एक बूल फ्लैग लेगा जहां इसमें केवल कस्टम प्रकार शामिल हैं यदि आप दूसरे पैरामीटर के रूप में true पास करते हैं। इस प्रकार यह बाकी इंजन के साथ संगतता को तोड़ने से रोकता है।

@willnationsdev तो, एक ऐसी प्रणाली के साथ जो स्क्रिप्ट को एडॉन्स को बिल्टिन कक्षाओं की तरह प्रथम श्रेणी के नागरिक माना जाता है, और "पुराने स्कूल" तरीके को छोड़ देता है?

आह। जिस तरह से स्क्रिप्ट वर्तमान में काम करती है वह यह है कि आप extends Node पर एक VBoxContainer $ पर एक स्क्रिप्ट डाल सकते हैं, और यह अभी भी ठीक काम करता है। यदि वर्तमान कार्यान्वयन कस्टम प्रकारों के लिए उस व्यवहार को तोड़ता है, तो कुछ समस्याएं होंगी - क्या इंजन प्रकार से सीधे प्राप्त होने वाली 'सामान्य' स्क्रिप्ट होने पर कस्टम स्क्रिप्ट के व्यवहार को रखने का कोई तरीका है?

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

@ वेब-ईवर्क्स सुनिश्चित नहीं है कि मैं यहीं अनुसरण कर रहा हूं, लेकिन...

कस्टम प्रकार विशेष रूप से वंशानुक्रम के लिए इन-इंजन प्रकारों की तरह काम करते हैं। इसलिए यदि आप एक कस्टम प्रकार से विस्तार करते हैं, तो यह ऐसा होगा जैसे आप इन-इंजन पदानुक्रम की एक पूरी तरह से अलग शाखा से विस्तार कर रहे हैं। भूतपूर्व। अगर मैं एक कस्टम प्रकार MyNode बनाता हूं जो Node #$ का विस्तार करता है, तो मैं उस स्क्रिप्ट को VBoxContainer पर नहीं डाल पाऊंगा जैसे मैं Node2D नहीं डाल सकता VBoxContainer । यह वास्तव में इच्छित व्यवहार होगा।

अब, नेमस्पेसिंग अवधारणा के साथ, आपने आदर्श रूप से उन लिपियों का नाम दिया होगा जो कस्टम प्रकार नहीं हैं। तो, उस स्थिति में, मैं एक स्क्रिप्ट बना सकता हूं जो Node तक फैली हुई है और इसे Node , VBoxContainer और MyNode पर रखती है। क्या इसका कोई मतलब है?

तो मैं जो कह रहा हूं वह यह है कि यदि आप एक कस्टम प्रकार MyNode इनहेरिट करते हैं तो MeshInstance कहें, उदाहरण के लिए संपादक में इसका एक नोड, और Spatial विरासत में मिली एक स्क्रिप्ट जोड़ने का प्रयास करें MyNode टाइप किए गए नोड के लिए, क्या यह ठीक से काम करेगा? यह 'इंजन' नोड्स के साथ ठीक से काम करता है, और यही वह व्यवहार है जिसका हमें अनुकरण करने की आवश्यकता है।

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

@ वेब-ईवर्क्स हाँ, यह काम करेगा। ClassDB के custom_types मानचित्र में प्रत्येक "प्रथम स्तर" प्रविष्टि को $#$2 classes #$ मानचित्र में एक प्रकार से वापस लिंक करना होगा, अन्यथा एक त्रुटि होती है और कस्टम प्रकार है नहीं बनाया। यह सुनिश्चित करता है कि कस्टम प्रकारों से वापस इंजन प्रकारों में Object तक जाने पर वंशानुक्रम की श्रृंखला संरक्षित है।

@willnationsdev बस सुनिश्चित करने के लिए - यदि आप _ready में MyNode $ विधि जोड़ते हैं, और आपकी उपयोगकर्ता स्क्रिप्ट में एक तैयार नोड जो स्थानिक से प्राप्त होता है, तो इसे Spatial._ready(), MeshInstance._ready(), MyNode._ready(), script._ready() कहा जाएगा ? (या जो भी ऑर्डर _ready में भेजा जाता है।)

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

@reduz यह ऐसा कुछ नहीं है जिसे अकेले संपादक UI से हल किया जा सकता है। नहीं यदि आप ऑब्जेक्ट पर स्क्रिप्ट के उपयोगकर्ताओं के हेरफेर को नियंत्रित करना चाहते हैं। मुझे ऐसा लगता है कि यह एक ऐसी विशेषता है जिसे बहुत से लोग सेटअप करना चाहते हैं।

क्या आप सुझाव दे रहे हैं कि gdscript_compiler को संपादकडेटा में सामग्री का संदर्भ देना चाहिए ताकि स्क्रिप्टेड प्रकारों के लिए नए वैश्विक पहचानकर्ता सेट किए जा सकें, बजाय इसके कि उन सभी को ClassDB में ट्रैक किया जाए और ClassDB को इंजन में सभी इनहेरिटेंस जानकारी का प्रबंधन करने की अनुमति दी जाए?

निश्चित रूप से इसका एक हिस्सा है जिसे संपादक UI के दृष्टिकोण से हल करने की आवश्यकता है, लेकिन एक हिस्सा ऐसा भी है जिसे कोर में हल करने की आवश्यकता है। इंजन में कस्टम प्रकार जोड़ना, ClassDB के दृष्टिकोण से _actual_ प्रकार, एक बहुत ही शक्तिशाली और अंततः आवश्यक विशेषता है। जहाँ तक भ्रमित करने की बात है, मैं अभी भी यह मानता हूँ कि यह वर्तमान प्रणाली की तुलना में अधिक भ्रमित करने वाला नहीं है, और शायद बहुत कम है।

@ वेब-ईवर्क्स मैं सहमत हूं। संपादक में विरासत डेटा को ट्रैक करने के लिए वास्तव में मेरी राय में और अधिक भ्रमित करने वाला होगा। और इसका परिणाम अजीब तरह से होगा क्योंकि एक बार जब आप संपादक के बिना गेम चलाते हैं तो उस प्रकार की जानकारी मौजूद नहीं होगी (यही कारण है कि मुझे वास्तव में इसे लोड करने के लिए project.godot में जानकारी लोड करना शुरू करना पड़ा था। ClassDB स्टार्टअप पर। कोई EditorPlugins कस्टम प्रकार जोड़ने के कारण GDScripts दृश्य को चलाने के दौरान संकलन को विफल कर रहा था)।

@ वेब-ईवर्क्स और आपके पहले के प्रश्न का उत्तर देने के लिए, हाँ, यह ठीक से काम करता है।

मेरे परीक्षण परिदृश्य में, मेरे पास Node.gd है जो GDSkillsEffect > GDSkillsAPI > Node का विस्तार कर रहा है, और प्रत्येक स्क्रिप्ट में लागू _ready विधियां उचित रूप से ट्रिगर हो जाती हैं आदेश: एपीआई, प्रभाव, Node.gd.

मैं वर्तमान में किसी प्रकार की अनंत लूप त्रुटि का अनुभव कर रहा हूं, हालांकि जब भी दो स्क्रिप्ट दोनों नाम से कस्टम प्रकार स्क्रिप्ट से प्राप्त करने का प्रयास करते हैं। भूतपूर्व। यदि Node.gd में extends GDSkillsEffect और gdskills_effect.gd में extends GDSkillsAPI है, तो gdskills_effect.gd या gdskills_api.gd को संशोधित करने और सहेजने का प्रयास संपादक को असीम रूप से "लोड" और फिर क्रैश। इस समय शायद यही मेरी सबसे बड़ी बग है।

@willnationsdev आह, नहीं, मैं Node.gd के विस्तार की बात कर रहा हूं Node , _not_ GDSkillsEffect । अगर _वह_ काम करता है, तो सब कुछ अच्छा है।

उदाहरण के लिए, यहाँ दृश्य वृक्ष का प्रतिनिधित्व है:

-> User Script:
  extends Node
  func _ready(): pass

@ वेब-ईवर्क्स आह, मैं देखता हूं कि आपका क्या मतलब है। ठीक है, यह काम करना चाहिए, लेकिन मैंने अभी इसका परीक्षण किया है और ऐसा लगता है कि Object::set_script() में मेरा तर्क किसी कारण से इसे अवरुद्ध कर रहा है, इसलिए यह एक बग है जिसे मुझे ठीक करने की आवश्यकता होगी। XD यह विफल हो रहा है क्योंकि यह पता चला है कि Node कस्टम प्रकार की स्क्रिप्ट प्राप्त नहीं करता है (जो सच है, याय), लेकिन यह उस मामले में विफल नहीं होना चाहिए, योग्य।

@ Web-eWorks जैसा कि मैंने उल्लेख किया है, यह ऐसा कुछ नहीं है जिसे ClassDB में बदलने की आवश्यकता है।

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

@willnationsdev मैं आपके प्रयास की सराहना करता हूं, लेकिन इस पर पहले से ही चर्चा नहीं हुई थी और आम सहमति यह है कि:

• प्रत्येक स्क्रिप्ट भाषा के लिए एक कस्टम प्रकार जोड़ना अलग है, इसलिए ClassDB में कुछ हैक करना, जो वास्तव में केवल C++ सामान को पंजीकृत करने के लिए है, जाने का रास्ता नहीं है।
• इस तरह की लंबाई तक जाने से पहले, हम उन मामलों के लिए UI उपयोगिता में सुधार कर सकते हैं जहां आप कस्टम नोड की स्क्रिप्ट का विस्तार करना चाहते हैं, इसलिए यह केवल सरल विरासत बनाता है।
• सामान्य तौर पर, कोने के मामलों को संभालने के लिए कोर इंजन में हैक्स जोड़ना कभी भी सही नहीं होता है। कोर को हैक-फ्री रहने की जरूरत है।

@willnationsdev संदर्भ के लिए, इंजन व्यवहार यह है कि विरासत पदानुक्रम में _something_ के बराबर या पिछले किसी भी स्क्रिप्ट को नोड में जोड़ा जा सकता है। इस प्रकार, एक स्क्रिप्ट जिसे extends Spatial को MeshInstance में जोड़ा जा सकता है, लेकिन Control या Node में नहीं जोड़ा जा सकता है, क्योंकि बाद में से कोई भी Spatial से प्राप्त या विरासत में नहीं है।

@reduz लेकिन क्या मोनो में एक नया वर्ग बनाने से इसे इंजन की विरासत पदानुक्रम में जोड़ा जाता है? या संपादक का नोड बनाएँ संवाद? शायद एक नए मुद्दे को खोलने की जरूरत है जो संक्षेप में बताता है कि इसका उद्देश्य क्या है, क्योंकि मुझे लगता है कि हम यहां उसी चीज के बारे में बात नहीं कर रहे हैं।

ClassDB संशोधनों का उद्देश्य इंजन को पुन: संकलित करने की आवश्यकता के बिना नए प्रकार के नोड्स (या संसाधन) को पंजीकृत करने की अनुमति देना है। GDScript में नए कस्टम ग्लोबल्स नहीं जोड़ने के लिए, हालांकि यह एक स्पर्शरेखा मुद्दा है जिस पर @willnationsdev उसी शाखा में काम कर रहा है।

इसका उद्देश्य हैक्स जोड़ना नहीं है, बल्कि इंजन के प्रकारों का विस्तार करने के लिए एक अच्छी तरह से डिज़ाइन किया गया _system_ बनाना है।

@ वेब-ईवर्क्स इंजन विरासत पदानुक्रम सी ++ के लिए है, स्क्रिप्ट नहीं। शुरुआत में दोनों को मिलाने की कोशिश करना वैचारिक रूप से गलत है।

हो सकता है कि गलतफहमी यह है कि नोड बनाएं संवाद ऐसा लगता है जैसे एक नया वर्ग जोड़ा गया था, इसलिए ऐसे कस्टम प्रकारों को स्पष्ट रूप से एक स्क्रिप्ट युक्त चिह्नित करना एक अच्छा विचार हो सकता है।

@ वेब-ईवर्क्स यदि आप मोनो का उपयोग कर रहे हैं, तो यह पारदर्शी रूप से दिखेगा जैसे कि एक नया वर्ग जोड़ा गया था, क्योंकि यह एक नया वर्ग है। जीडीस्क्रिप्ट के लिए, क्योंकि कक्षाएं डिफ़ॉल्ट रूप से फाइलें होती हैं, इसे इस तरह से नहीं किया जा सकता है, इसलिए इसे स्थापित करने के लिए एक समर्पित यूआई के साथ एक नया वैश्विक जोड़ना हो सकता है (जैसा कि हमारे पास सिंगलटन ऑटोलोड के लिए है) ... लेकिन यह अभी भी एक स्क्रिप्ट क्लास है, इंजन क्लास नहीं।

@willnationsdev इसमें मेरा पूरा बिंदु यह है कि मुझे लगता है कि यह गलत है कि आप इंजन में वास्तविक नई कक्षाएं जोड़ रहे हैं, क्योंकि वे नहीं हैं। यह भ्रम के लिए खुला है। यह सिर्फ एक स्क्रिप्ट के साथ एक नोड है, इसलिए स्क्रिप्ट को छिपाने के बजाय, मुझे लगता है कि बनाने के लिए सही काम इसे और अधिक दृश्यमान बनाना है।

@reduz खैर, यही बात है। नोड+स्क्रिप्ट एक सीन है। Add_custom_type तंत्र को मोनो की तरह व्यवहार करना चाहिए, एक 'नई कक्षा' दर्ज करना, भले ही यह तकनीकी रूप से किसी भी मानक से 'वर्ग' न हो। यदि क्लासडीबी को छूने की आवश्यकता के बिना ऐसा करने का कोई तरीका है, तो मैं सभी कान हूं।

इसके अलावा, @ akien-mga ने सुझाव दिया कि दृश्य ट्री व्यू में, हम कस्टम नोड्स की स्क्रिप्ट को छिपा सकते हैं, ताकि उपयोगकर्ताओं को उनके बारे में भ्रमित करने से बचने के लिए कि स्क्रिप्ट बनाई गई है और इसे गलती से संपादित किया गया है (लेकिन फिर भी इसे नीचे इंस्पेक्टर में दिखाएं) .

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

@willnationsdev मुझे एक नया, अधिक संक्षिप्त मुद्दा खोलने में कोई आपत्ति है, विशेष रूप से कार्यान्वयन के दायरे का विवरण?

@ वेब-ईवर्क्स नोड + स्क्रिप्ट एक दृश्य नहीं है, एक ट्री लेआउट में नोड्स एक दृश्य हैं। आप केवल नोड्स ही नहीं, कस्टम संसाधन प्रकार भी जोड़ सकते हैं।

और नहीं, यह एक नए वर्ग को पंजीकृत करने जैसा व्यवहार नहीं करना चाहिए। यह बहुत स्पष्ट होना चाहिए कि यह एक सी ++ वर्ग है जिसमें एक स्क्रिप्ट पहले से जोड़ी गई है।

@ वेब-ईवर्क्स हाँ, यह मेरे साथ कोई समस्या नहीं है। कृपया मेरा उल्लेख करें ताकि यदि आप करते हैं तो मुझे एक पिंग मिलती है। सुनिश्चित नहीं हैं कि क्या हमें एक अलग मुद्दे की आवश्यकता है?

इसे दूसरे नजरिए से देखें। आपका तर्क यह है कि इसे उपयोगकर्ता को ऐसा दिखाना है जैसे कि आप नए इंजन प्रकारों के साथ इंजन प्रकारों का विस्तार कर रहे थे।

मेरा दृष्टिकोण यह है कि आप इंजन प्रकारों को स्क्रिप्ट के साथ विस्तारित कर रहे हैं, न कि नए इंजन प्रकारों के साथ। और यह कि उपयोगकर्ता मूर्ख नहीं है और उसे यह जानने की जरूरत है।

@reduz मेरा मतलब नोड + स्क्रिप्ट के बारे में था कि वह तंत्र पहले से ही तत्काल दृश्यों के माध्यम से कवर किया गया था।

हो सकता है कि मैं मोनो कार्यान्वयन को गलत समझ रहा हूं, लेकिन क्या मोनो कक्षाएं अभी भी स्क्रिप्ट नहीं हैं?

@reduz मैं ज्यादातर आपके साथ सहमत हूं, जब आपने कहा था कि एक कस्टम नोड में एक स्क्रिप्ट जोड़ने से बस इसे प्राप्त करने का प्रस्ताव होगा। लेकिन आप कैसे उम्मीद करते हैं कि यह GDNative कस्टम प्रकारों के साथ काम करेगा?

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

मैं निश्चित रूप से एक वैकल्पिक विधि के लिए खुला रहूंगा। किसी भी तरह से, सबसे आसान कार्यान्वयन यह है कि ऑब्जेक्ट को कुछ तृतीय-पक्ष पंजीकरण वर्ग (चाहे वह ClassDB, ProjectSettings, EditorData, या जो और क्या जानता है) की जाँच करके स्वयं को स्क्रिप्ट असाइन करें (जैसा कि मैंने अपने कार्यान्वयन में किया है) . तब संपादक के लिए उस तीसरे पक्ष के साथ जांच करना और चीजों को अलग तरह से प्रदर्शित करना बहुत आसान हो जाता है (जैसा कि मैंने अपने कार्यान्वयन में किया है)। यह बहुत अधिक काम नहीं होगा, हालांकि मैं क्लासडीबी की तुलना में पंजीकरण को किसी अन्य संदर्भ में स्थानांतरित करने के बारे में नहीं सोचता।

^ क्या वह समझौता स्वीकार्य होगा? अन्यथा, आपको हर संभव स्थान को माइक्रोमैनेज करना होगा जिसमें ऑब्जेक्ट को तीसरे पक्ष के साथ जांच करने के लिए एक स्क्रिप्ट सौंपी जाती है। यह बहुत अधिक जटिल होगा।

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

@willnationsdev मैं समझता हूं कि आप क्या करने की कोशिश कर रहे हैं, लेकिन मुझे नहीं लगता कि इसे कभी भी साफ-सुथरा बनाया जा सकता है। यह एक ऐसी जटिलता को छिपा रहा है जिसके छिपाने का कोई कारण नहीं है, इस तरह से जो कभी भी अपेक्षित रूप से पूरी तरह से काम नहीं करेगी।

@Zylann मुझे लगता है कि यह वही है, लेकिन या तो ए) स्क्रिप्ट gdnative आंतरिक है बी) यह gdnative के लिए आंतरिक विधि का उपयोग करता है। मैं ईमानदारी से बताने के लिए इसके साथ पर्याप्त परिचित नहीं हूँ।

@reduz क्या आप कह रहे हैं कि आप वस्तुओं पर स्क्रिप्ट-आधारित बाधाओं को बनाने के किसी भी रूप की अनुमति नहीं देना चाहते हैं? क्योंकि मैं चेक लॉजिक को संपादक में ही स्थानांतरित कर सकता था और इससे आपको बाधाओं की डिज़ाइन-टाइम जाँच आसानी से मिल जाएगी (यूआई परिवर्तन, जैसा कि आप कहते हैं), लेकिन वे रनटाइम पर काम नहीं करेंगे, इसलिए लोग अभी भी संभावित रूप से होंगे एक बार खेल चलने के बाद चीजों को बदलने में सक्षम। क्या यह आपके लिए बेहतर काम करेगा? मैं अभी भी रनटाइम पर सामान की जांच करने में सक्षम होना पसंद करूंगा ...

@willnationsdev आप किस प्रकार की स्क्रिप्ट आधारित बाधाएँ करना चाहते हैं?

वही बाधाएं जो कस्टम स्क्रिप्ट प्रॉपर्टी के बारे में शुरुआत से ही रही हैं: यह लागू करना कि असाइन की गई स्क्रिप्ट किसी अन्य स्क्रिप्ट को प्राप्त करती है।

मैं दृश्य पदानुक्रम में विस्तारित स्क्रिप्ट के लिए स्क्रिप्ट आइकन को छिपाने की सिफारिश करता हूं और यदि कोई नोड के बेस क्लास को विरासत में लेने के बजाय "स्क्रिप्ट जोड़ें" बटन पर क्लिक करता है तो यह स्क्रिप्ट पर हमला करता है। यह पारदर्शी है और ClassDB के साथ खिलवाड़ करने की बिल्कुल भी आवश्यकता नहीं है

इसलिए, script_language.h में कुछ जानकारी की समीक्षा करते हुए, मुझे ऐसा लगता है कि मैं वास्तव में ClassDB में जोड़ी गई नई सामग्री को ScriptLanguage कक्षा में स्थानांतरित कर सकता हूं और एक बना सकता हूं ScriptDB सिंगलटन का प्रकार जो केवल तभी बनाया जाता है जब स्क्रिप्टिंग भाषा इसका उपयोग करने का इरादा रखती है। और क्योंकि object.cpp में पहले से ही script_language.h शामिल है, यह set_script(const RefPtr &p_script) में निम्नलिखित कार्य करने में सक्षम होगा ...

1. जांचें कि क्या p_script वास्तव में एक स्क्रिप्ट है
2. जाँच करें कि p_script किस भाषा से संबंधित है
3. संबंधित ScriptLanguage के लिए p_script और Object इंस्टेंस के custom_script को ScriptDB को ScriptLanguage दें,
4. ScriptDB से प्रतिक्रिया प्राप्त करें कि क्या p_script को Object को सौंपा जा सकता है, $# Object पर custom_script द्वारा निहित बाधाओं को देखते हुए Object उदाहरण।

यह हमें ClassDB दोनों को किसी भी संशोधन से साफ रखने और object.h साफ रखने की अनुमति देगा ( custom_script के लिए एक सेटर/गेटर से अलग)। यह उन स्क्रिप्टिंग भाषाओं की अनावश्यक जटिलता को भी रोकता है जिन्हें पहचानकर्ताओं और नामस्थानों को परिभाषित करने के लिए गोडोट पर निर्भर रहने की कोई आवश्यकता नहीं है (जैसे कि GDScript और VisualScript की आवश्यकता होगी, C#, C++, Python, आदि के विपरीत)।

फिर आपको केवल ScriptServer विधियों को परिभाषित करना होगा जो कस्टम प्रकार/कस्टम प्रकार विरासत की पुष्टि करने की प्रयोगात्मक ClassDB कार्यक्षमता को प्रतिस्थापित करने के लिए सभी लागू स्क्रिप्टिंग भाषाओं में पहचानकर्ता/नामस्थान जांच कर सकते हैं। पदानुक्रम काफी आसान।

क्या इनमें से कोई भी स्वीकार्य विकल्प @reduz जैसा लगता है?

बस यहां अपनी आवाज जोड़ रहा हूं। मैंने अभी-अभी गोडोट के साथ काम करना शुरू किया है और, जब मैंने कस्टम प्रकार के ऐडऑन के बारे में पढ़ा, तो मैंने वास्तव में सोचा था कि मैं एक नया पुन: प्रयोज्य आधार प्रकार बनाऊंगा। जैसे कि जब आप एक KinematicBody बनाते हैं तो आप उसमें एक स्क्रिप्ट संलग्न कर सकते हैं, लेकिन यह अभी भी अपने सभी KinematicBody काम करेगा।

इसे दो तरह से मजबूत किया जाता है:

1. उन्हें प्रकार कहा जाता है। जबकि भाषाएं भिन्न होती हैं कि कोई प्रकार विस्तार योग्य है या नहीं (जावास्क्रिप्ट: हाँ, गोलंग: नहीं, पायथन: हाँ), एक प्रकार जिसे आप आम तौर पर परिभाषित करते हैं वह विस्तार योग्य है यदि प्रथम श्रेणी भाषा प्रकार विस्तार योग्य हैं। गोडोट में, प्रथम श्रेणी के प्रकार विस्तार योग्य हैं, लेकिन कस्टम प्रकार नहीं हैं (कम से कम उसी तरह से नहीं)। प्रीफ़ैब सीन या टेम्प्लेट सीन जैसे उन्हें कुछ और कहना, उन्हें अलग के रूप में चिह्नित करने में मदद करेगा।

1. वे 'नया नोड बनाएँ' विंडो में प्रथम श्रेणी के नोड्स के समान पेड़ में दिखाई देते हैं। इसका मतलब है कि आप उन्हें उसी तरह इस्तेमाल करते हैं। 'प्रीफ़ैब्स' या 'टेम्पलेट्स' के लिए एक अलग सेक्शन होने या आप उन्हें जो भी कॉल करना चाहते हैं, उन्हें फिर से अलग कहा जाएगा।

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

मुझे लगता है कि यह इच्छित समाधान से कहीं अधिक आसान है:

1. "custom_type_script" नामक ऑब्जेक्ट क्लास में इंस्पेक्टर में छिपी एक संपत्ति जोड़ें और स्क्रिप्ट के बजाय इस संपत्ति का चयन करने के लिए कस्टम स्क्रिप्ट असाइन करें
2. जब आप नोड को विस्तारित करने का प्रयास करते हैं, तो जांचें कि क्या यह गुण शून्य है, यदि नहीं, तो नोड वर्ग के बजाय इस स्क्रिप्ट का विस्तार करें (लिखने का विस्तार "res:/path/to/script.gd")
3. यदि नोड स्क्रिप्ट शून्य है तो कस्टम स्क्रिप्ट के उदाहरण को इंगित करने के लिए get_script_instance बदलें

@MarianoGnu ठीक है, संपादक परिवर्तन बनाने के मामले में, script संपत्ति को स्वतः भरकर करना और इसे पहले स्थान पर कभी भी शून्य होने से रोकना आसान है (क्योंकि संपादक केवल कभी देखता है script संपत्ति, और हमें हर बार जब यह script संपत्ति का संदर्भ देता है और उस कोड को संशोधित करने की आवश्यकता नहीं होती है यदि हम केवल script के मूल्य को बदल देते हैं) .

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

एक संयोजन किया जा सकता है, ऑब्जेक्ट में अदृश्य स्क्रिप्ट को स्क्रिप्टडीबी में स्टोर करने के बजाय, स्क्रिप्ट रीडर में "एक्सटेंड कस्टमक्लासनाम" को "एक्सटेंड" रेस:/पाथ/स्टोर्ड/इनस्क्रिप्टडीबी.जीडी में बदलने के लिए प्री-पास जोड़ें। "जीडीस्क्रिप्ट के प्रीकंपेलर में, क्योंकि स्क्रिप्ट के बाहर स्क्रिप्ट का इनहेरिट पदानुक्रम होना बहुत परेशानी भरा है (पदानुक्रम जड़ से नीचे एक सीधी रेखा होना चाहिए, एक शाखा होने से भ्रम की स्थिति पैदा होती है)

क्योंकि स्क्रिप्ट को इनहेरिट पदानुक्रम से बाहर करना बहुत परेशानी भरा है (पदानुक्रम जड़ से नीचे एक सीधी रेखा होना चाहिए, एक शाखा होने से भ्रम की स्थिति पैदा होती है)

@MarianoGnu शायद यहाँ कुछ गलतफहमी है। आप किस बिंदु पर सोचते हैं कि वंशानुक्रम की कोई सीधी रेखा नहीं है? जहां तक ​​​​मैं चीजों को लागू करने गया हूं, स्क्रिप्ट के बीच हमेशा एक बहुत स्पष्ट विरासत पदानुक्रम होता है। मैंने इस बारे में कुछ भी नहीं बदला है कि विरासत पदानुक्रम स्वयं कैसे काम करता है। मैंने किसी दिए गए स्क्रिप्ट को स्ट्रिंगनाम पर मैप करना और इसे किसी प्रकार के डीबी में देखना संभव बना दिया है।

और अगर हम पहले से ही ऐसा करने के काम से गुजर रहे हैं, तो स्क्रिप्ट के टेक्स्ट को GDScript कंपाइलर में वापस पथ में बदलने का कोई कारण नहीं है। सभी कंपाइलर एक Script उदाहरण को script चर के लिए असाइन करते हैं। चाहे मैंने स्क्रिप्ट को ResourceLoader::load(path) विधि के माध्यम से लोड किया हो या इसे Class/ScriptDB::get_script(namespace_and/or_identifier) के साथ लाने के माध्यम से वास्तव में कोई फर्क नहीं पड़ता।

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

एक "कस्टम नोड" के रूप में सिर्फ एक स्क्रिप्ट है, यहां तक ​​​​कि स्क्रिप्ट को एक अंतर्निहित नोड में निर्दिष्ट करने से भी क्या अंतर है? कस्टम नोड सुविधा क्या करने वाली है?

@MCrafterzz इस बात पर चर्चा की गई कि प्लगइन से बनाए गए कस्टम नोड पर एक स्क्रिप्ट जोड़ने की क्षमता रखने के लिए कस्टम नोड्स की क्षमता होनी चाहिए।

वर्तमान में कस्टम नोड केवल एक नोड है जिसे पहले से संलग्न एक स्क्रिप्ट के साथ बनाया गया है और आइकन और नाम पहले ही बदल दिया गया है।

@willnationsdev इस सुविधा को लागू करके आप कितनी दूर आ गए हैं।
मैं वास्तव में चाहूंगा कि यह सुविधा 3.1 से पहले यहां हो, यह वास्तव में एक अद्भुत अतिरिक्त होगा।
गोडोट प्लगइन और एडऑन सिस्टम के लिए।

मैं किसी पर दबाव नहीं बनाना चाहता। तो कृपया इसे काम के तरीके से न लें।

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

@swarnimarun

इसके अलावा, यह उपयोगकर्ताओं को वैश्विक में प्रकार पंजीकृत करने की अनुमति देगा जो टाइपनाम-टू-फाइलपाथ मैपिंग तक पहुंच प्रदान करता है। GDScript इन मैपिंग को अनिवार्य रूप से सरल वैश्विक टाइपनामों के रूप में देखने में सक्षम होगा। इसके अलावा, पंजीकृत होने के लिए प्रकारों का कस्टम प्रकार होना आवश्यक नहीं है और प्रकार या तो स्क्रिप्ट या दृश्य हो सकते हैं।

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

@willnationsdev कोई चिंता नहीं, अगर यह 3.1 में आता है तो मैं संतुष्ट रहूंगा।
और मुझे एहसास हुआ कि यह काफी काम का हो सकता है।
अच्छा काम करते रहें।

वर्तमान में, संपादक के पास किसी भी नोड की स्क्रिप्ट को आसानी से विस्तारित करने की क्षमता है:

नोड ही वर्तमान में इस तरह दिखता है:

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

और भले ही आप कस्टम स्क्रिप्ट का विस्तार कर सकते हैं, यह बहुत कष्टप्रद है कि सादे कस्टम नोड्स विस्तारित कस्टम नोड्स के समान दिखते हैं।

तो, यहाँ मेरा सरल समाधान है: जब एक कस्टम नोड की स्क्रिप्ट कस्टम नोड की परिभाषा में स्क्रिप्ट के समान होती है, तो स्क्रिप्ट आइकन को इस तरह से फीका कर देना चाहिए:

अर्थ:

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

आप स्क्रिप्ट छिपाना नहीं चाहते हैं? ठीक है, फिर custom_node स्क्रिप्ट और प्रोजेक्ट नोड स्क्रिप्ट दिखाएं।

@aaronfranke मेरी राय में यह सबसे अच्छा समाधान है। इंस्टेंस सीन भी इसका फायदा उठा सकते हैं।

@zatherz et al, अब जबकि #30697 लागू कर दिया गया है, और क्या सुधार किया जा सकता है? क्या https://github.com/godotengine/godot/issues/6067#issuecomment -238250383 में कुछ और है जो महत्वपूर्ण है?

#30697 द्वारा तय के अनुसार बंद करना। जबकि ओपी में मूल प्रस्ताव https://github.com/godotengine/godot/issues/6067#issuecomment -238250383 में विस्तृत है, इसे लागू नहीं किया गया है, यह https:// में @reduz की चिंताओं के कारण नहीं होगा। github.com/godotengine/godot/issues/6067#issuecomment -239060186।