वास्तव में आपकी पोस्ट पसंद आई।

संपादित करें:
धिक्कार है इस पैराग्राफ की अनदेखी

स्रोत स्तर पर संशोधन वांछित होने पर फ़ाइलों को वास्तव में प्रोजेक्ट में कॉपी करने का एक तरीका है। इसके बाद ही फाइलों को प्रोजेक्ट फोल्डर में ही लाया जाना चाहिए। "क्लोन की गई" संपत्तियां .custom जैसे किसी छिपे हुए फ़ोल्डर में रह सकती हैं।

तो आपने मूल रूप से मेरी चिंताओं को कवर किया है। (क्षमा मांगना)
मैं अभी और गहराई में जाता हूं कि मैं वर्कफ़्लो + व्यवहार की कल्पना कैसे करता हूं।

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

यदि संपत्ति .local/godot/assets फ़ोल्डर में छिपी होगी तो यह कार्यक्षमता खो जाएगी।

प्रस्ताव

संपत्तियां अभी भी संपादक फ़ाइल ब्राउज़र में दिखाई और सूचीबद्ध होनी चाहिए। स्वतंत्र अगर वे .local/godot/assets फ़ोल्डर या प्रोजेक्ट फ़ोल्डर के अंदर हैं। तो आप फ़ाइलों को ब्राउज़ कर सकते हैं और समझ सकते हैं कि यदि कोई उचित दस्तावेज नहीं है, या यदि आप इससे सीखना चाहते हैं तो यह कैसे काम करता है।
प्रत्येक फ़ोल्डर जो 'एसेट' है, उसे भी किसी प्रकार के आइकन के साथ एक के रूप में चिह्नित किया जाना चाहिए ताकि आपके पास एक सिंहावलोकन हो कि एक संपत्ति क्या है और वास्तविक फाइलें कहाँ संग्रहीत हैं।
एक संपादक विंडो भी होनी चाहिए जो सभी संपत्तियों को सूचीबद्ध करती है। (एक टेबल में)

• डाउनलोड की गई सभी संपत्तियों को सूचीबद्ध करता है जिन्हें डाउनलोड किया गया था। उन्हें एक बटन के क्लिक के साथ आपके प्रोजेक्ट में जोड़ा जा सकता है। लेकिन इसके अलावा वे एसेट लिब में एसेट के समान हैं। यह सूची किसी भी परियोजना में समान होती है और परियोजना पर इसका कोई प्रभाव नहीं पड़ता है। (बस एक सिंहावलोकन करना आसान बनाता है। इस सूची को साफ़ करना और प्रोजेक्ट खोलते समय सभी संपत्तियों को फिर से डाउनलोड करना भी आसान है।)
• हमेशा सक्रिय (मूल रूप से प्रत्येक परियोजना के लिए "इस परियोजना में प्रयुक्त (सक्रिय/निष्क्रिय)" टॉगल करता है) उन संपत्तियों को आपकी मशीन पर प्रत्येक परियोजना में जोड़ा जाता है (यहां तक ​​​​कि नव निर्मित भी)। (हो सकता है कि संपत्ति को इसके लिए अनुमति देने की आवश्यकता हो।) वे वास्तव में संपादक उन्मुख हैं। कोने में एक घड़ी की तरह, git सपोर्ट, टूडू सूचियाँ या कुछ और डिफ़ॉल्ट संसाधन होने के लिए: (एक कस्टम वातावरण कुछ और थीम और प्रत्येक प्रोजेक्ट की शुरुआत में काम करने के लिए स्प्राइट्स का एक गुच्छा) ...
  उन्हें प्रति प्रोजेक्ट मैन्युअल रूप से निष्क्रिय किया जा सकता है।
  हालांकि वे अभी भी प्रोजेक्ट फाइल सिस्टम में सूचीबद्ध हैं और किसी भी अन्य assed/प्लगइन की तरह व्यवहार करते हैं। ताकि आप उनकी फाइलों को ब्राउज़ कर सकें और देख सकें कि वे कैसे काम करते हैं/वे क्या करते हैं।
• इस प्रोजेक्ट में प्रयुक्त (सक्रिय/निष्क्रिय) यह वास्तव में प्रोजेक्ट फ़ाइल सिस्टम में लिंक किए गए फ़ोल्डर को दिखाता है। और "जोड़ता है" (वे अभी भी .local/godot/assets फ़ोल्डर के अंदर हैं, लेकिन प्रोजेक्ट स्थानीय फ़ाइलों की तरह व्यवहार करते हैं।) प्रोजेक्ट के लिए फ़ाइलें।
  यहां आप यह भी चुन सकते हैं कि आप संपत्ति का कौन सा संस्करण सक्रिय करना चाहते हैं। और संस्करण स्विच करें।

जैसे ही आप किसी एसेट से किसी फाइल को एडिट/सेव/अपडेट करना चाहते हैं, आपको दो विकल्पों के साथ संकेत मिलता है

.local/godot/assets . में सेव करें

या तो संपत्ति को .local/godot/assets में अपडेट करें जो इसे एक कस्टम उपयोगकर्ता संस्करण में डालता है।
यह पैकेज-प्रबंधक गिट आधारित है, कस्टम उपयोगकर्ता संस्करण एक अतिरिक्त प्रतिबद्धता हो सकता है। जिसे आप जब भी सेव करते हैं तो commit --amend एड मिलता है।
(उदाहरण के लिए 3.2.5/user ) और आपकी सभी अन्य परियोजनाओं में भी उपलब्ध नहीं है। (उन अन्य परियोजनाओं में संस्करण को उपयोगकर्ता संस्करण में अपडेट करते समय)
यह उपयोगी क्यों है?
एसेट स्टोर की थीम लगभग एकदम सही है, लेकिन आप फ़ॉन्ट प्रकार से नफरत करते हैं...
फ़ॉन्ट प्रकार बदलें इसे एक नए संपत्ति संस्करण के रूप में सहेजें। अपने अन्य सभी प्रोजेक्ट पर फिर से जाएं और संपत्ति संस्करण को /user में बदलें। अब तुम खुश हो।
हो सकता है कि संपत्ति के उपयोगकर्ता संस्करण को प्रकाशित करने के लिए एक बटन भी हो।
तो एसेट स्टोर में अन्य पीपीएल के पास मामूली बदलाव के साथ एक उपयोगकर्ता संस्करण चुनने का विकल्प भी है।
एसेट गिट रेपो के लिए पीआर बनाने के लिए एक मध्यवर्ती के रूप में। (या एसेट के लेखक ने परिवर्तन को चुनने के लिए /user संस्करण को मास्टर पर एक नए संस्करण के रूप में चुना है।)

प्रोजेक्ट को लोकल बनाएं

वर्तमान प्रोजेक्ट में .local/godot/assets फ़ोल्डर से फ़ाइलों की प्रतिलिपि बनाता है... किसी भी विशेष संपत्ति व्यवहार (जैसे संस्करण...) को हटा देता है और अब आप इसके साथ गड़बड़ कर सकते हैं हालांकि आप चाहते हैं। (फ़ोल्डर भी संपत्ति के रूप में अपनी कस्टम उपस्थिति खो देता है।)

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

आकस्मिक विचार

यह आपकी अपनी स्थानीय संपत्ति/संसाधन lib/संग्रह के लिए भी एक अच्छा समाधान हो सकता है। .local/godot/assets में एक फ़ोल्डर आपको एक अच्छे संपादक ui के साथ और अपने OS फ़ाइल प्रबंधक में इसे खोजे बिना किसी भी Godot प्रोजेक्ट में इसकी सामग्री जोड़ने देता है।

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

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

एक नए पीआर पर हम खुद से पहला सवाल पूछते हैं कि क्या यह एक प्लगइन नहीं होना चाहिए? लेकिन क्या इसका उपयोग कोर में होने के लिए पर्याप्त रूप से किया जा रहा है? .

प्लगइन्स में चीजें होने में समस्याएं हैं:

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

उदाहरण:

• स्प्रिंग आर्म नोड। (https://github.com/godotengine/godot/pull/18822) यथोचित रूप से छोटा जोड़, अपनी कक्षा में अलग किया गया है, इसलिए चीजों को तोड़ना नहीं चाहिए, कई 3D गेम द्वारा उपयोग किया जाएगा, यदि प्रत्येक तीसरे व्यक्ति गेम द्वारा नहीं । उत्तर: एक प्लगइन होना चाहिए।
• यहां तक ​​कि आरएनजी सामान के लिए भी इसे प्लगइन के रूप में रखने पर चर्चा की गई। मानो 90% खेलों को कहीं RNG की आवश्यकता नहीं है।

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

@karroffel यह एक उत्कृष्ट पोस्ट है और मैं आपके द्वारा कही गई हर बात से सहमत हूं। हालाँकि, मैं इस बिंदु पर टिप्पणी करना चाहूंगा:

एसेट संबद्ध संस्करण के साथ सहेजे जाते हैं, सभी .local/godot/assets या कुछ इसी तरह में संग्रहीत होते हैं। वे अब स्वयं परियोजना का हिस्सा नहीं हैं बल्कि व्यापक रूप से उपलब्ध प्रणाली का हिस्सा हैं।

यह पाइथन पाइप सिस्टम के काम करने के समान है। तब लोगों ने महसूस किया कि पैकेज के नवीनतम संस्करण ने आपके सिस्टम में आपके पास मौजूद अन्य प्रोजेक्ट्स को खराब कर दिया है। वर्चुअलएन्व उस समस्या को हल करता है। जावास्क्रिप्ट के npm पारिस्थितिकी तंत्र में, मॉड्यूल स्थानीय रूप से एक परियोजना के लिए डिफ़ॉल्ट रूप से स्थापित होते हैं और सिस्टम वाइड एक ऑप्ट-इन सुविधा ( npm install --global ) है। फिर आप यह सुनिश्चित करने के लिए अपने package-lock.json को स्रोत नियंत्रण में जांचते हैं कि टीम में हर कोई प्रत्येक npm मॉड्यूल के समान संस्करण का उपयोग करता है और संघर्षों से बचता है।

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

अगर हम सिस्टम वाइड रूट पर जाते हैं, तो मैं सुझाव दूंगा कि वर्जन पिनिंग रखें। उदाहरण के लिए:

.local/godot/assets/fsm/1.0
.local/godot/assets/fsm/1.1

प्रोजेक्ट ए fsm-1.0 का उपयोग कर सकता है जबकि प्रोजेक्ट B fsm-1.1 का उपयोग करता है। प्रोजेक्ट सी साथ आता है और या तो पुन: उपयोग कर सकता है। उपयोगकर्ता अपनी dependencies.json फ़ाइलों या न्यूनतम पैच, लघु या प्रमुख संस्करणों में प्लग इन के विशिष्ट संस्करणों को निर्दिष्ट करने में सक्षम होना चाहिए।

एक बार निर्भरता डाउनलोड हो जाने के बाद, एक dependencies-lock.json फ़ाइल उत्पन्न की जा सकती है और स्रोत नियंत्रण में जाँच की जा सकती है।

@mhilbrunner मैं निश्चित रूप से सहमत हूं, मुझे लगता है कि "यह एक प्लगइन होना चाहिए" मानसिकता को थोड़ा कठिन धक्का दिया जाता है, बिल्कुल उन स्थितियों ने उन विचारों को जन्म दिया। मुझे लगता है कि स्प्रिंगआर्म जैसी अधिक सामान्य चीजें इंजन में होने के योग्य हैं, साथ ही InterpolatedCamera , जिसे जुआन हटाना चाहता है, बेहद उपयोगी और अच्छा है! यहां तक ​​​​कि सोचा कि वे चीजें कोड की केवल कुछ पंक्तियां हैं, उन्हें सही होने में कुछ समय लगता है, इसलिए "यह बहुत छोटा है" भी एसेट लाइब्रेरी की ओर बढ़ने का एक बुरा औचित्य है।

मेरे विचार ज्यादातर केंद्रित थे "ठीक है, प्रोजेक्ट लीड ने कहा कि यह ऐसा ही है, तो नई स्थिति को बेहतर बनाने के लिए क्या किया जा सकता है?"

मैं चाहूंगा कि प्लगइन्स के रूप में सुविधाओं की भारी धक्का-मुक्की थोड़ी कम हो जाए, लेकिन किसी भी तरह से मुझे लगता है कि प्रस्तुत किए गए परिवर्तन बहुत मदद करेंगे!

@saltares हाँ वह मेरा विचार था। मैं रस्ट के लिए कार्गो का बहुत बड़ा प्रशंसक हूं। यह काफी हद तक समान रूप से संचालित होता है। पुस्तकालयों को एक सिस्टम वाइड फ़ोल्डर में उन सभी संस्करणों में स्थापित किया जाता है जिनकी स्थानीय रूप से कभी आवश्यकता होती थी। विवरण एक फ़ाइल में है और एक विशिष्ट कॉन्फ़िगरेशन .lock फ़ाइल में है, यह बहुत बढ़िया काम करता है!

मुझे खुशी है कि इसने पहले से ही कुछ चर्चाओं को जन्म दिया: ब्लश:

यहाँ उपरोक्त बिंदुओं पर मेरा विचार है:

इंजन से सामान बाहर निकालना

इंजन के बाहर सामान धकेलना आईएमओ जाने का रास्ता है। ऐसे बहुत से प्लेटफॉर्म हैं जहां आकार के मायने रखता है (मोबाइल, एचटीएमएल 5) और ब्लोट गोडोट के आकार की परियोजना के लिए एक बड़ी चिंता है, इसलिए हम सब कुछ शामिल करके खुश नहीं हो सकते हैं।

मेरे लिए दर्शन यह होना चाहिए कि कुछ इंजन का हिस्सा तभी होना चाहिए जब नीचे दिए गए सभी मानदंड पूरे हों:

1. यह अपेक्षाकृत अक्सर प्रयोग किया जाता है
2. खुद करना मुश्किल है
3. इस सुविधा को करने का केवल एक ही तरीका है

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

इसके बारे में मुख्य चिंता यह है कि, अगर कुछ आधिकारिक नहीं है तो उसे बनाए नहीं रखा जाएगा। यहीं आप लोग गलत हैं।

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

एक्सटेंशन को इंजन के हिस्से जैसा महसूस होना चाहिए

इन बिंदुओं के संबंध में:

• कस्टम नोड्स का विस्तार करना आसान बनाएं, क्रॉस-लैंग्वेज स्क्रिप्ट इनहेरिटेंस की अनुमति दें

मैं इसके बहुत सख्त खिलाफ हूं। ऐसा करने का कोई व्यावहारिक लाभ नहीं है, और कार्यान्वयन लागत बहुत महंगी है। क्षमा करें दोस्तों, मुझे पता है कि यह एक अच्छी सुविधा की तरह लगता है लेकिन इसके लिए भार लागत/लाभ/जोखिम बहुत नकारात्मक पक्ष पर है।

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

यदि एक एक्सटेंशन से एक नया नोड जोड़ा जाता है, और एक स्क्रिप्ट के साथ किया जाता है, तो इसे बनाएँ संवाद में भी दिखाया जाना चाहिए।

• स्क्रिप्ट संलग्न करते समय स्क्रिप्ट विरासत का सुझाव नहीं दिया जाता है - उन मामलों के लिए ओवरराइड डिफ़ॉल्ट है।

इसे निश्चित रूप से करने की आवश्यकता है और यह एक बहुत ही स्वागत योग्य अतिरिक्त होगा।

• संपत्ति के सिस्टम वाइड इंस्टॉलेशन के साथ उचित निर्भरता प्रबंधन जोड़ें। संशोधन के लिए उन्हें वापस लाने के तरीके के साथ ही परियोजना से एडॉन्स को हटा दें

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

• संपत्ति के मामले में सुपर लंबे पथ से बचने के लिए स्क्रिप्ट को वर्ग के नाम और नामस्थान द्वारा संदर्भित करने की अनुमति दें।

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

इसके बारे में मेरी भावना यह है कि यह या तो शानदार काम कर सकता है, या इसके परिणामस्वरूप पूरी तरह से गड़बड़ और ऐड-ऑन हो सकते हैं जो बिना किसी स्पष्ट कारण के टूट जाते हैं।

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

इस टिप्पणी की लंबाई अधिक होने के कारण इसे संक्षिप्त अनुभागों में विभाजित किया गया है।

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

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

इंजन के बाहर सामान धकेलना आईएमओ जाने का रास्ता है। ऐसे बहुत से प्लेटफॉर्म हैं जहां आकार के मायने रखता है (मोबाइल, एचटीएमएल 5) और ब्लोट गोडोट के आकार की परियोजना के लिए एक बड़ी चिंता है, इसलिए हम सब कुछ शामिल करके खुश नहीं हो सकते हैं।

मैं सहमत हो सकता हूं कि ब्लोट एक चिंता का विषय है, लेकिन जब मैं देखता हूं कि आप अब तक क्या हटाना चाहते हैं, तो मैं खुद से पूछता हूं कि क्या यह वास्तव में इसके लायक है कि उस सामान को हटा दिया जाए। यहां तक ​​कि अगर आप वाहन, इंटरपोलेटेड कैमरा, आदि जैसे नोड्स को हटा देते हैं ... तो फ़ाइल के आकार में कितना अंतर होगा? शायद आधा मेगाबाइट? शायद कुछ मेगाबाइट? भले ही यह कई मेगाबाइट की बचत करता हो, फिर भी 35MB डाउनलोड और 45MB डाउनलोड में क्या अंतर है? खेल की संपत्तियां उस 10MB शून्य को जल्दी से भर देंगी! जब तक आप आधे इंजन को हटाने की योजना नहीं बनाते, मुझे बात समझ में नहीं आती।

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

अब निश्चित रूप से हम हमें दिए गए हर एक सुझाव को शामिल नहीं कर सकते...

1. यह अपेक्षाकृत अक्सर प्रयोग किया जाता है
2. खुद करना मुश्किल है
3. इस सुविधा को करने का केवल एक ही तरीका है

... और ये दिशानिर्देश इंजन में क्या अनुमति दी जानी चाहिए, इसकी जांच के लिए एक महान प्रारंभिक बिंदु हैं। इसमें कोई संदेह नहीं है कि इश्यू ट्रैकर के माध्यम से आने वाले प्रत्येक फीचर अनुरोध के लिए सभी तीन बिंदुओं पर पहले से ही विचार किया जा रहा है।

कुछ इंजन का हिस्सा तभी होना चाहिए जब नीचे दिए गए सभी मानदंड पूरे हों

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

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

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

tl; dr : दिशानिर्देश बहुत अच्छे होते हैं जब उनका उपयोग दिशानिर्देशों के रूप में किया जाता है न कि चेकलिस्ट के रूप में।

इसके बारे में मुख्य चिंता यह है कि, अगर कुछ आधिकारिक नहीं है तो उसे बनाए नहीं रखा जाएगा। यहीं आप लोग गलत हैं।

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

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

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

• अगर हम उन्हें GDscript में कनवर्ट करते हैं, तो वह GDscript की सभी सीमाओं के साथ आने वाला है। अतिरिक्त चाइल्ड नोड्स के संभावित ओवरहेड जैसी सीमाएं (विशेषकर यदि आप उपयोगकर्ता को इस प्रथम-पक्ष नोड को एक दृश्य के रूप में आयात करने के लिए कह रहे हैं), अपनी कक्षाओं को संदर्भित करने के लिए वर्ग नामों के बजाय पथ का उपयोग करना (हालांकि आपने इसे संबोधित किया है, यह लगता है, लेकिन मुझे लगता है कि मुझे इसे ऊपर लाने की आवश्यकता है), कम प्रदर्शन (चाहे कितना कम अंतर हो, यह अभी भी कम है), आदि। यह सी ++ से थोड़ा अधिक आदर्श है क्योंकि आप फिर से संकलन से चले गए हैं ड्रैग-एन-ड्रॉप, लेकिन ...

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

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

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

वैसे, मैं प्रति नोड समर्थन के लिए एकाधिक स्क्रिप्ट लागू करना पसंद करता हूं
क्रॉस लैंग्वेज इनहेरिटेंस के बजाय। पूर्व सिर्फ एक दो पंक्तियाँ है
कोड का ..

सूर्य पर, 10 जून 2018 को 13:51 बजे PLyczkowski [email protected] ने लिखा:

इसके बारे में मेरी भावना यह है कि यह या तो शानदार काम कर सकता है, या इसके परिणामस्वरूप a
पूर्ण गड़बड़ी और ऐड-ऑन जो बिना किसी स्पष्ट कारण के टूट जाते हैं।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।

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

प्रति नोड एकाधिक स्क्रिप्ट का दो बार प्रयास किया गया है और हमेशा असफल रहा है।

जो प्रयास किया गया वह मल्टीस्क्रिप्ट नोड है, लेकिन यह एक परेशानी थी

सूर्य पर, 10 जून 2018 को 15:01 पर Zireael07 [email protected] ने लिखा:

प्रति नोड एकाधिक स्क्रिप्ट को दो बार और हमेशा करने का प्रयास किया गया है
असफल।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।

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

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

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

एस्कोरिया जैसे फ्रेमवर्क इससे बहुत लाभान्वित हो सकते हैं, और आरपीजी, प्लेटफॉर्मर्स, विजुअल नॉवेल आदि जैसी चीजों के लिए अन्य फ्रेमवर्क भी हो सकते हैं।

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

क्रॉस-लैंग्वेज इनहेरिटेंस मेरे लिए एक भयानक विचार की तरह लगता है।

जिस काम में मैं संपादकडेटा में टाइपडीबी के साथ कर रहा हूं, मैं एक नामस्थान-टाइपनाम को फ़ाइलपथ हैश मैप में रख रहा हूं जो संशोधन पर प्रोजेक्ट सेटिंग्स में एक शब्दकोश में परिवर्तित हो जाता है। मेरी शाखा में, GDScript पार्सर और कंपाइलर इस डेटा का उपयोग प्रकारों के लिए वैश्विक नाम बनाने के लिए कर रहे हैं। इस समय, मुझे कस्टम प्रकार की स्क्रिप्ट दिखाई दे रही हैं। स्क्रिप्ट उन्हें नाम से एक्सेस और इनहेरिट कर सकती हैं। साथ ही, यह डेटा ऐसी किसी भी चीज़ के लिए पहुंच योग्य है जो ProjectSettings देख सकती है। तो संपादक द्वारा देखा गया एक CSharpScript एक मैपिंग उत्पन्न कर सकता है जिसे ProjectSettings Dictionary में दर्ज किया गया है, जिससे C# में घोषित प्रकारों को GDScript तक पहुँचा जा सकता है। प्रोजेक्टसेटिंग डिक्शनरी डेटा को सी # ऑब्जेक्ट में लपेटने का एक तरीका भी है जो स्क्रिप्ट ऑब्जेक्ट्स को एक्सेस करते समय लौटाता है, इस तरह सी # जीडीस्क्रिप्ट प्रकारों को नाम से भी एक्सेस करने में सक्षम होगा।

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

मुझे क्रॉस-भाषा स्क्रिप्ट विरासत में सक्षम होने के लिए @karroffel का सुझाव पसंद है (हालांकि यह भी नहीं पता कि यह संभव होगा)। किसी भी तरह से स्वचालित रूप से डुप्लिकेट विधियां जो बेस स्क्रिप्ट पर कॉल प्रतिनिधि करती हैं और सभी समान गुणों/संकेतों/स्थिरांक इत्यादि को भी परिभाषित करती हैं।

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

मैं जो टाइपडीबी सिस्टम बना रहा हूं, वह इसके लिए संपादक का समर्थन भी देगा...

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

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

चूंकि मैं इस प्रस्ताव की विचार प्रक्रिया का हिस्सा रहा हूं, इसलिए मैं कुछ बातें बताना चाहता हूं:

गोडोट की मेरी दृष्टि

TLDR: मैं गोडोट की कल्पना एक ऐसे उपकरण के रूप में करता हूं जिसे बहुत ही आसान, मॉड्यूलर और शुरुआती अनुकूल तरीके से संपत्ति और प्लगइन्स के साथ बढ़ाया जा सकता है।

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

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

मैं कल्पना करता हूं कि उपयोगकर्ता प्लगइन्स और संपत्तियों को डाउनलोड करने में सक्षम हैं जो महसूस करते हैं कि वे इंजन को "विस्तारित" कर रहे हैं: आप जो डाउनलोड कर रहे हैं उसके आधार पर, आपके पास गोडोट-एफपीएस या गोडोट-प्लेटफार्म या गोडोट-रेसिंग है।

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

लाभ

TLDR: यह दृष्टिकोण गोडोट प्रबंधन को इंजन के फूलने के बारे में बहुत अधिक चिंता किए बिना अलग से कट्टर तकनीकी मुख्य विशेषताओं और अधिक उपयोगकर्ता के अनुकूल प्लगइन्स का प्रबंधन करने की अनुमति देगा।

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

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

बहुभाषी विरासत के बारे में

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

प्रयोज्यता के बारे में नोट

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

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

अब वह भी एक और दिन की चर्चा है। अभी वर्तमान में तथ्य हैं,

1. गोडोट एक कॉम्पैक्ट, तेज और पोर्टेबल गेम इंजन है। और मुझे यह बहुत पसंद है, लेकिन ....
2. विभिन्न कारकों के आधार पर गोडोट का निष्पादन योग्य लगभग 45-60MB है। लेकिन निर्यात टेम्प्लेट 300MB जितना बड़ा हो सकता है। अब यह पहले बिंदु पर एक बड़ा झटका है।
3. गोडोट में बहुत सारी अद्भुत विशेषताएं हैं जो इसे शुरुआती लोगों के लिए एक इलाज बनाती हैं जैसे कैमरा फॉलो, लंबन बीजी और वाहन, यह अन्य समान गेम इंजनों पर एक बड़ा प्लस है। चूंकि यह गोडोट में गेम बनाना बहुत आसान बनाता है। और गोडोट को बहुत से नौसिखियों के लिए एक घर बनाता है, जिनके पास ऐसे उपकरणों के लिए अपने स्वयं के कार्यान्वयन को लिखने का कौशल नहीं है।

अब क्या होगा अगर हम उन सुविधाओं को हटा दें जिन्हें कुछ लोग ब्लोट मानते हैं। वैसे इंजन निश्चित रूप से अधिक कॉम्पैक्ट होगा लेकिन क्या इसकी आवश्यकता है? अगर यह मेरी ज़रूरतों को बेहतर तरीके से पूरा करता है तो मुझे 100MB इंजन डाउनलोड करने में कोई समस्या नहीं दिखती। लेकिन निर्यात के बारे में क्या, क्या 100MB इंजन बड़े खेलों का निर्यात नहीं करेगा?

शायद, हाँ, लेकिन ऐसी दुनिया में जहां डेस्कटॉप 256BG SSD + 1TB HDD से कम कुछ भी उपयोग नहीं करते हैं और यहां तक ​​कि फ़ोन में न्यूनतम 16GB से शुरू होने वाली जगह है, जिसमें से सभी बढ़ने की संभावना से अधिक है, क्या ऐसा होगा खराब?
मेरे कहने का मतलब है कि हमें अभी कुछ भी हटाने की जरूरत नहीं है, हमें बस कुछ चीजों को बेहतर तरीके से प्रबंधित करना शुरू करना है और यही होना चाहिए।
सुविधाओं में किसी प्रकार की महत्व सूची होनी चाहिए ताकि यह तय किया जा सके कि उन्हें मूल में होना चाहिए या नहीं, लेकिन इसका मतलब यह नहीं है कि यह एक कानून बन जाता है बल्कि अंगूठे का नियम बन जाता है।

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

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

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

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

क्रॉस-लैंग्वेज इनहेरिटेंस पॉइंट को कुछ स्पष्टीकरण की आवश्यकता है। न केवल मैं इसे एक बुरा विचार मानता हूं, बल्कि मैं यह भी नहीं देखता कि यह दूर से कैसे संभव है।

1. विभिन्न कारकों के आधार पर गोडोट का निष्पादन योग्य लगभग 45-60MB है। लेकिन निर्यात टेम्प्लेट 300MB जितना बड़ा हो सकता है। अब यह पहले बिंदु पर एक बड़ा झटका है।

300MB निर्यात टेम्पलेट्स? क्या आपका मतलब संपत्ति से है?

@neikeq बात यह है कि यदि आपकी पूरी परियोजना सी # में है लेकिन आप एसेट लाइब्रेरी से डाउनलोड किए गए कस्टम नोड का उपयोग कर रहे हैं तो वह नोड केवल एक नियमित नोड है, संभवतः केवल एक जीडीस्क्रिप्ट संलग्न है।

यदि आप नोड को "विस्तारित" करना चाहते हैं, तो आप नहीं कर सकते! मुझे लगता है कि आप नई कार्यक्षमता जोड़ने के लिए एक चाइल्ड नोड जोड़ सकते हैं, लेकिन इस तरह चीजों को ओवरराइड करना संभव नहीं है।

कार्यान्वयन

वर्तमान में स्क्रिप्टिंग भाषाएं विरासत में मिली कॉलों के लिए वास्तव में समान पैटर्न का उपयोग करती हैं जिन्हें सामान्यीकृत किया जा सकता है।

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdnative/nativescript/nativescript.cpp#L696 -L712

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/gdscript/gdscript.cpp#L638 -L651

https://github.com/godotengine/godot/blob/76875ba145c5745033d0a1c9fda2f4349e2509b3/modules/mono/csharp_script.cpp#L1175 -L1191

यहाँ पैटर्न है

Class *c = bottom;
while (c) {
    if (c->has_method(m)) {
        c->call(m);
        break;
    }
    c = c->base;
}

तो यह स्क्रिप्ट इनहेरिटेंस ट्री के नीचे से शुरू होता है और फिर ऊपरी स्तरों को कॉल करने का प्रयास करता है यदि ऐसी कोई विधि नहीं मिली है।

यदि प्रत्येक स्क्रिप्ट में भाषा-विशिष्ट विरासत संरचना के बजाय Ref<Script> parent_script होता, तो इसे सामान्यीकृत किया जा सकता था

if (this_class->has_method(m)) {
    this_class->call(m);
} else {
    // method not declared here, go to base class
    parent_script->call(m);
}

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

@neikeq इसे देखें,

@swarnimarun सभी प्लेटफार्मों के लिए निर्यात टेम्पलेट्स, सभी समर्थित मेहराब, डीबग और रिलीज, उनका आकार इंजन के "ब्लोट" के लिए पूरी तरह अप्रासंगिक है। हम केवल Linux X11 64-बिट रिलीज़ का समर्थन करने का निर्णय ले सकते हैं और यह फ़ाइल 20 MB की होगी...

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

जब हम शुरुआती उपयोगकर्ताओं को यही प्रदान करते हैं तो यह कैसे अप्रासंगिक है?

@ एकियन-एमजीए: निर्यात टेम्पलेट आकार मायने रखता है क्योंकि नोड्स को हटाने के लिए आपका तर्क था

परिनियोजन आकार मायने रखता है (मोबाइल, html5)

@swarnimarun @Zireael07 हां निर्यात टेम्प्लेट आकार व्यक्तिगत रूप से मायने रखता है, लेकिन मेरा कहना है कि टेम्प्लेट के बंडल के आकार को मापने से हमें कोई संकेत नहीं मिलता है। एक टेम्प्लेट का आकार (उदाहरण के लिए, wasm रिलीज़ टेम्प्लेट, 3.4 एमबी ज़िप्ड, या एंड्रॉइड रिलीज़ एपीके, आर्मव7 और x86 लिबास के साथ 23 एमबी ज़िप्ड) "350 एमबी लेता है" (+ शायद 10) की तुलना में बहुत अधिक प्रासंगिक है। विजुअल स्टूडियो के लिए जीबी अगर आपको कुछ बनाने की जरूरत है ...) क्या मायने रखता है अगर आकार मायने रखता है (वेब, मोबाइल) प्लेटफॉर्म पर एक न्यूनतम गेम किस आकार का होगा।

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

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

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

संपत्ति के सिस्टम वाइड इंस्टॉलेशन के साथ उचित निर्भरता प्रबंधन जोड़ें। संशोधन के लिए उन्हें वापस लाने के तरीके के साथ ही परियोजना से एडॉन्स को स्थानांतरित करें।

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

Res://addons की वास्तविक प्रणाली अच्छी है... उपयोगकर्ता के लिए निःशुल्क और कंप्यूटर के आसपास पोर्टेबल। यदि इस प्रणाली के बारे में कोई शिकायत नहीं है, तो क्या इसे बदलना आवश्यक है? ऐसी और भी बहुत सी चीज़ें हैं जिनसे उपयोगकर्ता वास्तव में शिकायत करते हैं...

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

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

@Ranoller विचार उन प्लगइन्स को प्रोजेक्ट के बाहर ले जाना है जिन्हें आपको संशोधित करने की आवश्यकता नहीं है । उदाहरण के लिए, InterpolatedCamera सिर्फ एक नोड होगा जिसे आप उपयोग करना चाहते हैं, इसके कोड को नहीं बदलें।

TODO सूचियों या git एकीकरण आदि जैसे संपादक-केवल प्लगइन्स के मामले में भी ऐसा ही हो सकता है। वे ऐसी चीजें हैं जिनका आप उपयोग करना चाहते हैं लेकिन बदलना नहीं चाहते हैं।

यह एक पैकेज मैनेजर की तरह है और पुस्तकालय हर भाषा में काम करते हैं जो सी और सी ++ नहीं है। आपके पास एक फ़ाइल है जो सभी निर्भरताओं को निर्दिष्ट करती है और फिर पैकेज प्रबंधक उन निर्भरताओं को लाएगा। यह तब भी होता है जब आप पीसी बदलते हैं - पैकेज मैनेजर कोई भी अभी तक मौजूद पैकेज डाउनलोड नहीं करेगा।

जब आप कुछ संशोधित करना चाहते हैं , तो आप कोड को प्रोजेक्ट में लाते हैं। फिर यह आपके गिट और प्रोजेक्ट में इसके सभी स्रोत कोड इत्यादि के साथ है। लेकिन यह हमेशा ऐसा नहीं होता है।

मेरा प्रस्ताव है कि परियोजना के बाहर की चीजें डिफ़ॉल्ट रूप से तब तक रखें जब तक आपको वास्तव में कुछ संशोधित करने की आवश्यकता न हो।

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

@karroffel लेकिन प्रत्येक भाषा में क्रॉस-लैंग्वेज इनहेरिटेंस कैसे काम करेगा? यह GDScript के लिए आसान हो सकता है, जो इंजन के साथ कसकर जुड़ा हुआ है, लेकिन यह सामान्य प्रयोजन की भाषाओं जैसे C# या GDNative के शीर्ष पर जोड़ी गई अन्य भाषाओं के लिए एक पूरी तरह से अलग कहानी है।
मैं गंभीरता से नहीं देख सकता कि यह कैसे हासिल किया जा सकता है, इससे भी कम यह कैसे अच्छा से ज्यादा बुरा नहीं कर सका।

आईएमओ आपके प्रोजेक्ट पर निर्भर ऐडऑन की सामग्री को संशोधित करना एक अच्छा विचार नहीं है। यदि किसी संशोधन की आवश्यकता है, तो एडऑन फ़ोल्डर के बाहर की सामग्री को कॉपी करें और वहां अपने परिवर्तन करें।

संपादित करें: या "कांटा" एडऑन

@neikeq जो आप संशोधित करते हैं वह आपके प्रोजेक्ट के अंदर है। जब आप किसी ऐडऑन को संशोधित करना चाहते हैं तो इसे आपके प्रोजेक्ट के अंदर कॉपी किया जाता है और केवल स्थानीय रूप से संशोधित किया जाता है।

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

@QbieShay क्या होगा यदि कोई अपडेट है जो आपके द्वारा संशोधित फ़ाइलों को संशोधित करता है?

@neikeq स्क्रिप्ट विरासत इस समस्या का समाधान नहीं है, यह सिर्फ एक होगा। जब आप किसी भिन्न प्रोग्रामिंग भाषा का उपयोग करना चाहते हैं, तो संलग्न स्क्रिप्ट के साथ नोड की कार्यक्षमता को ओवरराइड करने का कोई अच्छा तरीका नहीं है।

यदि हमारे पास Script API में विधियों को ओवरराइड करने का विकल्प होता तो वह भी अच्छा होता! (मूल रूप से बाहरी रूप से नई विधियों को परिभाषित करना और मौजूदा विधियों को ओवरराइड करना)।

@PLyczkowski यह एक सुझाव है जो उपयोगी भी होगा, लेकिन जो मैं प्रस्तावित करता हूं वह उस तक सीमित नहीं है - और एक कारण से।

आइए फिर से InterpolatedCamera उदाहरण लेते हैं। मैं इसके लिए स्रोत कोड को कभी नहीं छूऊंगा, मैं केवल इसका उपयोग करूंगा। मेरी परियोजना में स्रोत होने से बर्बाद हो जाएगा। इसके अलावा मेरे द्वारा बनाई गई अधिकांश परियोजनाएं सभी 3D हैं, इसलिए संभवत: मेरे सभी प्रोजेक्ट्स में उस कोड की प्रतिलिपि बनाई जाएगी।

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

प्रोजेक्ट के अंदर कुछ होना चाहिए और जब बाहर, संपादक या नहीं, तो कोई ब्लैक/व्हाइट लाइन नहीं है।

@neikeq

क्या होगा यदि कोई अद्यतन है जो आपके द्वारा संशोधित फ़ाइलों को संशोधित करता है?

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

विचार है

• प्रोजेक्ट के बाहर: अपडेट करना आसान, क्रॉस-प्रोजेक्ट होना आसान
• परियोजना के अंदर: अनुकूलन योग्य, संपत्ति की स्थिति खो देता है, कोई स्वचालित अपडेट नहीं

एक बार जब आप उन्हें अपने प्रोजेक्ट में कॉपी कर लेते हैं तो मूल रूप से वे सिर्फ नियमित फाइलें बन जाते हैं।

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

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

मेरे 2 सेंट वैसे भी।

@ ऐस-ड्रैगन

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

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

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

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

@ रानोलर हाँ, मुझे लगता है कि आपको उनके प्रस्ताव का सार मिल गया है।

आप लोग जो चर्चा कर रहे हैं उस पर कुछ प्रतिक्रिया

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

2) मुझे पैकेज मैनेजर और ऐड-ऑन के सिस्टम वाइड इंस्टाल का विचार पसंद नहीं है। मुझे लगता है कि यह एक भयानक विचार है और इससे कुछ भी सार्थक हासिल नहीं होता है। मैंने देखा है कि बड़ी परियोजनाओं में एक संपत्ति के संस्करण को अपडेट करने के लिए एकता डेवलपर्स के लिए भी कितना दर्दनाक है और सब कुछ टूट जाता है और इसे ठीक करने में दिन व्यतीत होता है।

3) मुझे पैकेज प्रबंधन का विचार ही पसंद नहीं है। मैंने देखा है कि एकता उपयोगकर्ता संपत्ति की दुकान से जो कुछ भी प्राप्त करते हैं उसे हैक कर लेते हैं और अधिकांश समय समाप्त नहीं होते हैं। बहुत बार वे इसे केवल आधार के रूप में उपयोग करते हैं, फिर उस पर काम करते हैं और इसे अपने स्वयं के उपयोग के लिए अनुकूलित करते हैं, क्योंकि आपको जो संपत्ति मिलती है वह उस तरह से केवल 60/70% है जहां आप इसे चाहते हैं .. या वे बस देखना चाहते थे यह कैसे किया जाता है और फिर बाद में अपना काम खुद करते हैं।

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

अगर हम लोगों को बिना किसी 3D सामान के निर्यात करने की अनुमति देते हैं तो हम कितना इंजन आकार कम कर सकते हैं? कई गेम (आधे? आधे से अधिक?) को 3D सुविधाओं की आवश्यकता नहीं होती है, लेकिन वे अभी भी उसी बाइनरी में बैठे हैं। मुझे पता है कि सैद्धांतिक रूप से प्रत्येक प्लेटफॉर्म पर मैक्रो के साथ खुद को फिर से संकलित किया जा सकता है, हालांकि, थोड़ा सा निवेश के साथ ...
इसके अलावा, इस विचार के बाद, यदि मॉड्यूल केवल "आंतरिक" गतिशील पुस्तकालय थे जो आधिकारिक इंजन के वितरण का हिस्सा हैं, तो इंजन में अधिक सुविधाओं को जोड़ना इस अर्थ में एक समस्या से कम होगा कि उन्हें वास्तविक आसान चुना जा सकता है (बस यही ), हालांकि इस तरह के गतिशील पुस्तकालयों का उपयोग कुछ प्लेटफार्मों (मुख्य रूप से मोबाइल और एचटीएमएल 5) के लिए थोड़ा बाधा हो सकता है। तो मॉड्यूल के लिए मैं समझूंगा कि GDNative को प्राथमिकता दी जाती है (ओह रुको ... इसमें वही समस्याएं हैं ^^)।

@reduz एकाधिक स्क्रिप्ट कैसे काम करेगी? और यह इंजन विस्तार में कैसे योगदान देगा? क्या आपने किसी मौजूदा अंक में अपने विचार की व्याख्या की? (पूछना क्योंकि इस धागे में इसे समझाना शायद बहुत अधिक है)

संपत्ति के सिस्टम वाइड इंस्टॉलेशन के साथ उचित निर्भरता प्रबंधन जोड़ें। संशोधन के लिए उन्हें वापस लाने के तरीके के साथ ही परियोजना से एडॉन्स को हटा दें

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

ब्लोट की चिंताओं के लिए, मैं इसके बजाय _modules_ पर अधिक नियंत्रण की सराहना करता हूं, और यह पहले से ही जनवरी 2018 पैट्रियन पोल पर मतदान किया गया था:

रोडमैप प्राथमिकता: छोटे बाइनरी आकार बनाने के लिए इंजन के संकलन भागों को ऑप्ट-आउट करने के अधिक विकल्प [3.1 के लिए अपेक्षित]

इस प्रस्ताव पर टिप्पणी करना मुश्किल है क्योंकि यह विभिन्न चीजों को छूता है और लोग विभिन्न पहलुओं पर टिप्पणी कर रहे हैं और विभिन्न मुद्दों को उठा रहे हैं।

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

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

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

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

उन आउटसोर्सिंग का लाभ यह है कि उन्हें नए इंजन संस्करण की प्रतीक्षा किए बिना सुधार और जारी किया जा सकता है। इसलिए बग्स को तुरंत ठीक किया जा सकता है, क्योंकि एक एक्सटेंशन के लिए एक नई रिलीज़ को पैक करना काफी सरल है।

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

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

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

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

फिर जो लोग इसे फायदेमंद समझते हैं वे इसका इस्तेमाल कर सकते हैं। यदि यह व्यापक हो जाता है और हर कोई इसका उपयोग कर रहा है, तो हमारे पास उपयोग के आंकड़े और उपयोगिता पर प्रतिक्रिया दोनों होंगे ताकि यह तय किया जा सके कि इसे बेस इंजन में पूरी तरह से एकीकृत किया जाए या नहीं।

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

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

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

@vnen यदि आप सभी संपत्तियों को नाम से संदर्भित करते हैं तो यह एक विरोधाभासी गड़बड़ी होगी। यह स्क्रिप्ट के लिए अधिक उपयुक्त है क्योंकि केवल प्रोग्रामर को अपनी कक्षाओं के लिए अद्वितीय नामों के साथ आना पड़ता है ताकि वे टाइप कर सकें और उनका उपयोग कर सकें (या शायद ही कभी, संसाधन)। अन्य चीजों के लिए, यदि हम रास्तों से छुटकारा पाते हैं, तो इसके लिए इसकी आवश्यकता होगी https://github.com/godotengine/godot/issues/15673 , जब तक कि आप नहीं चाहते कि कलाकारों, डिजाइनरों आदि को अपनी सभी संपत्तियों को विशिष्ट रूप से नाम देना पड़े (जो अभी भी नाम बदलने के मुद्दे के साथ आता है)।

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

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

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

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

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

स्क्रिप्ट नामकरण/कस्टम प्रकारों को अनुकूलित करने के लिए टाइपडीबी सामान के साथ गठबंधन करें, और मेरा मानना ​​​​है कि यह क्रॉस-भाषा स्क्रिप्ट-विरासत/मल्टीस्क्रिप्ट समस्या को छोड़कर सभी उल्लिखित समस्याओं को ठीक से संबोधित करेगा जो पूरी तरह से कुछ और है।

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

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

यह पैकेज मैनेजर के रूप में भी काम करता है, जहां पैकेज मैनेजर अब मानव क्यूरेटिंग प्लगइन बंडल है।

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

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

@Zylann

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

क्या उचित नामस्थान सामग्री के लिए यह एक बड़ा सौदा है? लेकिन यह यूआईडी हो सकता है, यह मेरे लिए ज्यादा मायने नहीं रखता जब तक कि यह पथ पर निर्भर नहीं है। यहां तक ​​​​कि पथ भी एक नाम की तरह है, क्योंकि संसाधनों को उनके आयातित समकक्ष में रीमैप किया जाता है ...

@QbieShay

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

यदि यह वास्तव में एक समस्या है, तो बहु-स्क्रिप्ट संभवतः सबसे सरल समाधान है। इसे अधिकतर #8546 में चर्चा के कारण हटा दिया गया था, लेकिन मुझे लगता है कि इसे बिना अधिक प्रयास के हल किया जा सकता है।

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

जिस चीज की अनदेखी की जाती है, लेकिन मेरी राय में लोगों द्वारा कोर इंजन में जोड़ने के लिए पूछने का एक कारण यह है: सभी प्लेटफार्मों के लिए इस चीज को संकलित करने वाला कौन है?

निश्चित रूप से एक जीडीस्क्रिप्ट प्लगइन के लिए यह कोई समस्या नहीं है, लेकिन एक सीपीपी प्लगइन के लिए यह एक बड़ी समस्या है।

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

तो मेरी राय में हमें पहले इस समस्या को हल करना होगा, और मुझे नहीं पता कि कैसे। क्या उदाहरण के लिए लिनक्स के माध्यम से सभी प्लेटफार्मों के लिए संकलन करना संभव है? यदि ऐसा है तो हम प्लगइन निर्माताओं और GDNative उपयोगकर्ताओं के लिए पहले से स्थापित लिनक्स वातावरण बनाने के लिए उबंटू इमेजर: https://www.maketecheasier.com/create-linux-distro/ जैसे कुछ का उपयोग कर सकते हैं।

क्या उदाहरण के लिए लिनक्स के माध्यम से सभी प्लेटफार्मों के लिए संकलन करना संभव है? यदि ऐसा है तो हम प्लगइन निर्माताओं और GDNative उपयोगकर्ताओं के लिए पहले से स्थापित लिनक्स वातावरण बनाने के लिए उबंटू इमेजर: https://www.maketecheasier.com/create-linux-distro/ जैसे कुछ का उपयोग कर सकते हैं।

नहीं (macOS और iOS बिल्ड को केवल macOS से संकलित किया जा सकता है), और मुझे नहीं लगता कि लोगों को एक लाइव Linux OS को बूट करने के लिए मजबूर करना GDNative लाइब्रेरी को एसेट लाइब्रेरी में अपलोड करने में सक्षम होना एक अच्छा विचार है।

हालाँकि, ट्रैविस CI और AppVeyor का उपयोग करके सभी प्लेटफार्मों के लिए संकलन करना संभव है, जिसे आप सार्वजनिक GitHub रिपॉजिटरी पर मुफ्त में सेट कर सकते हैं।

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

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

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

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

और स्टोर को ऑफ़लाइन उपयोग के लिए आधिकारिक बंडल की पेशकश करनी चाहिए (संपादक में ऑफ़लाइन स्टोर समर्थन के साथ)।

यदि किया जाता है, तो कई अन्य चीजों को आधिकारिक समर्थन (बग फिक्सिंग) और उपलब्धता (संस्करण अद्यतन) प्राप्त करने की आवश्यकता होगी।

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

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

और स्टोर को ऑफ़लाइन उपयोग के लिए आधिकारिक बंडल की पेशकश करनी चाहिए (संपादक में ऑफ़लाइन स्टोर समर्थन के साथ)।

हां, और ऑफलाइन पैकेज भी इंस्टॉल करना आसान होना चाहिए।

@reduz

मुझे पैकेज मैनेजर और ऐड-ऑन के सिस्टम वाइड इंस्टाल का विचार पसंद नहीं है। मुझे लगता है कि यह एक भयानक विचार है और इससे कुछ भी सार्थक हासिल नहीं होता है। मैंने देखा है कि बड़ी परियोजनाओं में एक संपत्ति के संस्करण को अपडेट करने के लिए एकता डेवलपर्स के लिए भी कितना दर्दनाक है और सब कुछ टूट जाता है और इसे ठीक करने में दिन व्यतीत होता है।

ठीक है, लेकिन क्यों ? आप इससे क्या वास्तविक सीमाएँ और मुद्दे देखते हैं? बिना यह कहे "मुझे यह पसंद नहीं है" कहना लोगों को यह समझाने वाला क्यों नहीं है कि यह एक अच्छा विचार नहीं है; आपको उल्लिखित अस्पष्ट कारणों के अलावा कम से कम कुछ स्पष्टीकरण देना चाहिए।

ठीक है, लेकिन क्यों? आप इससे क्या वास्तविक सीमाएँ और मुद्दे देखते हैं? बिना यह कहे "मुझे यह पसंद नहीं है" कहना लोगों को यह समझाने वाला क्यों नहीं है कि यह एक अच्छा विचार नहीं है; आपको उल्लिखित अस्पष्ट कारणों के अलावा कम से कम कुछ स्पष्टीकरण देना चाहिए।

सिस्टम पर वैश्विक "ऐडऑन" रजिस्ट्री मानकर:

• ऑनलाइन ऐड-ऑन सिस्टम से एडऑन v1.3 डाउनलोड करें। Addon ~/.godot पर स्थापित है या क्या नहीं
• संस्करण किसी प्रकार के स्थानीय स्टोर (फ़ाइल, स्क्लाइट, आदि) में ~/my-project पर मेरे प्रोजेक्ट से संबद्ध हो जाता है।
• मैं v1.4 में अपग्रेड करता हूं। अब मेरे एडऑन मैनेजर को यह जानना है कि 1.3 किसी भी प्रोजेक्ट द्वारा उपयोग नहीं किया जाता है और इसे साफ करें। तो प्रबंधक के पास निर्भरताओं को ट्रैक करने के लिए अतिरिक्त कार्यक्षमता है और किन परियोजनाओं में निर्भरताएं हैं। वैकल्पिक रूप से कोई भी इस कार्यक्षमता को नहीं जोड़ता है इसलिए मेरी स्थानीय मशीन एक ही एडऑन के कई संस्करणों के साथ प्रदूषित हो जाती है
• मैं तय करता हूं कि मैं अपनी परियोजना को ~/big-project/game पर ले जाना चाहता हूं। अब मुझे एडऑन रजिस्ट्री में अपने प्रोजेक्ट के संदर्भ को अपडेट करने का एक तरीका चाहिए। मैं उसको कैसे करू? क्या मुझे एडऑन मैनेजर को अलग से चलाना होगा? Manager register new_proj_location ?
• अब निर्भरता को स्थानीय रूप से requirements.txt अजगर शैली में संग्रहीत करने का निर्णय लिया गया है। बढ़िया, समस्या हल हो गई। सिवाय मैं यह जानने के लिए वापस नहीं आया कि कौन सी परियोजनाएं वैश्विक पैकेजों पर निर्भर करती हैं, मुझे गोडोट परियोजनाओं के लिए सिस्टम स्कैन करना होगा या संस्करणों को जमा करने से बचने के लिए प्रत्येक प्रोजेक्ट को अभी भी पंजीकृत करना होगा।
• ठीक है, मैं बस इस मुद्दे के आसपास काम करता हूँ। समय-समय पर मृत पैकेजों को मैन्युअल रूप से साफ करें। इसलिए मैं v1.5 का उपयोग करके अपने प्रोजेक्ट के लिए VehicleBodyAddon पर काम कर रहा हूं। उह, यह त्वरण गणना के लिए एफ * एम करता है लेकिन मैं एफ * एम * 5 करना चाहता हूं। मुझे कोड को जल्दी से संशोधित करने दें ... ओह, मेरे अन्य सभी प्रोजेक्ट उस एडऑन को चला रहे हैं।
• मुझे एक नया ऐडऑन बनाने दें जो दूसरे एडऑन पर निर्भर करता है। हम्म अब मुझे यह पंजीकृत करने की आवश्यकता है कि मेरा नया कस्टम एडऑन मौजूदा पर निर्भर करता है। अब मुझे न केवल दूरस्थ स्थान से ऐडऑन डाउनलोड करने के लिए, बल्कि स्थानीय रास्तों या गिट रिपॉजिटरी या कुछ और के साथ काम करने के लिए प्रबंधक का विस्तार करने की आवश्यकता है।

"विक्रेता" एडॉन्स मानते हुए:

• एडऑन को एडऑन डायरेक्टरी में डाउनलोड करें
• निर्देशिका में ओवरराइड एडऑन को अपडेट करना

तो प्रबंधक के पास निर्भरताओं को ट्रैक करने के लिए अतिरिक्त कार्यक्षमता है और किन परियोजनाओं में निर्भरताएं हैं। वैकल्पिक रूप से कोई भी इस कार्यक्षमता को नहीं जोड़ता है इसलिए मेरी स्थानीय मशीन एक ही एडऑन के कई संस्करणों के साथ प्रदूषित हो जाती है

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

मैं तय करता हूं कि मैं अपनी परियोजना को ~/big-project/game पर ले जाना चाहता हूं। अब मुझे एडऑन रजिस्ट्री में अपने प्रोजेक्ट के संदर्भ को अपडेट करने का एक तरीका चाहिए।

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

अब निर्भरता को स्थानीय रूप से requirements.txt अजगर शैली में संग्रहीत करने का निर्णय लिया गया है। बढ़िया, समस्या हल हो गई। सिवाय मैं यह जानने के लिए वापस नहीं आया कि कौन सी परियोजनाएं वैश्विक पैकेजों पर निर्भर करती हैं, मुझे गोडोट परियोजनाओं के लिए सिस्टम स्कैन करना होगा या संस्करणों को जमा करने से बचने के लिए प्रत्येक प्रोजेक्ट को अभी भी पंजीकृत करना होगा।

इस प्रकार के ऐड-ऑन सिस्टम के लिए एक पायथन-शैली की आवश्यकताएँ.txt एक बढ़िया विकल्प होगा। इस तरह यदि परियोजना को वास्तव में कुछ पुराने संस्करण की आवश्यकता है (लेकिन फिर से, आप अक्सर नवीनतम संस्करण चाहते हैं), तो हम इसे निर्दिष्ट कर सकते हैं, और यदि ऐड-ऑन प्रबंधक उस पुराने संस्करण को हटा देता है, तो यह जान सकता है इसे बाद में फिर से डाउनलोड करने के लिए।

इसलिए मैं v1.5 का उपयोग करके अपने प्रोजेक्ट के लिए VehicleBodyAddon पर काम कर रहा हूं। उह, यह त्वरण गणना के लिए एफ * एम करता है लेकिन मैं एफ * एम * 5 करना चाहता हूं। मुझे कोड को जल्दी से संशोधित करने दें ... ओह, मेरे अन्य सभी प्रोजेक्ट उस एडऑन को चला रहे हैं।

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

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

गिट उप-मॉड्यूल। एक और आवश्यकताएँ। txt (जैसे कि अजगर क्या करता है)। या बस उपयोगकर्ता को बताएं कि इसके लिए ऐड-ऑन एक्स की आवश्यकता है। यह उतना कठिन नहीं है जितना आप इसे बना रहे हैं। गोडोट के अधिकांश उपयोगकर्ता गूंगे नहीं हैं। वे जानते हैं कि "इस ऐड-ऑन की क्या आवश्यकता है: ऐड-ऑन एक्स कोर, एड-ऑन वाई, एड-ऑन जेड" का अर्थ है।

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

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

एक नया प्लगइन सिस्टम जोड़ें सम्मान के साथ असंगत नहीं होना चाहिए : // एडॉन्स जैसे यह अभी है ... और ऐसा इसलिए है क्योंकि:

वास्तविक प्रणाली महान है ...

मैं दोहराता हूँ:

वास्तविक प्रणाली महान है ...

उस बिंदु के बारे में कोई पूर्व शिकायत नहीं करता है।

मुझे इस चर्चा में देर हो रही है, यहाँ प्रस्ताव के बारे में कुछ विचार दिए गए हैं:

• मैं व्यक्तिगत रूप से अभी तक कई 'एसेट्स' का उपयोग नहीं करता हूं और मुझे लगता है कि एडऑन फोल्डर के साथ काम करना आसान है।
• मैं समझता हूं कि क्रॉस भाषा स्क्रिप्ट विरासत क्या करेगी और यह किस समस्या का समाधान करेगी (सी # डेवलपर को सी # का उपयोग करके कस्टम कार्यक्षमता जोड़ने के लिए जीडीस्क्रिप्ट स्क्रिप्ट से विस्तार करने की अनुमति दें) (ऐसा नहीं है कि मुझे इसका उपयोग करने की कोई इच्छा है) लेकिन मुझे यकीन नहीं है प्रति नोड क्या एकाधिक स्क्रिप्ट करेगा। ओह, तो जीडीस्क्रिप्ट स्क्रिप्ट से विस्तारित सी # स्क्रिप्ट के बजाय, यह इसे कॉल करने में सक्षम होगा? कौन सी लिपि मुख्य होगी? C# कोड कैसे बदलेगा जो GDScript स्क्रिप्ट करता है?
• स्क्रिप्ट को वर्ग नाम/नाम स्थान (टाइपडीबी) द्वारा संदर्भित करने की अनुमति देना उपयोगी हो सकता है। मैं res://paths के साथ ठीक हूं, लेकिन यह सच है कि एडॉन्स में किसी चीज़ से विरासत में बहुत लंबा पथ नाम बनता है। एक प्रमुख मुद्दा नहीं है, लेकिन एक अच्छा-से-होना - शायद क्रॉस भाषा विरासत के लिए आवश्यक (या पसंदीदा) होगा।

एसेट मैनेजमेंट के लिए एक सरल डिजाइन जो मैं सुझाऊंगा वह है

• एक निर्भरता होना।json (या केवल प्रोजेक्ट सेटिंग्स में डेटा सहेजना) उपयोगी है, बस इसलिए मुझे पता है कि मैंने कौन सा संस्करण डाउनलोड किया है और यदि कोई अपडेट किया गया संस्करण है। मुझे लगता है कि यह आवश्यक जानकारी है।
• नहीं, संपत्तियों को निर्भरता को परिभाषित करने में सक्षम न होने दें। मुझे नहीं लगता कि गोडोट की संपत्तियां एनपीएम मॉड्यूल की तरह एक-दूसरे पर इतनी अधिक निर्भरता रखती हैं। संपत्ति डेवलपर को दस्तावेज़ीकरण में बताएं कि क्या यह वास्तव में किसी अन्य संपत्ति पर निर्भर करता है और उपयोगकर्ता को मैन्युअल रूप से इंस्टॉल करने देता है। यह चीजों को सरल करेगा और हमें एक और निर्भरता सत्यापन चीज नहीं बनानी पड़ेगी जो कोड ब्लोट/बनाए रखने के लिए अधिक कोड है।
• नहीं, संपत्तियों को 'वैश्विक' स्थान पर न सहेजें। उन्हें प्रोजेक्ट एडॉन्स फ़ोल्डर में रखना पहले से ही अच्छा है। यह उन्हें परियोजना के साथ स्रोत नियंत्रण के साथ प्रतिबद्ध होने की अनुमति देता है और उन्हें प्रबंधित करना आसान बनाता है। यहां तक ​​कि npm node_modules प्रोजेक्ट के अंदर प्रोजेक्ट के मॉड्यूल को सेव करता है।
• अब, संपत्ति ब्राउज़र में सुधार करें ताकि यह सूचीबद्ध कर सके कि कौन सी स्थापित संपत्ति अपडेट की गई है और यदि आप चाहें तो उन्हें अपडेट कर सकते हैं।
• अब, यह उन ऐडऑन के लिए 'वैश्विक' ऐडऑन रखने में सक्षम होने के लिए समझ में आता है जो सिर्फ संपादक सुधार हैं। इसलिए सामान्य ऐडऑन अभी भी प्रोजेक्ट ऐडऑन फ़ोल्डर में जाते हैं, लेकिन संपादक से संबंधित ऐडऑन के लिए, आपके पास उन्हें विश्व स्तर पर स्थापित करने का विकल्प होता है। यह उस कोड को प्रोजेक्ट के ऐडऑन फ़ोल्डर के बाहर भी ले जाता है, इसलिए यह रिलीज़ पैकेज में नहीं जाता है। (यह विकास उपकरणों के लिए npm install -g के समान है)

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

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

• या तो हर डेवलपर जो कम से कम एक निर्भरता रखने की हिम्मत करता है, उसे उपयोगकर्ता को यह दिखाने के लिए बॉयलरप्लेट कोड सेट करना होगा कि उसे एक निर्भरता स्थापित करने की आवश्यकता है (भले ही पैकेज उस प्लगइन के लिए सिर्फ एक डेमो हो!)
• या क्या एसेटलिब कम से कम यह इंगित करता है?

संपत्तियों के आसान अपडेट के लिए +1 भी करें, उन्हें लाइब्रेरी में फिर से ब्राउज़ करने की आवश्यकता नहीं है।

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

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

हालांकि एक अच्छी तरह से इंजीनियर समाधान के रूप में, मैं मानता हूं कि यह अच्छा होगा और अन्य परिसंपत्तियों के आधार पर/आधार पर संपत्ति के एक पारिस्थितिकी तंत्र के विकास को प्रोत्साहित कर सकता है।

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

@ eon-s तो, @ bojidar-bg के सुझाव जैसा कुछ?

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

मैं व्यक्तिगत रूप से वास्तव में इंजन को अनुकूलित करने और उन सभी चीजों को हटाने में सक्षम होने का विचार पसंद करता हूं जिनका मैं वास्तव में उपयोग नहीं कर रहा हूं। [क्या कोई मुझे बता सकता है कि मैं उदाहरण के लिए सभी 3D सामग्री को कैसे हटाऊंगा? और क्या मैं उन मॉड्यूल के संकलन को अक्षम कर सकता हूं जिनका मैं उपयोग नहीं करता हूं? कैसे?]

बात यह है कि, जब कोई नया नोड प्रकार प्रस्तावित करता है जैसे। उल्लिखित स्प्रिंग आर्म या नया वर्ग उदा। एक बेहतर आरएनजी वर्ग, या यदि कुछ मौजूदा कोर नोड्स को हटाया जाना है, उदाहरण के लिए। वाहन नियंत्रक ... वे C++ कोड हैं। यदि उन्हें कोर में शामिल नहीं किया गया है, तो उन्हें एक्सटेंशन के रूप में कैसे जोड़ा जाएगा? GDNative संपत्तियां? प्रबंधन/निर्माण के लिए यह बहुत सारे डीएलएस और साझा पुस्तकालय होंगे।

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

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

यहां @chanon का जवाब दे रहे हैं।

नहीं, संपत्तियों को निर्भरता को परिभाषित करने में सक्षम न होने दें। मुझे नहीं लगता कि गोडोट की संपत्तियां एनपीएम मॉड्यूल की तरह एक-दूसरे पर इतनी अधिक निर्भरता रखती हैं।

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

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

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

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

वास्तव में, नोड्स का एक बड़ा समूह इंजन में शामिल होने के लिए @reduz की दूसरी आवश्यकता के अंतर्गत आता है, केवल इसलिए कि "स्वयं को करना मुश्किल है" पूरी तरह से मनमाना है। जो कुछ के लिए सरल हो सकता है वह दूसरों के लिए कठिन होता है।

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

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

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

मुझे अभी भी विश्वास है कि कोर को डाउनलोड करने और ट्रिम करने के लिए आधिकारिक नोड्स प्रदान करना अधिक फायदेमंद है। इसके साथ, हम कर सकते हैं:

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

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

दिलचस्प चर्चा। कई अच्छे प्रस्ताव भी।

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

बस इन दिलचस्प विचारों में से कुछ को मंजूरी देना चाहता था।

विशेष रूप से इसके बारे में अधिक से अधिक कार्यक्षमता किसी ऐसी चीज़ में निर्यात हो जाती है जो आधिकारिक मॉड्यूल या प्लगइन्स जैसी किसी चीज़ का रूप ले लेती है।

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

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

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

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

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

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

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

वैसे भी, सभी लोग अच्छा काम करते रहें।

बस एक और पागल विचार:

हो सकता है कि किसी तरह GDNative C++ को मॉड्यूल में ऑटो-कन्वर्ट करना संभव होगा (आदर्श रूप से GDNative द्वारा बनाई गई अप्रत्यक्ष परतों को हटाकर)? फिर यह "एक स्थिर निष्पादन योग्य में सब कुछ" दृष्टिकोण और "कंपाइलर स्थापित किए बिना पट्टी सुविधाओं" के दोनों अधिवक्ताओं को खुश कर सकता है

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

मुझे डर है कि यह प्रदर्शन को नुकसान पहुंचाएगा क्योंकि जीडीस्क्रिप्ट अभी बहुत तेज नहीं है।

शुक्र, 22 जून, 2018 को रात 11:10 बजे, एलन नॉर्थ नोटिफिकेशन @github.com
लिखा था:

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

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

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

@LikeLakers2

लेकिन क्यों? उस समय, क्यों न केवल संपत्तियों को इस निर्भरता फ़ाइल को वैसे भी होने दें क्योंकि इससे कुछ भी नुकसान नहीं होगा?

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

हालांकि, मैं प्रोजेक्ट फ़ोल्डर के बाहर किसी स्थान पर प्रोजेक्ट ऐडऑन स्थापित करने के विचार के खिलाफ हूं क्योंकि इससे चीजों को प्रबंधित करना कठिन हो जाता है। केवल 'वैश्विक' संपादक ऐडऑन प्रोजेक्ट फ़ोल्डर के बाहर होने चाहिए।

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

जैसा कि ऊपर कहा गया है, अगर चीजों को कोर इंजन से हटाकर संपत्ति में बदलना है, तो बेहतर परिसंपत्ति प्रबंधन प्रणाली होना समझ में आता है। अन्यथा यह इंजन से कार्यक्षमता खो जाने की राशि होगी क्योंकि उपयोगकर्ता आसानी से हटाई गई कार्यक्षमता को खोजने में सक्षम नहीं होंगे।

मैं सोच रहा था कि आदर्श परिदृश्य

• नए उपयोगकर्ता और वे लोग जो इंजन को संकलित नहीं करते हैं: इंजन डाउनलोड पृष्ठ पर उनके पास कोर इंजन डाउनलोड करने का विकल्प होता है, और यह भी चयन करते हैं कि वे अपने इंजन डाउनलोड में कौन से आधिकारिक या अनुशंसित एक्सटेंशन शामिल करना चाहते हैं। ( ध्यान दें कि यह संभव नहीं होगा यदि एक्सटेंशन को वैश्विक फ़ोल्डर में सहेजा नहीं जा सकता है। उपयोगकर्ताओं को इसके बजाय एक प्रोजेक्ट बनाने के बाद एक्सटेंशन ढूंढना होगा, जो खोज योग्यता को नुकसान पहुंचाता है। ... हालांकि एक आदर्श [असंभव] दुनिया में, वेबसाइट होगी मौके पर चयनित एक्सटेंशन/घटकों से एक कस्टम सी ++ बिल्ड बनाएं।)
• जो लोग इंजन को संकलित करते हैं: एक उपकरण जो एक्सटेंशन सी ++ कोड डाउनलोड और संस्करणों का प्रबंधन करता है और उन्हें बिल्ड फ़ोल्डर में सही स्थान पर रखता है ताकि वे इंजन बिल्ड में शामिल हो सकें।

इंजन को संकलित करने वाले किसी व्यक्ति के रूप में, मैं अपने एक्सटेंशन को GDNative (या धीमी GDScript) के बजाय मॉड्यूल के रूप में पसंद करूंगा। मैं प्रतिरूपकता के स्तर की कल्पना कर रहा हूं कि मैं अपने निर्माण में शामिल करने या शामिल नहीं करने के लिए विशिष्ट नोड प्रकार चुन सकता हूं, या यहां तक ​​कि सभी 3D सामान को छोड़ सकता हूं।

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

दूसरी ओर, जो लोग इंजन को संकलित नहीं करते हैं, उनके लिए GDNative C++ एक्सटेंशन जोड़ने का एकमात्र समाधान है।

तो जैसे स्टाररी-एबिस ने सुझाव दिया, अगर GDNative को एक सामान्य मॉड्यूल में स्वतः अनुकूलित किया जा सकता है तो यह बहुत अच्छा होगा।

ठीक है तो मैंने अपना स्टैंड बदल दिया है मुझे उद्योग के पावरहाउस के समान लीग में क्षमताओं के साथ ब्लोट-फ्री इंजन का विचार पसंद है।

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

यहां मेरे कुछ सुझाव दिए गए हैं कि इसे कैसे प्राप्त किया जाए,

1. सबसे पहले हम संपत्ति पुस्तकालय में संपत्ति रखने की क्षमता जोड़ सकते हैं जिसे भागों में स्थापित किया जा सकता है, गिट में उन्हें टैग या शाखाओं द्वारा अलग किया जा सकता है।
   तो अब अगर मैं केवल 2D फ़ीचर नोड्स चाहता था तो मैं बस उसे डाउनलोड कर सकता था लेकिन अभी भी अपडेट की जांच के लिए देखने के लिए केवल एक ही जगह है।
2. दूसरा, हम संपत्ति के अपडेट में लेबल जोड़ने की क्षमता जोड़ सकते हैं, जैसे कुछ कोर अपडेट कुछ फीचर और कुछ बैकवर्ड संगतता ब्रेकिंग हो सकते हैं।
   इसके बाद एसेट मैनेजर द्वारा एडऑन को अपडेट करने और मामले पर आपसे अपडेट पूछने के लिए स्वचालित रूप से इसका उपयोग किया जा सकता है। जैसे यह आपको बताएगा कि आप मुख्य अपडेट के इंतजार में आए हैं, या आपका अगला अपडेट बैकवर्ड कम्पैटिबिलिटी ब्रेकिंग होने वाला है। आप अपडेट करना चाहते हैं या नहीं।
3. तीसरा एक संपत्ति के कई संस्करण रखने की अनुमति देने के लिए और फिर जब कोई संस्करण बहुत पुराना हो जाता है तो एडऑन/एसेट का देव इसे पुराना के रूप में चिह्नित कर सकता है जो कि गोडोट खोलने पर दिखाई देगा और यह आपको पुराने संस्करण को हटाने के लिए कहेगा या नहीं .
4. और अंतिम ऐडऑन के लिए अन्य ऐडऑन के लिए पूछने की क्षमता निर्भरता की तरह होगी लेकिन यह आपको केवल यह बताएगा कि इस एडऑन को चलाने के लिए आपको इस एडऑन की आवश्यकता है और यदि आपके पास इसे इंस्टॉल नहीं है।
   और अगर कभी एडऑन खुद नोटिस करता है कि एडऑन अब नहीं मिल सकता है तो इसे फिर से जोड़ने के लिए कहें या सिर्फ एक त्रुटि संदेश दिखाएं।

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

और जैसा कि @chanon ने कहा था कि हमें संपत्तियों को वैश्विक के रूप में डाउनलोड करने की आवश्यकता होगी जिसे बाद में एकता की तरह परियोजना में आयात किया जा सकता है।
और ऐडऑन प्रक्रिया की स्थापना में बहुत लचीलेपन के साथ हमारे वर्तमान कार्यान्वयन की तुलना में एक बेहतर परिसंपत्ति प्रबंधक की अनुमति दी जानी चाहिए।
मैं अनुशंसा करता हूं कि एक ऐडऑन को GDNative और मॉड्यूल दोनों के रूप में जोड़ने की क्षमता हो, जो एडऑन देवों पर कुछ भार डालेगा, लेकिन मुझे लगता है कि यह एकमात्र स्वीकार्य समाधान है जब तक कि यहां कुछ मौलिक रूप से नहीं बदलता है।
लेकिन हम ऐडऑन निर्माण को आसान बनाने के लिए अभी भी GDNative में कुछ सुविधाएँ जोड़ सकते हैं। जैसे एक बार में सभी प्लेटफॉर्म के लिए निर्माण करने में सक्षम होना काफी बेहतर होगा।

प्लगइन्स अपडेट होने के कारण निर्भरता और संपत्ति के टूटने के मुद्दे पर,
क्यों नहीं (और क्षमा करें अगर मैं किसी को पहले से ही यह सुझाव दे रहा हूं)

1. क्या सर्वर हर संस्करण को अपलोड रखता है

2. प्लगइन्स को एक विशिष्ट प्लगइन के विशिष्ट संस्करण को निर्दिष्ट करने की अनुमति दें

3. प्लगइन्स के लिए एक समझदार संस्करण प्रणाली का उपयोग करने का प्रयास करें (गोडोट का उपयोग करता प्रतीत होता है
   मेजर.फीचर.बगफिक्स वर्जन नंबरिंग, जो मुझे पसंद है)

4. और सबसे महत्वपूर्ण बात, प्लगइन्स को स्वतः अपडेट न करें? (या कम से कम अनुमति दें
   उपयोगकर्ता यह चुनने के लिए कि वे किस प्रकार के अपडेट के साथ ठीक हैं, जैसे बग फिक्स और
   फीचर अपडेट, लेकिन कोई बड़ा अपडेट नहीं)।

@ टू-टोन तो फिर पूरी चीज को ब्लोट फ्री क्यों करें। ??

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

आप उपयोगकर्ताओं को अपडेट करने का निर्णय लेने की अनुमति देने के बारे में सही हैं लेकिन बग-फिक्स डिफ़ॉल्ट रूप से स्वतः होना चाहिए। क्योंकि अगर मेरे पास सौ ऐडऑन हैं तो मैं बग फिक्स अपडेट के लिए एक-एक करके उनकी जांच नहीं करूंगा।
बाकी उपयोगकर्ता पर निर्भर हो सकता है यदि आवश्यकता हो तो हमारे पास अक्षम करने के लिए एक सेटिंग हो सकती है।

और स्टोर को ऑफ़लाइन उपयोग के लिए आधिकारिक बंडल की पेशकश करनी चाहिए (संपादक में ऑफ़लाइन स्टोर समर्थन के साथ)।

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

शायद, हाँ, लेकिन एक ऐसी दुनिया में जहां डेस्कटॉप 256BG SSD + 1TB HDD से कम कुछ भी उपयोग नहीं करते हैं और यहां तक ​​कि फ़ोन में न्यूनतम 16GB से शुरू होने वाली जगह होती है, जिसमें से सभी बढ़ने की संभावना से अधिक है, क्या ऐसा होगा खराब?

पोर्टेबल और किफायती लैपटॉप सेगमेंट में, eMMC जीवित और अच्छी तरह से है और 32GB आकार (10GB से कम मुफ्त के साथ) इतना असामान्य नहीं है।

वैसे, लैपटॉप के उस वर्ग पर, मुझे लगता है कि वर्तमान एंड्रॉइड निर्यात प्रणाली उपयोग योग्य है, जबकि नियोजित (https://github.com/godotengine/godot/issues/18865) नहीं है। मैं नई प्रणाली की खूबियों को समझता हूं और संतुलन पर मैं शायद खुद इसके लिए मतदान करता (जब मैंने इस मुद्दे को देखा तो पहले से ही कोई प्रतियोगिता नहीं थी), लेकिन हमें इस बात से अवगत होना चाहिए कि हम परिवर्तन से एक महत्वपूर्ण उपयोग के मामले को खो रहे हैं।

@swarnimarun कोई गलतफहमी हो सकती है। जब मैं उस टिप्पणी में "सिस्टम" कहता हूं, तो मेरा मतलब उस सर्वर से था जो प्लगइन्स की सेवा करता है, इंजन नहीं। क्षमा करें यदि यही आपको परेशान करता है।

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

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

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

बस मेरे कुछ सेंट, निश्चित रूप से इनमें से अधिकांश पहले कहा गया है, इसलिए मुझे संदेह है कि मैं कुछ नया ला रहा हूं।

मैं चीजों को प्लगइन्स के रूप में करने के लिए प्लगइन्स के रूप में चीजों को करने में विश्वास नहीं करता। मैं आकार के मुद्दे को समझता हूं लेकिन हम अब 80 के दशक में नहीं रह रहे हैं। हम इंजन के 50Mb या 55Mb होने के बारे में बात कर रहे हैं, इंजन के 50Mb या 500Mb होने के बीच नहीं, किसी भी गंभीर गेम की संपत्ति के आकार की तुलना में प्लगइन में स्थानांतरित होने वाली सुविधा का अतिरिक्त आकार वृद्धि नगण्य है। यदि हमारे द्वारा भुगतान की जाने वाली कीमत अधिक परेशानी वाला एकीकरण है, तो यह इसके लायक नहीं है।

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

मेरा VR अनुभव इनमें से कुछ से अलग है। एक कारण है कि इसमें अधिक समय लग रहा है तो मैं इसे मोबाइल पर चलाना और चलाना चाहूंगा। मांगों के कारण, विशेष रूप से मोबाइल पर, डिस्प्ले को विभिन्न तरीकों से स्थापित करने के लिए आपको कोर के काम करने के तरीके को बदलना होगा और इसे एक प्लगइन में कैप्चर करना मुश्किल साबित होगा।
ओपनवीआर और ओपनएचएमडी अब तक आसान रहे हैं। Oculus मैं एक ऐसे समाधान से गुज़रा हूँ जिसे तुच्छ समझा जाता है लेकिन मैं इससे खुश हूँ।
ARKit को कोर में होना चाहिए, यह एक मॉड्यूल के रूप में हल करने योग्य नहीं है, कम से कम हमारी वर्तमान संरचना में नहीं है (Apple iOS पर डायनेमिक लाइब्रेरी की अनुमति भी नहीं देता है, इसलिए वह भी है)।
गियरवीआर और डेड्रीम को वास्तव में मूल में होना चाहिए, गियरवीआर के लिए एक असंभवता इसके कारण स्वामित्व पुस्तकालयों का उपयोग कर रही है।
Hololens/Microsoft MR मैं यह देखने के मार्ग पर जा रहा हूं कि क्या मैं इसे एक प्लेटफ़ॉर्म विकल्प बना सकता हूं, Microsoft उन्हें इस तरह से देखता है क्योंकि ऐप दोनों के बीच चलने वाले हैं और होलोलेंस पर केवल होलोग्राफिक ऐप के रूप में स्थापित हैं।

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

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

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

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

जो नोड प्लगइन्स में बदलने लायक हो सकते हैं, वे कंट्रोल नोड्स हैं जो कंट्रोल नोड्स (कंपोजिट वाले) द्वारा बनाए जाते हैं, दूसरों के निर्माण के लिए केवल साधारण नोड्स छोड़ते हैं।

वाहन जैसे जटिल तर्क वाले नोड्स या यहां तक ​​​​कि सरल लेकिन उपयोगी जैसे स्थिति वाले, कोर में अच्छे हैं।

IMO, इनमें से किसी को भी इंजन से नहीं हटाया जाना चाहिए। नियंत्रण नोड्स, भौतिकी नोड्स (जैसे वाहन), और यहां तक ​​कि वर्तमान में मौजूदा भू-भाग समर्थन नहीं:

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

यदि हम इस तरह से जाते हैं, तो प्लगइन इन्फ्रास्ट्रक्चर और एसेटलिब दोनों को उपयोगिता ओवरहाल की आवश्यकता होती है।

और वैसे, मैं UE4 के बड़े इंस्टॉल आकार से कम परेशान हूं, क्योंकि मैं इसके द्वारा वाहनों, इलाके या UI के लिए अंतर्निहित समर्थन के साथ नहीं आ रहा हूं - जो इसके पास है, यह सब।

मुझे यकीन नहीं है कि इसमें से कितना पहले ही कहा जा चुका है, इस तरह के बड़े धागे का पालन करना मुश्किल हो सकता है, लेकिन वैसे भी:

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

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

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

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

अब यह तय हो गया है, इंजन से बाहर कुछ सामान ("कुछ" निर्धारित करने के लिए) पर विचार करने के लिए हमें प्रोत्साहित करने वाले मुख्य कारक हैं:

• तकनीकी ऋण। सभी कोड बनाए रखने की जरूरत है। 2014 के बाद से हमारे पास एक टूटा हुआ वाहन शरीर विशेष रूप से उपयोगी नहीं है, क्योंकि यह वास्तविक खेलों के लिए पर्याप्त नहीं है। यह हाल ही में Bullet का उपयोग करके बेहतर हुआ है इसलिए यह बेहतर हो रहा है, लेकिन पिछले 4 वर्षों से यह प्रभावी रूप से मृत कोड और अनावश्यक रखरखाव का बोझ था।
• सार्वभौमिकता: गोडोट एक ऐसा इंजन है जो आपको किसी भी प्रकार का खेल करने देता है, और इसके द्वारा प्रदान की जाने वाली सुविधाएँ आपको किसी भी प्रकार का खेल करने में सक्षम बनाती हैं। इसका मतलब यह नहीं है कि यह अनन्य होना चाहिए (अधिकांश खेलों में आपको एक ही समय में 2D और 3D दोनों की आवश्यकता नहीं है), लेकिन सुविधाओं को अधिकांश उपयोगकर्ताओं की सामान्य आवश्यकताओं को पूरा करना चाहिए। जिसका अर्थ है कि हमारे द्वारा प्रदान की जाने वाली सुविधाएँ निम्न स्तर की होनी चाहिए, और यह कि खेल-विशिष्ट उच्च स्तरीय सुविधाएँ अधिकांश समय बाहरी रूप से सर्वोत्तम रूप से प्रदान की जाती हैं।
• लचीलापन: कोर के बाहर उच्च स्तरीय सुविधाओं को बनाए रखने से उन्हें बेहतर बनाने के लिए बहुत तेज पुनरावृत्ति प्रक्रिया सक्षम होती है, यदि आवश्यक हो तो उन्हें फोर्क करें, आदि।

यदि हम इस तरह से जाते हैं, तो प्लगइन इन्फ्रास्ट्रक्चर और एसेटलिब दोनों को उपयोगिता ओवरहाल की आवश्यकता होती है।

खैर, यही इस मुद्दे का कारण है, नहीं? :) पूरी बात यह है कि कोर इंजन में सभी कोने के मामलों को बंडल करने के बजाय बेहतर वर्कफ़्लो की अनुमति देने के लिए हमें उपयोगिता ओवरहाल की आवश्यकता है।

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

@Ranoller नए सिस्टम हमेशा पुराने सामान को हटाते हैं, अपरिहार्य है।
CPU कणों को GLES2 के साथ वापस आना चाहिए (क्योंकि CPU वाले का समर्थन नहीं करता है), लेकिन CPU पर आकर्षित करने वाले लेकिन GPU पर नहीं होना अच्छा नहीं होगा।
EventStreamChibi एक मॉड्यूल था, मुझे लगता है कि नया ऑडियो सिस्टम अधिक लचीला होने पर ट्रैकर फ़ाइलों के लिए बेहतर समर्थन दे सकता है।

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

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

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

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

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

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

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

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

तो @reduz के प्रस्ताव का पूरा बिंदु यह है कि नए योगदानकर्ताओं को कोर इंजन में डालने के लिए सुविधाओं की बढ़ती संख्या, ज्यादातर समय, संपत्ति पुस्तकालय में संपत्ति के रूप में बेहतर अनुकूल होगी। यहां इस मुद्दे का मुद्दा यह है कि यह कैसे सुनिश्चित किया जाए कि यह कार्यप्रवाह यथासंभव सुगम हो।

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

तो @reduz के प्रस्ताव का पूरा बिंदु यह है कि नए योगदानकर्ताओं को कोर इंजन में डालने के लिए सुविधाओं की बढ़ती संख्या, ज्यादातर समय, संपत्ति पुस्तकालय में संपत्ति के रूप में बेहतर अनुकूल होगी। यहां इस मुद्दे का मुद्दा यह है कि यह कैसे सुनिश्चित किया जाए कि यह कार्यप्रवाह यथासंभव सुगम हो।

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

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

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

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

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

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

मुझे लगता है कि हालांकि विचार यह है कि इंजन में सिर्फ बुनियादी बिल्डिंग ब्लॉक शामिल होंगे, फिर वाहन नोड जैसी चीजें आधिकारिक ऐड-ऑन हो सकती हैं, फिर बाकी सब कुछ जो बड़ा है और अलग-अलग तरीकों से लागू किया जा सकता है, बस नियमित ऐड-ऑन होना चाहिए , सही?

जो मुझे नहीं मिलता वह यह है कि आधिकारिक ऐड-ऑन कैसे लागू किए जाएंगे। मैंने सोचा था कि वर्तमान में हम कस्टम नोड्स नहीं लिख सकते हैं जो ऐसा लगता है कि वे बनाए गए थे, है ना, उनके पास एक स्क्रिप्ट होनी चाहिए? या यह एक सी ++ मॉड्यूल या कुछ के साथ संभव है (यहां सी ++ नोब हूं)।

और अंत में हम इस समस्या में पड़ जाते हैं कि ऐड-ऑन कैसे किया जाए जो अलग-अलग आधिकारिक नोड्स पर निर्भर करता है। किसी प्रकार की निर्भरता प्रणाली के बिना यह नरक जैसा लगता है।

पार्टी के लिए देर हो चुकी है, लेकिन मेरे वर्तमान प्रोजेक्ट के पैमाने को देखते हुए, मैंने खुद को गोडोट 3 के लिए _a लॉट_ प्लगइन्स विकसित करते हुए पाया है और प्रोजेक्ट समाप्त होने से पहले खुद को कई और विकसित करते हुए देखा है। प्रत्येक प्लगइन के साथ, मैं एक गेम अज्ञेय तरीके से जितना हो सके उतना विकसित करने की कोशिश करता हूं और दूसरों के उपयोग के लिए एमआईटी लाइसेंस के तहत उन्हें ओपन सोर्स करता हूं। मैं झूठ नहीं बोलने वाला। वर्तमान ऐडऑन सिस्टम वास्तव में चीजों की भव्य योजना में उतना बुरा नहीं है ... फिर भी _are_ कुछ टुकड़े गायब हैं जो इसे कई मामलों में सीमा रेखा को बेकार बनाते हैं। इससे पहले कि मैं उन तक पहुंचूं, मैं @karroffel विचारों के बारे में कुछ बातें कहना चाहता हूं।

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

यह मुझे वर्तमान एडऑन सिस्टम के साथ मेरे _personal_ योग्यता की ओर ले जाता है और जो मुझे लगता है कि एक बेहतर दुनिया के लिए दो बहुत अच्छे शुरुआती बिंदु होंगे जो वास्तव में नियमित आधार पर प्लगइन्स विकसित करते हैं:

वर्तमान ऐडऑन सिस्टम के साथ सबसे बड़ी समस्या निर्भरता प्रबंधन की कमी है।

इस पर पहले ही काफी चर्चा हो चुकी है, लेकिन अधिकांश सुझाव भारी-भरकम हैं और वर्तमान प्रणाली के साथ अत्यधिक संगत नहीं हैं। अब, मैंने अभी तक खुद को एसेटलिब मॉड्यूल के कोड बेस से परिचित नहीं कराया है, लेकिन मुझे लगता है कि इस विभाग में _ should_ एक आसान जीत है। वर्तमान में, Github पर तीसरा भाग एडऑन रिपॉजिटरी निम्नलिखित फ़ोल्डर संरचना का पालन करता है:

addons/
    addon_name/
        plugin.cfg
        ...other files

मैं जो प्रस्तावित करता हूं वह है plugin.cfg स्कीमा का विस्तार करना और उपयोग करने के लिए एक विकल्प प्रतिबद्ध हैश (या शाखा/टैग नाम) के साथ निर्भरता संस्करणों की एक सूची रखने की क्षमता जोड़ना। निम्नलिखित की तरह कुछ काम करेगा:

[plugin]
name="foo"
description="foobar"
author="blah"
version="1.0.0"
script="plugin.gd"

[dependency]
name="dep1"
path="github.com/foo/dep1"
hash="7fc2367508c41cfab86eaf7d84e04cd122978fdb"

[dependency]
name="dep2"
path="github.com/foo/dep2"
tag="v3.1.2"

[dependency]
name="dep3"
path="github.com/foo/dep3"
branch="big-refactor"

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

एक वास्तविक दुनिया के उदाहरण के रूप में,
मेरे पास गोडोट व्यवहार पेड़ों के लिए एक संपत्ति है। इस प्रणाली का एक हिस्सा UE4 जैसा ब्लैकबोर्ड नोड है जो मनमाने वैश्विक या नोड-स्थानीय डेटा को संग्रहीत करने के लिए है जिसे नोड्स में साझा किया जाना है। इसका उपयोग बीटी सिस्टम में व्यवहार नोड्स के बीच राज्य साझा करने के लिए किया जाता है। यह सब ठीक है और बांका है, लेकिन फिर मैं वर्तमान में एक संवाद प्रणाली और साथ में टूलिंग विकसित कर रहा हूं, और इस प्रणाली के हिस्से को शर्तों के लिए उपयोग करने के लिए कुछ प्रकार के varibales डेटाबेस की आवश्यकता होती है। मैं संवाद प्रणाली के लिए भी बीटी सिस्टम से ब्लैकबोर्ड घटक का पुन: उपयोग करना चाहूंगा। वास्तव में, ब्लैकबोर्ड घटक लगभग उतना ही सामान्य है जितना इसे प्राप्त हो सकता है, और वैश्विक डेटा gamedev में एक काफी सामान्य मुहावरा है, इसलिए अपने आप में भी यह एक काफी उपयोगी एडऑन हो सकता है, क्योंकि यह मूल रूप से हर परियोजना में फिर से लागू किया गया है। .

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

मल्टी-स्क्रिप्ट नोड्स की आवश्यकता

यह इस मुद्दे में पहले से ही एक और गर्म विषय है, और ईमानदारी से, गोडोट का उपयोग करने का इरादा कैसे किया जाता है, इसकी मूलभूत विचारधारा को बदले बिना मेरे पास इस तक पहुंचने का एक बहुत अच्छा तरीका नहीं है। यह ठीक हो भी सकता है और नहीं भी, लेकिन हाँ... वैसे भी, यह प्लगइन _authors_ के लिए उतनी समस्या नहीं है, जितनी प्लगइन _users_ के लिए है (अक्सर एक ही व्यक्ति से कई बार;)।

अंत में, अगर हम इन दो चीजों को हल कर सकते हैं, तो मुझे लगता है कि हम वहां 90% होंगे। अन्य 10% मेरी राय में एक सौदा के रूप में बड़ा नहीं है और शायद संपत्ति की मौलिक वास्तुकला को ओवरहाल करने के परिप्रेक्ष्य से संपर्क किया जाना चाहिए, जो मेरी राय में, बहुत बड़ी मछली तलने के बाद इंतजार कर सकता है।

यदि कोई आपत्ति नहीं है, तो मैं शायद आने वाले दिनों में एसेटलिब कोड में निर्भरता प्रबंधन के संबंध में अपने सुझाव को लागू करने का प्रयास करूंगा

निर्भरता प्रबंधन मुझे अच्छा लगता है। :स्माइली:

केवल एक चीज जिससे मैं सहमत नहीं हूं, वह है निर्भरता का संस्करण
एक वैकल्पिक सूची हो। यह उन समस्याओं का कारण बनेगा जो reduz ने उल्लेख किया है कि
अन्य इंजन के प्लगइन सिस्टम के साथ होता है।

जब तक कोई व्यक्ति अपने सिर के ऊपर से निर्भरता संघर्ष से निपटने का एक आसान तरीका नहीं आ सकता है

मुझे लगता है कि इसका समाधान इस बात पर निर्भर करेगा कि प्लगइन कैसे कोड को कॉल करता है
एक अलग प्लगइन। अगर हम इसे इस तरह सेट करते हैं कि प्लगइन की स्क्रिप्ट काम करती है
extends "dep2/folder/script.gd" , इंस्टॉल होने पर हम बस dep2 . बदल सकते हैं
dep2-v3.1.2 । हैश के लिए हम केवल पहले 5 अंकों का उपयोग कर सकते हैं (जब तक कि
हम ऐसे नाम वाले फ़ोल्डर चाहते हैं जो कम से कम 42 वर्ण लंबे हों)। 5 बजे
अंक टकराव की संभावना अविश्वसनीय रूप से छोटी है।

मैं अभी थोड़ा थक गया हूँ, इसलिए हो सकता है कि मुझे कुछ याद आ रहा हो, लेकिन मुझे दिखाई नहीं दे रहा है
कोई समस्या।

@jonbonazza यदि आप करते हैं, तो कृपया इसमें Git उपयोग को हार्डकोड न करने का प्रयास करें। यद्यपि ऐसा लगता है कि यहां आसपास दिया गया है, कुछ लोग अन्य वीसीएस सिस्टम (या वीसीएस का बिल्कुल भी उपयोग नहीं कर रहे हैं) पसंद कर सकते हैं, इसलिए शायद यह संपत्ति-लिबरेशन पक्ष पर संभालने के लिए एक विवरण होना चाहिए।
साथ ही, मुझे आश्चर्य है कि क्या हम किसी प्रोजेक्ट में वीसीएस सब-रेपो के रूप में प्लगइन्स को आसान बनाने के लिए कुछ करने पर विचार करते हैं? किसी समय इसका उल्लेख किया गया था लेकिन मुझे याद नहीं है कि कोई समझौता हुआ था या नहीं।

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

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

मुझे यकीन नहीं है कि संपत्ति पुस्तकालय में अद्वितीय मानव पठनीय आईडी (स्लग) हैं। नहीं तो चाहिए। उदाहरण के लिए npm मॉड्यूल में एक टेक्स्ट मॉड्यूल नाम/आईडी होता है जिसे आप उन्हें स्थापित करते समय उपयोग करते हैं।

निर्भरता विनिर्देश तब शायद इस तरह दिखेगा

[dependency]
asset_id="some_asset"
version="1.0.0"

@ टू-टोन मैं इसके साथ बहुत ज्यादा पागल नहीं होने की कोशिश कर रहा था। बस कुछ आसान चाहता था जब तक कि एक बेहतर दृष्टिकोण पर निर्णय नहीं लिया जाता।

@Zylann मैं शायद उसी दृष्टिकोण का उपयोग करूंगा जो वर्तमान में संपत्ति lib में उपयोग किया जाता है - जिथब से ज़िप फ़ाइल को डाउनलोड करना और निकालना।

@chanon एसेट लिब सीधे जीथब के साथ काम करता है, इसलिए हमारे पास संस्करणों के लिए एकमात्र पहचान हैश, ब्रांच और टैग है।

कौन सा हिस्सा बहुत पागल है? निर्भरता संस्करण अनिवार्य या मेरा समाधान होना
निर्भरता संघर्ष के लिए? किसी भी स्थान पर एक मानक है जिसमें
निर्भरता प्रबंधन और दूसरा पाठ और फ़ोल्डर में एक सरल संपादन है
नामित। मुझे नहीं लगता कि इनमें से कोई भी चीज पागल है।

मंगल, 3 जुलाई 2018 को, 11:23 AM जॉन बोनाज़ा नोटिफिकेशन @github.com ने लिखा:

@ टू-टोन https://github.com/Two-Tone मैं कोशिश कर रहा था कि मैं ज्यादा पागल न हो जाऊं
इस के साथ। बस एक बेहतर होने तक हमें पकड़ने के लिए कुछ आसान चाहता था
दृष्टिकोण तय किया है।

@Zylann https://github.com/Zylann मैं शायद उसी दृष्टिकोण का उपयोग करूंगा
जो वर्तमान में एसेट लिब में उपयोग किया जाता है - ज़िप को डाउनलोड करना और निकालना
जीथब से फाइल।

@chanon https://github.com/chanon जीथब के साथ एसेट लिब wirks
सीधे तौर पर हमारे पास संस्करणों के लिए एकमात्र पहचान हैश प्रतिबद्ध है,
शाखा, और टैग।

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

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

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

@jonbonazza मैं देख रहा हूँ। आपका समाधान कुछ ऐसा है जिसे लागू किया जा सकता है और संपत्ति पुस्तकालय को संशोधित करने की आवश्यकता के बिना तुरंत काम करता है। तब मैं मानता हूं कि यह एक अच्छा पहला कदम है। (ऐसा नहीं है कि मैं एक कोर मेंटेनर हूं जिसके पास कोई अधिकार है .. बस मुझे लगता है कि यह एक अच्छा पहला कदम है।)

मुझे लगता है कि अगर एसेट लाइब्रेरी डेटाबेस में टेक्स्ट आइडेंटिफ़ायर (स्लग) प्लस वर्जन की जानकारी जोड़ी गई है, तो इसे ऊपर दिए गए मेरे उदाहरण की तरह जोड़ा जा सकता है।

आप निर्भरता के लिए git सबमॉड्यूल का उपयोग कर सकते हैं।

@jonbonazza और यही वह जगह है जहां मेरा बाद वाला प्रश्न फिर से उठता है, क्योंकि प्लगइन रेप्रो के साथ सबमॉड्यूल का उपयोग करना संभव नहीं लगता है क्योंकि उस रेपो को डाउनलोड के लिए उपयुक्त होने के लिए पूर्ण फ़ाइल पदानुक्रम को शामिल करने की आवश्यकता होगी, .git को मजबूर करना

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

@Zylann हाँ, मैं सबमॉड्यूल्स के बारे में अपनी टिप्पणी में यही प्राप्त कर रहा था। वर्तमान में परियोजना संरचना पर मौजूदा प्रतिबंधों के कारण यह संभव नहीं है, लेकिन इस संबंध में संपत्ति lib tob को अधिक लचीला बदलना तुच्छ होगा।

संपादित करें: इसे पीछे की ओर संगत तरीके से भी किया जा सकता है।

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

इसमें जटिल क्या है? एक एक आवश्यकता है जिसे लागू किया जा सकता है
एक साधारण चेक और दूसरा एक साधारण मिलान है और प्रतिस्थापित करें or
संलग्न/प्रीपेन्ड। यह वास्तव में निर्भरता समर्थन में जोड़ने से आसान है।

मंगलवार, 3 जुलाई 2018 को दोपहर 12:11 बजे जॉन बोनाज़ा नोटिफिकेशन @github.com ने लिखा:

@ टू-टोन https://github.com/Two-Tone क्षमा करें, लेकिन "बहुत पागल" मेरा मतलब था
"बहुत जटिल" क्योंकि यह हमें पकड़ने के लिए त्वरित समाधान माना जाता है।
मैं सहमत हूं कि दीर्घावधि में, उचित संघर्ष समाधान आवश्यक है, लेकिन
मैं उम्मीद कर रहा था कि हम अंतरिम में इसके बिना ही दूर हो सकते हैं।

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

@ टू-टोन आप केवल फ़ोल्डर का नाम नहीं बदल सकते क्योंकि प्लगइन के कोड में स्क्रिप्ट अक्सर सीधे एडऑन के पथ का उपयोग करते हैं। उदाहरण के लिए

extends "res://addons/foo/bar.gd"

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

फिर ऐड-ऑन फ़ोल्डर संरचना जैसा मैंने कहा है, लेकिन अनिवार्य है, फिर पर
समय स्थापित करें बस स्ट्रिंग वर्ग के कार्यों को ढूंढें और बदलें का उपयोग करें
देखने के लिए हर स्क्रिप्ट पर है

'विस्तारित' res://addonname/ '

और इसके साथ बदलें

'विस्तारित' res://addonname-versionnumber/ '

ये कोड में कठिन समस्याएं नहीं हैं। वे सी ++ के लिए वास्तव में सरल धन्यवाद हैं।
इन समस्याओं को ठीक करने के लिए ये ज्यादातर सिर्फ उपयोगकर्ता की समस्याएं हैं
हमें कुछ सामान अनिवार्य करना है। यदि वे कोई प्लग-इन अपलोड करते हैं और उपयोगकर्ता पाते हैं कि
यह पूरी तरह से टूट गया है क्योंकि देव ने इन अविश्वसनीय रूप से पालन नहीं किया
सरल नियम, तो वह प्लग-इन डेवलपर पर है।

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

बुध, 4 जुलाई 2018 को दोपहर 12:48 बजे मार्क नोटिफिकेशन @github.com ने लिखा:

@jonbonazza https://github.com/jonbonazza मैं जोड़ूंगा, यह सिर्फ नहीं है
स्क्रिप्ट जो ऐसा करती हैं, लेकिन कोई भी संपत्ति दूसरे को संदर्भित करती है।

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

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

यह जो हल करता है वह निर्भरता का मुद्दा नहीं है बल्कि निर्भरता संघर्षों का समाधान है। एक प्लग-इन किसी भिन्न ऐड-ऑन के संस्करण 1 पर निर्भर हो सकता है और दूसरा संस्करण 2 पर निर्भर हो सकता है, इसके बिना या इसके समान कुछ हमारे पास या तो विरोध होगा या उपयोगकर्ता को प्लगइन्स का उपयोग करने में सक्षम होने से प्रतिबंधित करना होगा परस्पर विरोधी निर्भरताएँ हैं।

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

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

एकमात्र समाधान जिसके बारे में मैं सोच सकता हूं वह है जीडीस्क्रिप्ट का विस्तार करना ताकि उपयोगकर्ता स्क्रिप्ट में निर्दिष्ट कर सके कि वे किस प्लगइन का उपयोग कर रहे हैं, फिर उस बिंदु से वे केवल extends "res://addonname/etc करते हैं और इंजन का उपयोग करके स्वयं को संभालते हैं सही रास्ता। हालांकि, यह निश्चित रूप से "बहुत जटिल" मुद्दे में आता है जिसका @jonbonazza ने उल्लेख किया है। लेकिन अल्पावधि के लिए इसे छोड़ा जा सकता है।

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

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

ईमानदारी से, मुझे लगता है कि एक अल्पकालिक समाधान के लिए कार्रवाई का सबसे अच्छा तरीका है कि एसेट लिब को समर्थन में बदल दिया जाए (हालाँकि _require_ क्योंकि पश्चगामी संगतता नहीं है) addons dir के तहत एक परत वाली परियोजनाओं की सेवा करने की क्षमता। उदाहरण के लिए

godot-tools.level-streamer/
    project.cfg

के बजाय

addons/
    godot-tools.level-streamer/
        project.cfg

इस तरह, हम केवल ऐडऑन के विवरण में निर्दिष्ट कर सकते हैं कि इसके लिए किसी अन्य ऐडऑन की आवश्यकता है।

यदि हम चाहें तो यह हमें हमारे प्रोजेक्ट में ऐडऑन के लिए आसानी से gitsubmodules का उपयोग करने की अनुमति देगा।

डीपीएस (उदाहरण के लिए dep/ ) के लिए ऐसा करने के बारे में क्या रूट निर्देशिका या उपयोगकर्ता परिभाषित फ़ोल्डर में मैन्युअल रूप से स्थापित प्लग-इन हैं? इस तरह निर्भरता जड़ को अव्यवस्थित नहीं कर रही है और एडॉन्स या तो हो सकते हैं या?

$UserSetLocation/
    godot-tools.level-streamer/
        project.cfg

deps/
    thing-level-streamer-uses/
        project.cfg

@ टू-टोन लेकिन फिर क्या होगा यदि आपकी निर्भरता पर निर्भरता है? क्या डीपीएस फ़ोल्डर इसके बजाय प्लगइन का सबफ़ोल्डर नहीं होना चाहिए, इस तरह आप आवश्यकतानुसार मनमाने ढंग से गहराई तक जा सकते हैं?

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

कहा जा रहा है...

@willnationsdev यह काम कर सकता है, लेकिन यदि कई प्लगइन्स एक ही निर्भरता पर भरोसा करते हैं, तो आपके पास उस निर्भरता की कई प्रतियां हैं जहां केवल ऐसा होना चाहिए ... दो।

हां, निर्भरता प्रबंधन कोई साधारण बात नहीं है। अन्यथा npm को उतना जटिल होने की आवश्यकता नहीं होगी और yarn को बनाने की आवश्यकता नहीं होगी।

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

उदाहरण के लिए, नोड.जेएस वेब देव में, नोड_मॉड्यूल्स के अंदर क्या है, इसे अनदेखा करना कुछ हद तक ठीक है, जब तक कि यह काम करता है क्योंकि यह केवल सर्वर पर तैनात किया जाएगा। एक गेम के लिए, आप उस सभी कोड/परिसंपत्तियों को अंतिम ऐप पैकेज में पैकेजिंग करेंगे और उसी निर्भरता को n बार दोहराया जाना बहुत बुरा है।

इन समस्याओं के कारण मेरे शुरुआती सुझावों ने कहा कि संपत्ति को अभी तक निर्भरता को परिभाषित नहीं करने देना है, लेकिन परियोजना की निर्भरता को सूचीबद्ध करने का एक तरीका है, और उपयोगकर्ता को संपत्ति की किसी भी निर्भरता को मैन्युअल रूप से स्थापित करने दें:
https://github.com/godotengine/godot/issues/19486#issuecomment -399559419

यदि हमारे पास संपत्ति निर्भरता को परिभाषित करती है, तो मुझे लगता है कि वे सभी एक ही स्तर ( res://addons फ़ोल्डर में) पर स्थापित होना चाहिए। निर्भरता संस्करण संघर्षों के लिए (दो संपत्तियां एक ही संपत्ति पर निर्भर करती हैं लेकिन इसके विभिन्न संस्करण) मुझे लगता है कि एक साधारण संकल्प सबसे अच्छा होगा, जैसे हमेशा नए संस्करण के लिए जाना।

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

मुझे नहीं लगता कि निर्भरता को संपत्ति के सबफ़ोल्डर के रूप में रखना एक अच्छा विचार है क्योंकि यह एक ऐसे रास्ते की ओर ले जा रहा है जो बहुत जटिल होगा।
यदि हमारे पास संपत्ति निर्भरता को परिभाषित करती है, तो मुझे लगता है कि उन सभी को एक ही स्तर पर स्थापित किया जाना चाहिए ( res://addons folder . में)

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

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

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

मुझे ऐसा लगता है कि इस संपूर्ण निर्भरता के मुद्दे के बारे में बहुत सोचा जा रहा है

@ LikeLakers2 उचित निर्भरता प्रबंधन और संघर्ष से बचाव एक महत्वपूर्ण और कठिन मुद्दा है। इसकी इतनी चर्चा हो रही है कि

मुझे नहीं लगता कि यह बातचीत इस समय जिस तरह से चल रही है, उसी के साथ खत्म होगी।

निर्भरता लाने वाली सभी समस्याओं का पता लगाए बिना इसे आगे बढ़ाने की कोशिश करना एक बहुत बुरा विचार होगा और इससे और अधिक समस्याएं पैदा होंगी। यह एक कठिन मुद्दा है और इसमें समय लगेगा।

निर्भरता संस्करण संघर्षों के लिए (दो संपत्तियां एक ही संपत्ति पर निर्भर करती हैं लेकिन इसके विभिन्न संस्करण) मुझे लगता है कि एक साधारण संकल्प सबसे अच्छा होगा

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

जैसे हमेशा नए संस्करण के लिए जाना

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

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

@Zylann तब हमारे पास वह समस्या है जहाँ उपयोगकर्ता x प्लगइन स्थापित नहीं कर सकता क्योंकि y उसी निर्भरता के भिन्न संस्करण का उपयोग करता है। यह उपयोगकर्ताओं द्वारा अच्छी बात के रूप में नहीं देखा जाएगा

मैं @willnationsdev और @LikeLakers2 . से सहमत हूं

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

बहुत ज्यादा बाइक शेडिंग। यह एक गेम इंजन है, गेम-इंजन-एडऑन-डिलीवरी-प्लेटफॉर्म नहीं। प्रत्येक ऐडऑन निर्देशिका में बस विक्रेता निर्भरता और इसे एक दिन कहते हैं। कुछ अक्षमता की कीमत पर संस्करण संघर्ष या प्रबंधन या w/e के बारे में कोई तनाव नहीं। यदि ऐडऑन का उपयोगकर्ता प्रदर्शन के बारे में चिंतित है तो उन्हें GDNative या मॉड्यूल जैसे वास्तविक प्रदर्शन अनुकूलन पर विचार करने की स्थिति में होना चाहिए। मैं यह भी नहीं सोच सकता कि किसी भी एडऑन का गहरा निर्भरता ग्राफ क्यों होगा। एक ऐडऑन को दूसरे पर निर्भरता होने का एकमात्र कारण यह है कि यदि वह इसे किसी तरह से बढ़ाता है: SweetFpsController -> SweetFpsController w/ flying । उस स्थिति में मैं कहूंगा कि यह दो परियोजनाओं या उनके उपयोगकर्ताओं पर निर्भर है कि वे इंजन को जिम्मेदारी देने के बजाय अपने युग्मन को समेटें।

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

• आम तौर पर, एक्स का संस्करण 2 संस्करण 1 के साथ पिछड़ा-संगत होना चाहिए, और इस तरह चीजों को सरल रखना चाहिए (याद रखें कि जब मैंने प्लगइन विकसित करते समय मानसिकता का उल्लेख किया था)।
• यदि आप X के नवीनतम संस्करण का उपयोग नहीं कर सकते हैं, तो इसका समर्थन करने के लिए प्लगइन A की प्रतीक्षा करें और पिछले संस्करण को डाउनलोड करें (हमें विभिन्न संस्करणों को प्राप्त करने के लिए एसेटलिब एपीआई की आवश्यकता है, न कि केवल नवीनतम, जिसे करना कठिन नहीं होना चाहिए)। यह मॉड की तरह है, इसका सही होना जरूरी नहीं है।
• एक्स का प्लगइन निर्माता इसे एक अलग प्लगइन के रूप में अपलोड करता है (क्योंकि एपीआई संगतता को तोड़ता है), ठीक उसी तरह जैसे हमें गोडोट 3 के बाहर जाने पर करना था। तो फिर आपके पास दो बार एक ही प्लगइन होगा, लेकिन यह ठीक है क्योंकि वे वास्तव में वैसे भी समान होने के लिए बहुत अलग हैं, और इसके आधार पर सामान भी काम करेगा। यह प्लगइन डेवलपर द्वारा केवल एक फ़ोल्डर का नाम बदलने के लिए भी हो सकता है, यहां तक ​​​​कि दो संपत्ति lib प्रविष्टियों की भी आवश्यकता नहीं है।

सबसे खराब स्थिति में आपको यह काम मैन्युअल रूप से करना होगा (और अंततः प्लगइन निर्माता के लिए पीआर संगतता)।

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

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

@Zylann मेरे द्वारा सुझाए गए विकल्पों में से कोई भी विकल्प कैसे बेहतर है? और किसी विशिष्ट स्ट्रिंग में टेक्स्ट खोजने और जोड़ने के बारे में जादुई कुछ भी नहीं है।

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

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

विकल्प 3 एक बार फिर प्लगइन डेवलपर्स के लिए चीजों को और अधिक कठिन बना देता है।

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

मुझे ऐसा लगता है कि लोग इसे जरूरत से ज्यादा जटिल बनाने की कोशिश कर रहे हैं।

उचित निर्भरता प्रबंधन और संघर्ष से बचाव एक महत्वपूर्ण और कठिन मुद्दा है। इसकी इतनी चर्चा हो रही है कि

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

निर्भरता लाने वाली सभी समस्याओं का पता लगाए बिना इसे आगे बढ़ाने की कोशिश करना एक बहुत बुरा विचार होगा और इससे और अधिक समस्याएं पैदा होंगी। यह एक कठिन मुद्दा है और इसमें समय लगेगा।

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

मैं इस बात से थोड़े नाराज़ हूँ कि यह बातचीत बिना किसी प्रगति के कितने समय से चल रही है। गंभीरता से।

अलग-अलग रास्तों वाले दो संस्करण एक कठिन समस्या नहीं है

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

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

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

इस धागे में सब कुछ पर +1 - प्लगइन मॉड्यूल का विस्तार करना और संपत्ति के उपयोग में वृद्धि करना जाने का रास्ता है

एकता को आजमाने और सीखने के बाद, अब मेरे पास एक स्पष्ट विचार है कि यह कैसा होना चाहिए।

फर्स्ट इज यूनिटी में अब एक 'पैकेज मैनेजर' है, जिसका उपयोग वे उपयोगकर्ताओं को यह चुनने के लिए करते हैं कि वे इंजन के किन घटकों को इंस्टॉल/अनइंस्टॉल करना चाहते हैं। ऐसा लगता है कि वे भविष्य में इसका इस्तेमाल एसेट स्टोर के लिए भी कर सकते हैं।

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

साथ ही, सामान्य "मॉड्यूल" को साझा पुस्तकालयों (dll/.so फ़ाइलें) के रूप में बनाया जाना चाहिए ताकि उन्हें पैकेज मैनेजर में इंस्टॉल/अनइंस्टॉल के लिए चुना जा सके।

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

पैकेजों की एक सार्वजनिक रजिस्ट्री की आवश्यकता होगी।

यह समुदाय को आसानी से गोडोट की क्षमताओं का विस्तार करने और आसानी से एक दूसरे के कार्यों पर निर्माण करने में सक्षम करेगा। मुझे लगता है कि इससे सामुदायिक विकास को काफी बढ़ावा मिलेगा।

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

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

एकता पहले से ही अपने पैकेज के विभिन्न संस्करणों, उनके संपादकों, या कुछ विशिष्ट पैकेज संयोजनों को स्थापित (या स्थापित नहीं), या यहां तक ​​​​कि जिस क्रम में वे स्थापित किए गए थे, के साथ मुद्दों, क्रैश और संगतता समस्याओं में चलती है।

यह बहुत सी अतिरिक्त जटिलता है जिसे अच्छी तरह से प्रबंधित करने की आवश्यकता है, ऐसा न हो कि हम निर्भरता नरक में समाप्त हो जाएं :)

निर्भरता नरक के संबंध में, क्यों न AppImage जैसी किसी चीज़ से एक पृष्ठ लिया जाए और प्लगइन वितरकों को संपत्ति/फ़ाइल निर्भरताओं के प्रबंधन के लिए जिम्मेदार बनाकर निर्भरता की समस्याओं से बचने का प्रयास किया जाए? यहां बताया गया है कि मैं इस समस्या को कैसे देखता हूं ...

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

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

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

मुझे यकीन है कि यह इस जटिल समस्या के समाधान के लिए बहुत अधिक अनुभवहीन है, लेकिन मैं अपने कस्टम फ़ॉन्ट पैच के कारण हाल ही में प्लगइन सिस्टम के बारे में सोच रहा था। मुझे लगता है कि सबसे अच्छा उपयोगकर्ता अनुभव वह है जहां उन्हें निर्भरताओं के बारे में चिंता करने की ज़रूरत नहीं है, और डेवलपर्स वे हैं जिन्हें अपनी निर्भरताओं के प्रबंधन से संबंधित होना चाहिए। इससे उपयोगकर्ता के लिए प्रबंधन करना आसान हो जाता है: एक प्रोजेक्ट में फ़ाइल सिस्टम डॉक में एकल फ़ाइल के रूप में उनके ऐडऑन का प्रतिनिधित्व हो सकता है, आप राइट क्लिक कर सकते हैं और अतिरिक्त विकल्प प्राप्त कर सकते हैं ( extract files (विकास के लिए), update plugin (आसान अपडेट के लिए), वेबसाइट पर जाएं ( for easy community organization )) और किसी दिए गए 'कंटेनर' ( extends "[path-to-addon-tar]://ClassName" ) के भीतर कक्षाओं को भी संदर्भित करें।

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

पिछले 2 सेंट के आधार पर सिर्फ 2 सेंट (क्या यह इसे 4 मील बनाता है?):
मुझे लगता है कि .tar संग्रह अधिकांश उपयोगकर्ताओं (अहम, विंडोज़ उपयोगकर्ताओं) के लिए थोड़ा अपरिचित होगा, इसलिए .zip अभिलेखागार का उपयोग करना बेहतर हो सकता है, क्योंकि उनके पास कुछ हद तक व्यापक समर्थन है।

कहा जा रहा है, गोडोट के अपने .pck प्रारूप में प्लगइन्स को वितरित करने के बारे में क्या? मेरे पास कुछ विपक्ष हैं (जैसे कि अधिकांश अनुप्रयोगों द्वारा अपरिचित होना), लेकिन यह इसे और अधिक मानक और उपयोग करने का मौका हो सकता है।

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

कहा जा रहा है, गोडोट के अपने .pck प्रारूप में प्लगइन्स को वितरित करने के बारे में क्या? मेरे पास कुछ विपक्ष हैं (जैसे कि अधिकांश अनुप्रयोगों द्वारा अपरिचित होना), लेकिन यह इसे और अधिक मानक और उपयोग करने का मौका हो सकता है।

निश्चित रूप से, मेरा मतलब ज्यादातर सामान्य पैक संग्रह प्रकार के उदाहरण के रूप में .tar था। यह गोडोट के .pck प्रारूप का उपयोग कर सकता है और शायद करना चाहिए।

ज़िप का उपयोग क्यों न करें क्योंकि यह संपीड़न प्रदान करता है और एक मानक प्रारूप है?

@Calinou मैं सहमत हूँ। अगर हम यह अनिवार्य करते हैं कि .pck फाइलों का उपयोग किया जाना चाहिए, तो लोगों को चीजों को पैक करने के लिए गोडोट इंजन का उपयोग करना होगा, बजाय इसके कि उनका पसंदीदा पैकिंग टूल उपयोग के लिए अपने प्लगइन को बंडल करने के लिए है। GitHub रिपॉजिटरी को .zip फाइलों के रूप में भी डाउनलोड करता है और इसमें अब तक Godot प्लगइन्स का सबसे बड़ा संग्रह है।

मैं यहाँ सहमत हूँ। मुझे नहीं लगता कि किसी अन्य फ़ाइल प्रकार को बनाने की आवश्यकता है। ज़िप फ़ाइलें बहुत अच्छी तरह से काम करती प्रतीत होती हैं, और लोगों के पास संपत्ति पुस्तकालय के माध्यम से गोडोट इंटरफ़ेस का उपयोग करके स्थापित करने का विकल्प होता है, या वे स्वयं मैन्युअल रूप से डाउनलोड कर सकते हैं। a.pck फ़ाइल उस विकल्प की अनुमति नहीं देती है।

मेरी आदर्श दुनिया में, मैं https://godotengine.org/download पर दो डाउनलोड बटन रखना चाहूंगा:

• एक चिकना न्यूनतम डाउनलोड जो reduz तीन आवश्यकताओं को पूरा करता है, और
• सभी स्वीकृत और नियमित रूप से बनाए गए प्लगइन्स के साथ एक ब्लोट डाउनलोड जो कुछ गुणवत्ता नियंत्रण को पार कर गया है, इसलिए मुझे पता है कि उनका एपीआई कम से कम कोर के साथ-साथ न्यूनतम संस्करण से एपीआई के साथ काम करता है।

और भी आदर्श:
चुनें और मिलाएँ। न्यूनतम डाउनलोड करने पर, मैं न्यूनतम संस्करण + प्लगइन "थीम्स" का चयन कर सकता हूं। जो सामान्य उपयोग के मामलों के लिए आवश्यक सामान्य प्लगइन्स का संग्रह है। (उदाहरण के लिए: 2DPixelart, 3D FirstPersonShooter, 3D ThirdPerson, RTS, RPG, 2.5D गेम, 2DCutout, Rougelike, ManagementSim, Sidescroller, Eventpackage, Shaderpackage, Scriptpackage, Assetpackace, ect)। इसलिए जब मैं इंजन शुरू करता हूं तो आवश्यक प्लगइन्स पहले से ही स्थापित होते हैं और जाने के लिए तैयार होते हैं और मुझे पता है कि वे काम करते हैं क्योंकि उन्हें स्वीकृत किया गया है।
अधिक उन्नत उपयोगकर्ता उन थीम संग्रहों के भीतर अलग-अलग प्लगइन्स को अनचेक कर सकते हैं यदि वे जानते हैं कि उन्हें उनकी आवश्यकता नहीं है, या दो या दो से अधिक प्लगइन थीम्स को जोड़ सकते हैं, या कस्टम पैकेज बनाने के लिए स्वीकृत प्लगइन्स के पूल से थीम में अतिरिक्त सिंगल प्लगइन्स जोड़ सकते हैं।

आदर्श रूप से, परिणाम यह होगा कि https://godotengine.org/download उन विकल्पों में से _one download link on the fly_ बनाता है।

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

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

पहली बार संपादक चलाते समय अतिरिक्त [केवल आधिकारिक?] प्लगइन्स स्थापित करने के लिए कहना एक आसान समाधान होगा। वर्तमान में हमारे पास एसेटलिब खोलने का विकल्प है यदि परियोजना सूची खाली है; गोडोट को पहली बार चलाने पर आधिकारिक प्लगइन्स स्थापित करने के लिए संवाद पॉपअप क्यों नहीं है?

https://github.com/godotengine/godot-proposals/issues/142 , https://github.com/godotengine/godot-proposals/issues/577 और https://github.com/godotengine/ के पक्ष में समापन गोडोट

aaronfranke से संपादित करें: https://github.com/godotengine/godot-proposals/issues/554 भी देखें