Godot: `Class_name` के कुछ उपयोग चक्रीय त्रुटियों को अप्रत्याशित रूप से उत्पन्न कर सकते हैं

यदि आप आधार स्क्रिप्ट को class_name देते हैं और इसका विस्तार रेखा में उपयोग करते हैं तो यह काम करेगा।
पहली बार में फ़ाइल नाम (https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_parser.cpp#L4947) का उपयोग करने पर मुझे भी त्रुटि हो रही है, लेकिन वह भी गायब हो जाती है और नहीं आती है एक बार काम करने के बाद वापस (जैसा कि मैंने उल्लेख वर्कअराउंड का उपयोग करने के बाद किया है)

@ PetePete1984 कूल, धन्यवाद पीट। यह है कि यह कैसे इस्तेमाल किया जा करने का इरादा है?

इसकी दोहरी जाँच और परीक्षण करते समय, मैं get_class() पद्धति को देख रहा था, और सोच रहा था कि क्या इसे Node2D वापस करना चाहिए? is CustomClass हिस्सा _true_ लौट रहा है, लेकिन दूसरी ओर is_class("CustomClass") _false_ है।

CC @reduz @vnen @willnationsdev

मैं यह नहीं कहूंगा कि यह अभिप्रेरित व्यवहार है, विशेष रूप से एक त्रुटि संदेश के साथ नहीं, जो चक्रीय समावेशन का अर्थ है जहां कोई भी नहीं है।
get_class() और is_class() मुझे सामान्य रूप से भ्रमित कर रहे हैं, वास्तव में उस पर टिप्पणी नहीं कर सकते। स्रोत लंबे समय में उस रहस्य को हल कर सकता है, लेकिन अब तक is मेरे लिए पर्याप्त था।

@ जेवन क्या यह कुछ ऐसा होगा जो स्पष्ट त्रुटि संदेश की आवश्यकता है?

@ PetePete1984 हाँ, is 3.1 में अब एक आश्चर्यजनक बात हो गई है। हालाँकि मैं एक ऐसी स्थिति में आया था, जहाँ मैं नए match जैसे match custom_thing.get_class() का उपयोग करना पसंद करता था और कई तारों के खिलाफ तुलना करता था। लेकिन कुछ भी महत्वपूर्ण नहीं है, सिर्फ एक पठनीयता और कम टाइपिंग चीज।

@avencherus आप के साथ दूर करने में सक्षम हो सकता है:

match custom_thing.get_script():
    <typename>: stuff # script classes
    <typename>: stuff
    _: match custom_thing.get_class():
        "Node": stuff # engine classes

मुझे यकीन नहीं है कि यह त्रुटि क्यों दे रहा है, मुझे जांच करनी होगी।

@willnationsdev को पूरी तरह से यकीन नहीं है कि get_script() हिस्से के लिए चेक मेरे लिए कम से कम है, यह GDScript ऑब्जेक्ट [GDScript:1057] लौटाता है।

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

@avencherus स्क्रिप्ट कक्षाओं के "वर्ग के नाम" वैश्विक चर हैं जो स्क्रिप्ट का संदर्भ देते हैं। इसलिए...

class_name CustomType
match get_script():
    CustomType:
        print("I am a CustomType!") # should print

@willnationsdev ओह

@ जेवन हाँ, कहानी में कुछ अतिरिक्त झुर्रियाँ। मुझे देखने दो कि मैं उन्हें कितनी अच्छी तरह समझ सकता हूं।

सबसे पहले, पीट का समाधान काम करता है, जब एक बेस क्लास को class_name दिया जाता है class_name CustomBase जो मैंने जोड़ा है, वह आधा काम करता है। नोड्स जोड़ते समय यह नोड सूची में नहीं दिखता है, लेकिन is काम करेगा, और कोई अजीब त्रुटियां नहीं हैं।

फिर इस बात की पुष्टि करने के लिए, मैं एक base2.gd -> custom2.gd विस्तारित स्क्रिप्ट बनाने के चरणों को फिर से बनाने के लिए गया। फिर अंदर custom.gd class_name CustomClass2 , लेकिन बेस क्लास में किसी भी वर्ग का नामकरण नहीं होता है।

एक और मुद्दा सामने आया। नोड सूची में पहले एक था, लेकिन एक आइकन के साथ सूचीबद्ध किया गया जिसने कहा कि "त्रुटि"

इसलिए मैंने पहली बेस क्लास को संशोधित किया ताकि वे दोनों class_name । लेकिन फिर से अजीब परिणाम मिले।

नोड सूची में सब कुछ दिखाई नहीं दे रहा है, और फिर is कीवर्ड केवल उनमें से एक के लिए सही वापस आए। यद्यपि इस स्क्रीनशॉट में आप देख सकते हैं कि नोड सूची CustomClass2 को पहचानती है, फिर भी इसके पीछे के कोड में, is CustomClass2 झूठे लौट रहे हैं।

ऐसा लगता है कि बहुत सारी चीजें बंद हो रही हैं या पर्दे के पीछे से गुज़र रही हैं। काफी हद तक यह अनुमान लगाना कि यह मेरे सीमित ज्ञान के साथ क्या कर सकता है।

उम्मीद है की वो मदद करदे। एक्स)

संपादित इस टिप्पणी ध्यान न दें। मुझे महसूस नहीं हुआ था कि class_name 3.0 में

class_name 3.0.6 में टूट गया लगता है। मैं एक अलग मुद्दा बनाऊंगा, लेकिन:

@bfishman स्क्रिप्ट कक्षाएं 3.0.x में एक विशेषता नहीं हैं। इसलिए यह काम नहीं कर रहा है।

मैंने बस निम्नलिखित की कोशिश की और प्रत्येक संस्करण ने काम किया। CreateDialog में सभी स्क्रिप्ट कक्षाएं दिखाई गईं, स्क्रिप्ट ठीक संकलित की गईं, दृश्य सफलतापूर्वक चला, आदि।

इस तरह एक दृश्य पदानुक्रम के साथ:

• नोड (बेस.जीडी)
  
  
  
  • नोड (व्युत्पन्न)
  
  

स्क्रिप्ट:

# res://base.gd
extends Node
class_name BaseNode
func _ready():
    print("base")

# res://derived.gd
extends BaseNode
extends "base.gd" # I tried both of these 'extends' lines and they each worked
class_name DerivedNode # I tried with and without this line
func _ready():
    print("derived")

हर बार जब मैंने परीक्षण चलाया, तो यह छपा

base
derived
base

...जैसा होना चाहिए।

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

@willnationsdev देखने के लिए धन्यवाद, मैं इसे

@avencherus मुझे पूरा यकीन नहीं है। मुझे अभी याद है @Kroffel ने इसके बारे में कुछ उल्लेख किया है जब मैंने स्क्रिप्ट वर्ग आइकन के सामान में कुछ सुधार जोड़े थे।

Https://github.com/godotengine/godot/commit/1093c0ff51b980634dffdd9618eaa53061da6419 पर परीक्षण किया गया
मुझे कोई त्रुटि नहीं दिख रही है लेकिन यह "नया नोड बनाएँ" संवाद में नोड नहीं दिखा रहा है।

मुझे मूल पोस्ट में दिखाई गई त्रुटि भी मिल रही है (Windows x64 Godot 3.1 अल्फ़ा):

हालाँकि, यह एक अलग संदर्भ में होता है। मेरे पास 3 स्क्रिप्ट्स हैं, जिनमें से प्रत्येक में एक अलग class_name , और उनमें से प्रत्येक में Node2D का विस्तार है। जब तक स्क्रिप्ट में से कोई एक is ऑपरेटर के साथ इसे संदर्भित नहीं करता तब तक त्रुटि नहीं होती है। उदाहरण के लिए if some_var is Incomer । हालांकि अजीब बात यह है कि यदि एक ही स्क्रिप्ट अन्य class_name का संदर्भ देती है, तो कोई समस्या नहीं है। और अगर दूसरी स्क्रिप्ट में class_name का संदर्भ दिया जाए, तो कोई समस्या नहीं है।

तो एक ClassA, ClassB, ClassC है। यदि ClassC is ऑपरेटर के साथ ClassA का संदर्भ देता है, तो लोड समय पर त्रुटि होती है। यदि ClassC ClassB का संदर्भ देता है, तो कोई त्रुटि नहीं। यदि ClassB ClassA का संदर्भ देता है, तो कोई त्रुटि नहीं।

कोई भी स्क्रिप्ट एक ही दृश्य में नहीं है, और सभी नोड्स भाई बहन हैं (कोई पूर्वज संबंध नहीं)।

@AlexHolly मेरे साथ भी यही स्थिति है। त्रुटि प्रतीत होती है, लेकिन हां, आधार लिपि नहीं होने पर कक्षाएं नोड नोड में दिखाई नहीं देंगी, जिसमें class_name ।

यह अल्फा 3.1 c320d93 में है

"का उपयोग करके एक छोटा सा उदाहरण है"। यदि आप "as" का उपयोग करते हैं तो वही बात हो सकती है।
इसका उल्लेख @Oranjoose ने भी किया था।
cycle.zip

कोई भी स्क्रिप्ट एक ही दृश्य में नहीं है, और सभी नोड्स भाई बहन हैं (कोई पूर्वज संबंध नहीं)।

यह दृश्य में नोड्स के साथ कुछ नहीं करना है। स्क्रिप्ट में चक्र स्वयं होता है।

अभी के लिए is और as का उपयोग करते हुए साइकिल प्राप्त करना काफी आसान है और अगर ऐसा होता है कि यह वास्तव में बग नहीं है, तो यह तरीका है। मैं इसे सुधारने की कोशिश करूंगा लेकिन 3.1 के लिए नहीं। मूल रिपोर्ट एक बग है क्योंकि कोड में कोई वास्तविक चक्र नहीं हैं।

मैं 451e5fd में भी त्रुटि को पुन: उत्पन्न नहीं कर सका। नोड बनाएँ विंडो tho में नहीं दिखा।

मैं पुष्टि कर सकता हूं कि यह समस्या 0dbe014 (नवीनतम मास्टर मैंने खींची) में मौजूद नहीं है। हम शायद इस मुद्दे को बंद कर सकते हैं।

इसके अलावा, मैं इसे बनाने में सक्षम था ताकि स्क्रिप्ट का विस्तार करने वाली स्क्रिप्ट कक्षाएं अभी भी CreateDialog में दिखाई दें जो अभी भी एक बग था। PR ऊपर लिंक किया गया है।

@willnationsdev धन्यवाद होगा। X) मैं class_name साथ विभिन्न मुद्दों पर टकरा रहा हूं, लेकिन इस एक को फिर से बनाने में सक्षम नहीं है। उन्हें फिर से बनाने के लिए बहुत मुश्किल है, लेकिन मैंने उनका उपयोग करना बंद कर दिया है।

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

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

@avencherus मैं देख रहा हूँ। वैसे मुझे आशा है कि आप अंततः यह जान सकते हैं कि यह किन परिस्थितियों में हो रहा है। संदर्भ के बिना, हम इसे ठीक नहीं कर सकते। एक्सडी

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

मुझे जो समाधान मिला वह load(get_script().resource_path).new() का उपयोग करना था। एक कौर, मुझे पता है, लेकिन इसने पार्सर को डेटा का सुरक्षित रूप से निर्माण करने और संकलन प्रक्रिया के माध्यम से सुरक्षित रूप से प्राप्त करने की अनुमति दी, टाइपनेम को आधिकारिक रूप से पंजीकृत होने दें, और उसके बाद केवल RUNTIME पर टाइप का संदर्भ दें जब यह पूरी तरह से प्रारंभ हो गया था।

मैं समय-समय पर इसे छेड़ने का प्रयास करता रहूंगा। काश मैं और अधिक मदद कर सकता, लेकिन मैं कल्पना कर रहा हूं कि उन्हें तब तक इंतजार करना होगा जब तक कि उनके कार्यान्वयन के गहन ज्ञान वाले लोग अपनी परियोजनाओं पर काम कर रहे हों और इन समस्याओं में पहले भाग लें। मैं दांव लगाऊंगा कि उन्हें पता होगा कि उस स्थिति में अपनी जगहें कहाँ सेट करनी हैं।

कुछ मुद्दों का एक त्वरित सारांश (मैं आने वाले कुछ हफ्तों में इन्हें पोस्ट करूँगा):

1. obj is MyClass मुझे ये चक्रीय त्रुटियां मिलेंगी और दोनों के बीच कोई अन्य संबंध या संदर्भ नहीं था। हालांकि मुझे नहीं पता कि यह दृश्य पेड़ को स्कैन कर रहा है और अपने बच्चों को चक्रीय संदर्भों के रूप में गिन रहा है।
2. मैंने आपके द्वारा बताई गई असुविधा में भी भाग लिया है। काश ऐसा नहीं होता, क्योंकि यह एक ही प्रकार की स्थितियों में अंतर्निहित / देशी वर्ग के नामों के साथ ठीक काम करता है। तो आप इस अंतिम उद्देश्य के साथ कोड का एक पूरा गुच्छा लिख ​​सकते हैं, यह सोचकर कि यह सब ठीक है, जब तक कि आप अपने कस्टम प्रकारों को जोड़ना शुरू नहीं करते हैं, और आपको एक हैक / वर्क-अराउंड / पुरानी विधि का सहारा लेना होगा, और तब क्या था इसका मूल्य अगर क्रिया पथ नामों से बचने के लिए नहीं है?
3. मैं संपादक में इन चीजों को त्रुटि-मुक्त कर चुका हूं और टेस्ट रन के दौरान साफ-सुथरी निष्पादित कर रहा हूं, लेकिन फिर निर्यात किए गए गेम में त्रुटियां और विफलताएं हैं। नीचे एक उदाहरण (हालांकि इस मुद्दे से सबसे अधिक असंबंधित है) class_name उपयोग बिल्ड में उनके आइकन नहीं ढूंढ सका, लेकिन संपादक से रन और परीक्षण में कोई समस्या नहीं है।

कुल मिलाकर class_name साथ मेरे अनुभव लगभग अप्रत्याशित, बहुत मुश्किल से समझाने, और त्रुटियों को पुन: पेश करने के लिए लगभग दैनिक मुठभेड़ रहे हैं। बहुत सारा समय इसके चारों ओर नाचते हुए बर्बाद हो जाता है और उन्हें हल करने की कोशिश करता है।

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

शायद 4.0 में। एक्स)

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

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

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

@ हेवेन हे। वापसी पर स्वागत है। एक्स)

उत्तर और समय के लिए धन्यवाद।

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

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

एक बड़ी चीज जो मुझे याद आ रही है वह है संकेत पर आकर्षित करने की क्षमता जब एक कस्टम वर्ग आपके नए प्रकार के संकेत के साथ संयुक्त होता है। var thing : NewThing

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

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

इस तरह की कुछ घटनाओं ने बहुत कुछ हासिल किया है। मुझे लगता है कि कहीं 30,000 लाइनों की तरह एक समस्या स्पार्किंग की कल्पना करने के लिए।

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

मैंने देखा है कि ऐसा कभी-कभी होता है जहाँ त्रुटि रेखा के ऊपर या नीचे कारण से हो रही है।

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

3.1 में चेतावनियों और त्रुटियों के साथ कई असामान्य घटनाएं हुई हैं, इसलिए मुझे आश्चर्य होता है कि क्या समस्या स्वयं चीज़ है, या त्रुटि रिपोर्टिंग तर्क के साथ कोई समस्या है? मुझे अभी तक नहीं पता है कि कहां से शुरू करना है, और मैं केवल यह आशा कर सकता हूं कि इसमें से कुछ मददगार होने के साथ समाप्त हो रहे हैं, और समय के साथ मैं उन्हें छोटी परियोजनाओं में संकीर्ण करने में सक्षम हो सकता हूं।

संपादित करें: कोई बात नहीं, किसी भी तरह मैं सिर्फ यह नहीं कर चक्रीय समावेशन का समाधान ...
project.godot में वैश्विक कक्षाएं लॉन्चिंग एडिटर पर वैसे भी अधिलेखित हो जाती हैं।

@vnen या @avencherus ओपी को अपडेट करने के लिए अच्छा होगा कि यह बग आखिर में क्या है, इसका स्पष्ट विवरण के साथ, क्योंकि यह एक अच्छा विचार होने से पहले पढ़ने के लिए एक लंबी चर्चा है।

@ akien-mga मैं अब इसकी स्थिति के बारे में निश्चित नहीं हूं, या विशेष रूप से इसके बारे में क्या लिखना है।

अगर मुझे याद है कि कम से कम इसके कुछ हिस्से हैं। अपने वर्तमान रूप में GDScript की सीमा के रूप में अपेक्षित चक्रीय त्रुटियां, और फिर अप्रत्याशित वे दिखाई देते हैं जो छोटी परियोजनाओं में अलग करना और पुन: उत्पन्न करना मुश्किल होता है (कभी-कभी त्रुटिपूर्ण त्रुटि संदेशों के कारण)।

चूंकि यह एक ऐसी सुविधा नहीं है जिसका मैं वर्तमान में उपयोग कर रहा हूं, इसलिए मैं प्रगति का अनुसरण नहीं कर रहा हूं। मुझे लगता है कि कुछ चीजें यहां और इस समय से तय हो गई हैं।

इन अन्य मुद्दों पर एक नज़र में ऐसा लगता है जैसे कि बात GDScript में आवश्यक परिवर्तनों के संबंध में है। 3.2 के संशोधन के साथ। यदि वह योजना है, तो 3.1 मील के पत्थर के नीचे नहीं होगी।

यह बंद करना शायद ठीक है, जब तक कि vnen बहीखाता पद्धति के लिए उपयोग नहीं कर रहा है, या यदि आप इसका उपयोग आगामी डुप्लिकेट मुद्दों के लिए संदर्भित करने के लिए करना चाहते हैं जब 3.1.0 स्थिर भूमि।

यह सुविधा एक प्रयोज्य जीत है जिसमें मुझे दिलचस्पी है, इसलिए मैं 3.2 में इसकी पुन: समीक्षा करूंगा, और किसी भी निष्कर्ष को पोस्ट करूंगा।

खैर यह बंद नहीं होना चाहिए, नहीं, डुप्लिकेट रिपोर्टों की सरासर राशि निश्चित रूप से दिखाती है कि ठीक करने के लिए कुछ है :)

मैं निम्नलिखित त्रुटि संदेश में भाग गया, जो मुझे 3.0 से 3.1 तक एक परियोजना को अद्यतन करने के लिए समस्याग्रस्त है। पहले निम्नलिखित कोड काम करते थे:

extends Node2D
export(String, FILE, "*.gd") var _class_name = "res://Test.gd"
onready var SomeClass = load(_class_name)

func foo():
    for c in get_children() :
        if c is SomeClass : 
            do_stuff()

जब मैं कोड बदलूं:

extends Node2D
class_name SomeClass

func foo():
    for c in get_children() :
        if c is SomeClass : 
            pass

मुझे निम्नलिखित त्रुटि मिलती है:

पार्स त्रुटि: कक्षा फ़ाइल में एक नाम का उपयोग करने की अनुमति नहीं है (चक्रीय संदर्भ बनाता है)

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

@ डायस्पटर मुझे लगता है कि आपको बस इतना करना है if c is SomeClass if c is get_script() । दोनों विकल्प एक रनटाइम जांच को अंजाम देते हैं, लेकिन SomeClass संस्करण की आवश्यकता होती है कि आप स्क्रिप्ट को फिर से संपादक-समय पर लोड करें (जिसके परिणामस्वरूप चक्रीय संदर्भ) जबकि get_script() पद्धति कुछ भी करने का प्रयास नहीं करती है संपादक समय।

@willnationsdev मुझे समझ में आया कि एक वैध समाधान है (या मेरे मुद्दे पर समाधान जैसा कि मैंने अपनी मूल टिप्पणी लिखने के बाद महसूस किया कि पहला तरीका अभी भी काम कर रहा है। यह कहा जा रहा है कि मैं पसंद करूंगा अगर दूसरा तरीका ठीक से समर्थन किया जा सके। मुझे भी लगा। यह काम करता है:

DummySomeClass.gd
extends Node2D
class_name DummySomeClass

func foo():
    pass


SomeClass.gd
extends DummySomeClass
class_name SomeClass

func foo():
    for c in get_children() : 
        if c is DummySomeClass: 
            pass

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

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

यह एक भोला सवाल हो सकता है लेकिन क्या हमें इस गैर-चक्रीय प्रतिबंध से छुटकारा नहीं मिलना चाहिए।
मेरा मतलब है अन्य भाषाओं जैसे जावा, सी #, सी ++, आदि ... बिना मुद्दों के प्रकारों से निपट सकते हैं ...

@harraps जो किया जाएगा (जैसा कि मैंने थ्रेड में कुछ बार कहा था), लेकिन इसमें कुछ मूलभूत परिवर्तनों की आवश्यकता है कि कैसे GDScript वायर्ड है। मैं अब इसे नहीं छूऊंगा क्योंकि हम रिलीज के करीब हैं और इस बदलाव से अनुकूलता टूटने की संभावना है।

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

यदि आप एक स्थिर फ़ैक्टरी विधि के साथ एक वर्ग बनाते हैं जो रिटर्न मान में वर्तमान वर्ग के नाम का संदर्भ देता है, तो यह संपादक के भीतर किसी भी प्रकार की त्रुटि की रिपोर्ट नहीं करेगा, लेकिन एक बार संपादक बंद हो जाता है, तो आपको एक त्रुटि रिपोर्टिंग मिलेगी वह संसाधन अभी भी उपयोग किए जा रहे हैं।

extends Reference
class_name MyClass

static func make() -> MyClass:
    # can't even use get_script() for static funcs, but that's a separate issue
    var c = load("res://my_class.gd").new()
    return c

फिर आपको यह त्रुटि मिलती है:

ERROR: SelfList<class GDScriptFunction>::List::~List: Condition ' _first != 0 ' is true.
   At: .......\godot\core/self_list.h:111
ERROR: SelfList<class GDScript>::List::~List: Condition ' _first != 0 ' is true.
   At: .......\godot\core/self_list.h:111
WARNING: ObjectDB::cleanup: ObjectDB Instances still exist!
     At: core\object.cpp:2093
Leaked instance: GDScript:17060 - Resource name:  Path: res://my_class.gd
Leaked instance: GDScriptNativeClass:1058
ERROR: ResourceCache::clear: Resources Still in use at Exit!
   At: core\resource.cpp:425

# 944 से रिपॉस्टिंग,

मैं नियमित रूप से चक्रीय जीडीस्क्रिप्ट निर्भरताओं में भी दौड़ रहा हूं। यहाँ कुछ उपयोग के मामले हैं जहाँ मैं वर्तमान में बिना जीडीएसस्क्रिप्ट के वापस लौटने के लिए मजबूर हूँ:

1. मेरे पात्र एक ActorController उपयोग करते हैं जो अलग-अलग Move s (जैसे किसी राज्य की मशीन में राज्यों) का उपयोग करते हैं। ActorController फॉरवर्ड _physics_process() और ऐसे सक्रिय Move । इसके विपरीत, यह कदम ActorController को एक और Move या एक्सेस प्रॉपर्टी (जैसे जंप हाइट, रनिंग स्पीड, आदि) पर स्विच करने के लिए एक्सेस करता है।

2. मेरे MoveRepository साथ समान स्थिति - रिपॉजिटरी स्टोर पुन: प्रयोज्य Move s के लिए स्टोर करते हैं, फिर भी Move s को भी रिपॉजिटरी तक पहुंचने की आवश्यकता होती है यदि कोई अन्य Move प्राप्त करना चाहता है। अपने ActorController में इसे चुनने के लिए

यह C # या C ++ में एक गैर-इश्यू है, लेकिन GDscript (वैकल्पिक स्टैटिक टाइपिंग के साथ) के लिए मुझे वेरिएंट (डायनामिक टाइपिंग) पर वापस आना पड़ता है या घटनाओं और इस तरह के उपयोग की आवश्यकता नहीं होती है।

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

बस इसी में भाग गया। से संबंधित लगता है।

वास्तव में बहुत अजीब है।

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

ध्यान दें, मैंने class_names के लिए संसाधन पथों को बंद कर दिया था, और मुझे बिना किसी कारण के त्रुटियां देने से पहले लगभग 5 मिनट के लिए काम करना ठीक लगा। : /

हम्म। त्रुटियों को इस आदेश के साथ करना प्रतीत होता है कि संपादक विंडो में चीजें भरी हुई हैं? मैं उन्हें फ़ाइलों को बंद करने और फिर से खोलने के द्वारा प्राप्त कर सकता हूं, जिस क्रम में उन्हें विरासत में मिला है। तो, शायद इसके आसपास किसी तरह की परेशानी कुछ फाइलों में चीजों को घोषित नहीं करना है। : /

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

@ कोणीय-एन्जिल मैंने देखा है कि गोडोट को फिर से शुरू करने से त्रुटियों का समाधान होता है। यह निराशाजनक है कि मैं कस्टम क्लासेस / प्रकारों के साथ गोडोट में स्थैतिक टाइपिंग का उपयोग नहीं कर सकता हूं, बिना विचित्र त्रुटियों के पॉपअप के बिना।

"प्रोजेट को बंद करना / फिर से खोलना मेरे लिए काफी है।" Shift + Ctrl + Q (प्रोजेक्ट सूची पर जाएं), शीघ्र पुष्टि करें, फिर प्रोजेक्ट पर दोबारा क्लिक करें। फिर भी थोड़ा निराशा होती है, लेकिन आपको इसकी आदत पड़ जाती है (जब तक कि यह ठीक न हो जाए)।

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

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

—आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है। सीधे इस ईमेल पर जाएं, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

गोडोट 3.1.1 (मोनो नहीं)
Stack.zip

न्यूनतम प्रजनन योग्य उदाहरण

https://cdn.discordapp.com/attachments/477544613511692358/584811385838632977/unknown.png

_please_ कोई इसे ठीक करता है।

लोडिंग ठीक काम करता है, प्रीलोडिंग नहीं करता है

ध्यान दें कि वास्तव में StackList.gd में एक अनकैप्ड स्क्रिप्ट त्रुटि है। विशेष रूप से इसकी शब्दकोश कुंजी घोषणा में एक वाक्यविन्यास त्रुटि है। हालाँकि यह केवल तभी पकड़ा जाता है जब शब्दकोश को स्थिरांक में बदल दिया जाता है।

बस एक नोट बनाना चाहता था कि मैं आज भी "class_name बग" हिट कर रहा हूं।

यदि ऑब्जेक्ट className है, तो मैं परीक्षण के बजाय object.has_method ("नाम") का उपयोग करने के लिए वापस आ गया हूं

मैं इसे 3.1.1 में एक बार मार रहा हूं, और इससे बचने के लिए हुप्स से कूद रहा हूं।
उम्मीद है कि यह 3.2 में तय हो जाएगा!

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

मैं वर्तमान में @JavaryGames पर इसे ठीक करने की कोशिश कर रहा हूं, समाधान पहले से ही चल रहा है। यकीन नहीं है कि अगर यह 3.2 में बदल जाएगा, क्योंकि यह एक बड़ा बदलाव है (कुछ हद तक कैसे GDScript आंतरिक रूप से काम करता है) को फिर से तैयार करना है और हम रिलीज के करीब हैं, लेकिन शायद हम 3.2.1 या कुछ में एकीकृत कर सकते हैं। निश्चित रूप से 4.0 में तय किया जाएगा।

जिस फिक्स पर मैं काम कर रहा था वह अभी भी WIP है और क्रैश का कारण बन रहा है। मुझे विश्वास नहीं है कि बीटा स्टेज में इसे इतना बड़ा मर्ज किया जाएगा, इसलिए बाद में इसे 3.2.x रिलीज में होने की संभावना है।

@ इवन इस बग के लिए फिक्स के साथ शाखा है, जिसे हम संकलित और परीक्षण कर सकते हैं?

निश्चित नहीं है कि इस बिंदु पर अधिक जानकारी मदद करती है, लेकिन समस्याग्रस्त वर्ग के class_name को बदलना और फिर इसे वापस बदलना एक

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

@ इवन इस बग के लिए फिक्स के साथ शाखा है, जिसे हम संकलित और परीक्षण कर सकते हैं?

हां, मेरे सार्वजनिक कांटे में यह है: https://github.com/vnen/godot/commits/gdscript-no-cycles

निश्चित नहीं है कि इस बिंदु पर अधिक जानकारी मदद करती है, लेकिन समस्याग्रस्त वर्ग के class_name को बदलना और फिर इसे वापस बदलना एक

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

https://github.com/godotengine/godot/issues/38265 कुछ प्रजनन विवरणों के साथ इसकी एक डुप्लिकेट रिपोर्ट प्रतीत होती है।

यह फिक्स मेन लाइन में कब आएगा?
यह सुपर कष्टप्रद है क्योंकि मैं टाइप स्क्रिप्ट्स का उपयोग करता हूं और इस समस्या में बहुत बार भागता हूं।
आज मैं एकांत स्थिति में नहीं हूं।

extends Resource
class_name WfcSlotHistory

func _init(slot:WfcSlot):
    pass

extends Resource
class_name WfcSlot

function saveHistory():
   var history:WfcSlotHistory = WfcSlotHistory.new(self)
   ...

res: //assets/wfc/WfcSlotHistory.gd : 5 - पार्स त्रुटि: वर्ग "WfcSlot" पूरी तरह से लोड नहीं किया जा सकता (स्क्रिप्ट त्रुटि या चक्रीय निर्भरता)।
मॉड्यूल / gdscript / gdscript। cpp: 576 - विधि विफल रही। लौटकर: ERR_PARSE_ERROR

@ मायकेस्कुलेज़ इस मामले में, मुझे ऐसा लगता है कि यह आंशिक रूप से एक डिज़ाइन मुद्दा है: WfcSlot शायद WfcSlotHistory बारे में नहीं जानना चाहिए। save क्रिया संभवतः बाद की होनी चाहिए।

(यह व्यवहार / बग _is_ कष्टप्रद है, हालांकि, मुझे गलत नहीं लगता।)

@ Jeto143 आपकी प्रतिक्रिया के लिए धन्यवाद, मैंने SlotHistory में सभी स्लॉट सदस्यों को मैनुअल कॉपी करके मेरी समस्या हल कर दी।
उम्मीद है कि यह बग सुलझ जाएगा

हाय देवों जब यह लंबा ... लंबा बग आखिरकार हल हो जाएगा?

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

मैं इस तरह एक वर्ग है (उदाहरण उदाहरण)
`` ``
संसाधन बढ़ाता है
class_name क्लास ए

_init (valueA: int, valueB: int):
प्रिंट (valueA, valueB)

स्थिर कवक (मूल्य: int) -> वर्ग:
वापसी ClassA.new (मूल्य, मूल्य)
`` ``

`` ``
var o: ClassA = ClassA.new (1,2) # ठीक काम कर रहा है

var o2: ClassA = ClassA.of (2) # त्रुटि पैदा करता है

`` ``

स्थैतिक कवक के उपयोग से यह त्रुटि उत्पन्न होती है।
"पार्सर त्रुटि: वर्ग फ़ाइल में अपने नाम का उपयोग करने की अनुमति नहीं है (चक्रीय संदर्भ बनाता है)"

इसलिए यह मुझे कई कंस्ट्रक्टर का उपयोग करने के लिए एक वर्ग लिखने के लिए ब्लॉक करता है जहां आधुनिक भाषाओं में मानक व्यवहार होता है।

मैं इस तरह से एक हैकी वर्कअराउंड का उपयोग करता हूं
`` `
स्थिर कवक (मूल्य: int) -> वर्ग:
var clazz = load ("res: //..//ClassA.gd")
वापसी clazz.new (मूल्य, मूल्य)
`` ``

सादर
माइक

हाय देवों जब यह लंबा ... लंबा बग आखिरकार हल हो जाएगा?

इसे 4.0 में GDScript रीराइट के भाग के रूप में हल किया जाएगा।

क्या स्थैतिक कार्यों के लिए यह काम ठीक होगा?

class_name Cls

static func f():
    print(Cls)

@ तो हम 3.2.X रिलीज पर हैं, क्या हम जल्द ही किसी भी समय सुधार की उम्मीद कर सकते हैं?

@ Ploppy3 ये सुधार बड़े पैमाने पर बदलावों के कारण हैं जो GDScript के पुनर्लेखन के साथ आते हैं और संभवत: उन्हें चेरी-पिक करना संभव नहीं है। यदि आप इन सुधारों को करना चाहते हैं, तो आपको 4.0 पर अपग्रेड करना होगा।

मेरे पास यह मुद्दा है और साथ ही यहां मेरी दो स्क्रिप्ट्स भी हैं।

class_name Entity extends Area2D

export var resource : Resource

onready var sprite   = get_node("sprite")
onready var collider = get_node("collider")

func _process(delta: float) -> void:
    if sprite   == null: sprite   = get_node("sprite")
    if collider == null: collider = get_node("collider")
    if resource is EntityConfig:
        sprite.frame = wrapf(sprite.frame+resource.gfx_speed, resource.gfx_start, resource.gfx_start+resource.gfx_count)

class_name EntityConfig extends Resource

export var gfx_image   := ""
export var gfx_start   := 0
export var gfx_speed   := 1.0
export var gfx_count   := 0
export var gfx_xoffset := 0.0
export var gfx_yoffset := 0.0
export var gfx_xsize   := 16.0
export var gfx_ysize   := 16.0
export var hit_xoffset := 0.0
export var hit_yoffset := 0.0
export var hit_xsize   := 16.0
export var hit_ysize   := 16.0

func new()->Area2D:
    var entity = Entity.new()
    entity.sprite            = Content.load_texture(gfx_image)
    if entity.sprite != null:
        entity.sprite.frame      = gfx_start
        entity.sprite.position.x = gfx_xoffset
        entity.sprite.position.y = gfx_yoffset
        entity.sprite.hframes    = entity.sprite.texture.get_width () / gfx_xsize
        entity.sprite.vframes    = entity.sprite.texture.get_height() / gfx_ysize

    entity.collider.position.x      = hit_xoffset
    entity.collider.position.y      = hit_yoffset
    entity.collider.shape.extents.x = hit_xsize / 2
    entity.collider.shape.extents.y = hit_ysize / 2
    return entity

मैंने गोडोट 3.2.3 में अपने कैपस्टोन समूह परियोजना पर काम करते समय इस समस्या का पता लगाया। हमारी टक्कर कॉलबैक के लिए, हमारे पास कुछ इस तरह है:

extends Area2D

func _on_Throwable_body_entered(body: Node) -> void:
    if body is Player:
        if body.pick_up():
            queue_free()

इसलिए हम प्लेयर-विशिष्ट तरीकों को कॉल करने से पहले if body is Player जांच करना चाहते हैं। समस्या यह है कि, Player हो सकता है या उपलब्ध नहीं भी हो सकता है, भले ही वैश्विक दायरे में, चाहे class_name या preload -ed के माध्यम से घोषित किया गया हो। यह तब भी होता है जब Player हमारी स्क्रिप्ट को स्पष्ट परिपत्र निर्भरता का कारण नहीं बता रहे हों।

वर्तमान में हम यह सुनिश्चित करके काम कर रहे हैं कि Player Area2D टक्कर के मुखौटे में एक ही चीज़ है और कोड में कुछ भी जाँच नहीं है। सबसे पहले हम if body.name == "player" चेक कर रहे थे।

मुझे यह जानकर खुशी हुई कि इस पर काम किया जा रहा है, भले ही इसमें काफी समय लग रहा हो, और मुझे आशा है कि सब ठीक हो जाएगा।

मेरे पास एक समान निर्भरता का मुद्दा था जब मुझे एक स्थिर पद्धति का उपयोग करके बिल्डर पैटर्न को लागू करने से रोका गया था:

class_name MyClass

static func build() -> MyClass:
  var new_instance  = MyClass.new()
  ...
  return new_instance

स्रोत फ़ाइल पथ से कक्षा को लोड करने के लिए यहाँ वर्णित समाधान अच्छा है, लेकिन स्रोत कोड को बदले बिना फ़ाइल ट्री को बदलने की आवश्यकता नहीं है।

मैं इस तरकीब का उपयोग वर्तमान स्रोत फ़ाइल पथ को स्थिर विधि में भी करता हूँ (जिसमें get_script () उपलब्ध नहीं है):

static func build() :
    var new_instance = load(GodotExt.current_script_path()).new()
    ...
    return new_instance

साथ में

class_name GodotExt

static func current_script_path():
    return get_stack()[1].source    <- return usable script path

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

हाय @AliBouarab अच्छी चाल