Yarn: ड्रॉप 'इकाई' प्रत्यय

यह सिर्फ नियमित संस्थाओं के लिए Entity गिर रहा है और BlockEntities नहीं, हाँ?

हां।

स्पंज Entity प्रत्यय का भी उपयोग नहीं करता है।

+1 लेकिन क्या उस तर्क का उपयोग ब्लॉक जैसी चीज़ों के लिए भी नहीं किया जा सकता है? यह लगभग कभी नहीं टकराता। मुझे ब्लॉक का विचार पसंद है। छाती लेकिन अगर आप कुछ ऐसा बना रहे हैं जो सख्ती से संबंधित नहीं है, तो यह अजीब होगा।

मैं निरंतरता के लिए असहमत हूं

साथ बात Block प्रत्यय, IMO, कि यह न सिर्फ एक ब्लॉक है, लेकिन ब्लॉक को दर्शाता है। उदाहरण के लिए घास लेने के लिए, वहाँ एक की ही कभी एक उदाहरण है GrassBlock किसी भी समय है, इसलिए इसे कहते हैं "इस घास ब्लॉक कि" सुरक्षित है। संस्थाएं वास्तव में इस तरह काम नहीं करती हैं, क्योंकि दुनिया में हर एक के लिए इकाई का एक उदाहरण है। तो, एक और उदाहरण के रूप में, लाश के साथ, आप यह नहीं कह सकते हैं, "इस ज़ोंबी है" कई लाश देखते हैं, न सिर्फ एक है। आप कहेंगे "यह एक ज़ोंबी है"।

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

हम्म, गिरने वाले ब्लॉक के बारे में कैसे?

@Sorixelle वास्तव में एक अच्छा बिंदु बनाता है। लेकिन मुझे लगता है कि हमें प्रत्यय के लिए एक कारण खोजना चाहिए, हाँ, नाम पर नहीं होना अच्छा है, लेकिन यह सुसंगत नहीं है।

तो ZombieEntity का अर्थ लाश के लिए Entity प्रकार है?

क्या उस तर्क का उपयोग ब्लॉक जैसी चीजों के लिए भी नहीं किया जा सकता है?

मैं निरंतरता के लिए असहमत हूं

अंतर यह है कि हम कहते हैं "मेरे पास 5 पत्थर के ब्लॉक हैं" ("5 पत्थर" नहीं), लेकिन "मेरे पास 5 भेड़ें हैं" ("भेड़ संस्थाएं" नहीं)।

यदि आप कहते हैं "मेरे पास 5 पत्थर हैं" तो कृपया :+1: यह अंक

कल्पना कीजिए कि हमने कक्षाओं का नाम SheepThing और ItemThing ।

हमारे पास ठीक यही है, क्योंकि "इकाई" "चीज़" और "ऑब्जेक्ट" का पर्यायवाची है ।

क्या "इकाई" "चीज़" और "ऑब्जेक्ट" का पर्याय है? हां।

क्या इसका मतलब यह है कि इकाई Minecraft में कुछ और विशिष्ट नहीं हो सकती है?

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

क्या आप SheepDynamicObject या SheepGameObject नामों के साथ ठीक रहेंगे?

"लेख", "वस्तु" और "वस्तु" "वस्तु" के पर्यायवाची हैं । क्या हमें SwordItem का नाम बदलकर SwordArticle , SwordObject या SwordThing ?

मुद्दा यह है कि SheepThing और ItemThing अर्थहीन भिन्नताएं हैं जब "इकाई" की अवधारणा को Minecraft में "चीज" या "ऑब्जेक्ट" की तुलना में अधिक विशिष्ट के रूप में परिभाषित किया जाता है, जैसे "आइटम"।

मैं यह नहीं कह रहा हूं कि इकाई अर्थहीन है। मैं कह रहा हूं कि यह एक सामान्य शब्द है जो सभी गतिशील चीजों के लिए उपयोग किया जाता है, वैसे ही हमारे पास java.lang.Object , लेकिन StringObject , IntegerObject आदि नहीं है।

उस तुलना के द्वारा मैं जो बिंदु बनाने की कोशिश कर रहा था वह यह था कि यदि Mojang ने इसके बजाय Entity Thing दिया होता, तो क्या आप अभी भी SheepThing , ItemThing ?

"लेख", "वस्तु" और "वस्तु" "वस्तु" के पर्यायवाची हैं । क्या हमें SwordItem का नाम बदलकर SwordArticle , SwordObject या SwordThing ?

मुद्दा यह है कि SheepThing और ItemThing अर्थहीन भिन्नताएं हैं जब "इकाई" की अवधारणा को Minecraft में "चीज" या "ऑब्जेक्ट" की तुलना में अधिक विशिष्ट के रूप में परिभाषित किया जाता है, जैसे "आइटम"।

मुझे लेख या चीज़ में आइटम नामों के साथ इसे और अधिक जटिल बनाने का कोई कारण नहीं दिख रहा है।

शुल्कर इस बात के महान उदाहरण हैं कि जहां इकाई संकेतन को हटाने से समान नामकरण परिदृश्य और एक ही नाम की एक ब्लॉक इकाई, ब्लॉक और इकाई परिभाषा के कारण चीजें भ्रमित हो सकती हैं।

मैं यह नहीं कह रहा हूं कि इकाई अर्थहीन है। मैं कह रहा हूं कि यह एक सामान्य शब्द है जो सभी गतिशील चीजों के लिए उपयोग किया जाता है, वैसे ही हमारे पास java.lang.Object , लेकिन StringObject , IntegerObject आदि नहीं है।

java.lang.Object प्रत्येक वर्ग का एक सुपरक्लास है, और इकाई वर्ग उसी का एक अंश बनाते हैं।

उदाहरण के लिए, आप आइटम को ItemEntity से कैसे अलग करेंगे।
इसके अलावा, जावा मानक EnumSet, EnumMap आदि दिखाता है, इसलिए बेस क्लास एक्सटेंडर का हिस्सा है
कंपाउंडटैग, लिस्टटैग, स्ट्रिंगटैग...

सुपर टाइप जोड़ना आम बात है

Drop के लिए इकाई के लिए ItemType रजिस्ट्री तत्व के लिए

minecraft:item रजिस्ट्री Registry की Item , न कि ItemType , और इकाई प्रकार आईडी minecraft:item इसलिए यह ItemEntity ।

ज़रूर, Entity प्रत्यय रखना कोई बड़ी बात नहीं है। हम उसके साथ रह सकते है।

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

उस तुलना के द्वारा मैं जो बिंदु बनाने की कोशिश कर रहा था, वह यह था कि अगर Mojang ने इसके बजाय Entity Thing दिया होता, तो क्या आप अभी भी SheepThing , ItemThing ?

हां, क्योंकि उस मामले में Thing का एक विशिष्ट अर्थ होगा।

जैसे यानिस ने कहा, प्रत्यय को छोड़ने से केवल भ्रम होता है। नाम स्पष्टता के लिए हैं, न कि "अच्छे दिखने" के लिए।

नाम स्पष्टता के लिए हैं, न कि "अच्छे दिखने" के लिए।

प्राकृतिक लगने वाले नाम स्पष्टता के समान ही महत्वपूर्ण हैं।

कल्पना कीजिए कि मैंने Minecraft खेलते समय कहा था "मैं कुछ कच्चे बीफ़ आइटम प्राप्त करने के लिए कुछ गाय संस्थाओं को मारने जा रहा हूँ और फिर उन्हें पके हुए बीफ़ आइटम में बदलने के लिए एक भट्टी ब्लॉक का उपयोग कर रहा हूँ"।

हमारे सोचने और बोलने के तरीके से मेल खाने वाला कोड बहुत अच्छी बात है।

आपके पास एक ही समय में दोनों हो सकते हैं: एक प्राकृतिक आधार (गाय, कच्चा बीफ़, भट्टी), और एक स्पष्ट प्रत्यय (इकाई, वस्तु, ब्लॉक)।

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

अभी भी ItemEntity की समस्या है।

हाँ Item एकमात्र कारण है कि मुझे यह काम नहीं दिख रहा है। मैं शायद इसके लिए तब तक सहमत नहीं होता जब तक कि हमने Item -> ItemType लेकिन खेल में वस्तुओं की कतरनी मात्रा के कारण यह एक बड़ा नाम है।

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

ItemEntity -> DroppedItem , जिस तरह से हमारे पास ThrownSnowballEntity

हम जानते हैं कि गाय संस्थाएं हैं और गोमांस एक वस्तु है। कोई भी "गाय इकाई" या "गोमांस वस्तु" नहीं कहता है, तो हमें कोड लिखते/पढ़ते समय ऐसा क्यों कहना/पढ़ना चाहिए?

समाधान से कोई फर्क नहीं पड़ता असंगत होना एकमात्र अन्य विकल्प है।

प्रत्यय को छोड़ने से विभिन्न रजिस्ट्रियों की सामग्री के लिए कक्षाओं के साथ समस्याएँ उत्पन्न होंगी। Item आधार वर्ग को निश्चित रूप से इस तरह नामित किया गया है क्योंकि इसमें पहचानकर्ता minecraft:item का उपयोग करके इसकी (या इसके उपवर्गों) से भरी एक रजिस्ट्री मौजूद है। इसी तरह, ItemEntity इकाई वर्ग को निश्चित रूप से इस तरह नामित किया गया है क्योंकि इसका संबंधित इकाई प्रकार minecraft:entity_type रजिस्ट्री में minecraft:item रूप में पंजीकृत है। वर्तमान Item वर्ग Item रूप में रहेगा, लेकिन ItemEntity वर्ग भी Item बन जाएगा।

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

प्रत्ययों को छोड़ने का पूरा विचार जावा मानक के साथ भी असंगत है (सूची या मानचित्र के कार्यान्वयन देखें), जैसा कि पहले उल्लेख किया गया है ।

मैं शायद इसके लिए तब तक सहमत नहीं होता जब तक कि हमने Item -> ItemType लेकिन खेल में वस्तुओं की कतरनी राशि के कारण यह एक बड़ा नाम है।

मुझे यकीन है कि जैसे ही Mojang वस्तुओं को डेटा-चालित बनाता है, एक ItemType , इसलिए अभी के लिए इस पर रोक लगाना सबसे अच्छा है। साथ ही, यह अभी भी पहचानकर्ता और minecraft:x_type रजिस्ट्रियों के संबंध में हमारे वर्तमान सम्मेलनों के साथ असंगत होगा।

ItemEntity -> DroppedItem , वैसे ही जैसे हमारे पास ThrownSnowballEntity

एक बार फिर, यह जावा मानकों और यार्न मानकों के साथ असंगत होगा। मैं ThrownSnowballEntity बारे में किसी भी चर्चा के बारे में उत्सुक हूं, हालांकि इसके पहचानकर्ता पर विचार करना minecraft:snowball ।

प्रत्ययों को छोड़ने का पूरा विचार जावा मानक के साथ भी असंगत है (सूची या मानचित्र के कार्यान्वयन देखें),

एक HashMap एक हैश नहीं है, बल्कि एक हैश [-आधारित] नक्शा है, और एक ArrayList एक सरणी नहीं है, बल्कि एक सरणी [-आधारित] सूची है। एक CowEntity एक गाय है। यह कहने जैसा है कि हमें "गाय" के बजाय "गाय का जानवर" कहना चाहिए क्योंकि हम "पेंसिल" के बजाय "पेंसिल शार्पनर" कहते हैं ...

जावा एडब्ल्यूटी देखें। सब कुछ Component तक फैला हुआ है, लेकिन हमारे पास Button बजाय ButtonComponent , Scrollbar बजाय ScrollbarComponent आदि। इसलिए यदि हम इसका पालन करते हैं जावा मानक, हमें प्रत्यय से छुटकारा पाना चाहिए।

यदि बाद वाले वर्ग का नाम बदलकर DroppedItem या इससे मिलते-जुलते नाम से इस विशिष्ट समस्या का समाधान किया गया, तो यह पहचानकर्ता से मेल नहीं खाएगा।

मैं मानता हूं कि पहचानकर्ताओं का मिलान करना कक्षाओं को खोजने में आसान बनाने के लिए महत्वपूर्ण है, लेकिन मुझे नहीं पता कि हमें इसे पूरी तरह से क्यों Dropped जोड़ना ठीक है।

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

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

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

पहचानकर्ता और minecraft:x_type रजिस्ट्रियों के संबंध में हमारे वर्तमान सम्मेलनों के साथ असंगत।

वह सम्मेलन समझ में नहीं आता है। रजिस्ट्रियां आइटम प्रकार और ब्लॉक प्रकार संग्रहीत करती हैं, न कि प्रत्येक व्यक्तिगत आइटम और ब्लॉक के उदाहरण। _type प्रत्यय पर भिन्नता Mojang द्वारा एक असंगति है, और हमें इसे कॉपी नहीं करना चाहिए, ठीक वैसे ही जैसे हम किसी पहचानकर्ता में टाइपो की प्रतिलिपि नहीं बनाते हैं।

ईमानदारी से कहूं तो रूण, "मैं कुछ गायों को मारने जा रहा हूं" तकनीकी समुदाय से आने वाले मेरे लिए स्वाभाविक लगने से बहुत दूर नहीं है।

यदि आप Minecraft को प्राकृतिक भाषा की तरह पढ़ना चाहते हैं, तो आप कई अन्य नाम बदल सकते हैं। "मैं कुछ पेड़ों की विशेषताओं को काटने जा रहा हूं" किसी के लिए भी अच्छा नहीं है। मतलब यह है कि हम नाम बदलने चाहिए TreeFeature करने के लिए Tree ? नहीं! लेकिन "गाय इकाई" वास्तव में अच्छी तरह से पढ़ती है। विशेष रूप से "सर्वर पिछड़ रहा है क्योंकि एक ही स्थान पर बहुत सारी गाय संस्थाएं हैं" जैसे संदर्भ में।

मतलब यह है कि हम नाम बदलने चाहिए TreeFeature करने के लिए Tree ?

हाँ, यहाँ Feature शब्द यहाँ बेमानी है। मैं फीचर कक्षाओं के अंत में Generator जोड़ने का भी सुझाव दूंगा, क्योंकि वे वास्तव में सुविधाओं के लिए जनरेटर हैं, न कि सुविधाओं के लिए। हमारे पास TreeGenerator extends FeatureGenerator जैसा कुछ होगा।

सर्वर पिछड़ रहा है क्योंकि एक ही स्थान पर बहुत सारी गायें हैं

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

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

लेकिन वे _are_ गाय संस्थाएं हैं, गाय नहीं। गाय का विचार केवल प्राकृतिक भाषा में मौजूद है - CowEntity विशेष रूप से गाय _entity_ को संदर्भित करता है, गाय की संपूर्ण अवधारणा को नहीं। आप उस वर्ग में गाय के अन्य भागों से संबंधित कोड नहीं डालेंगे - जैसे कि उसकी बूंदें।

यह बाइकशेडिंग बिल्कुल बेकार है ...

Entity प्रत्यय स्पष्ट है क्योंकि यह आपको "यह वर्ग क्या है?" पर संदेह नहीं करने देता। Minecraft के संदर्भ में Entity स्पष्ट रूप से थिंग का पर्याय नहीं है।

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

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

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

इसके अलावा, ठीक है प्राकृतिक भाषा शांत और सभी है, लेकिन यह गेम इंजन के लिए विशिष्ट है, एक उपन्यास की तरह कोड पढ़ने की कोशिश करना संभव नहीं है।

मुझे भी नहीं कहना होगा। ऐसे कई मामले हैं जब यह अस्पष्ट होगा (उपरोक्त ItemEntity , साथ ही ArrowEntity या TridentEntity )।

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

वोट को देखकर लगता है कि यह स्पष्ट है?

क्या आप कॉल करते हैं LivingEntity : Living या Entity : कुछ भी नहीं, प्रत्यय अन्य नामों के साथ संगति प्रदान करता है, मैं सहमत हूं @l-Luna के साथ CowEntity प्रतिनिधित्व नहीं करता है एक गाय यह एक CowEntity प्रतिनिधित्व करती है, एक Cow इकाई, उसकी बूंदों और उसके मॉडल/रेंडर-एर का प्रतिनिधित्व करती है। Entity प्रत्यय किसी को चोट नहीं पहुँचा रहे हैं, और मुझे लगता है कि वे कुछ स्पष्टीकरण जोड़ने में मदद करते हैं, साथ ही इस तथ्य के साथ कि BlockEntity एक प्रयुक्त प्रत्यय भी है। बस मेरे 2 सेंट।

क्या आप LivingEntity: Living या Entity कहते हैं:

मैं LivingEntity को "जीवित इकाई" कहता हूं, ताकि नाम बना रहे। मैं CowEntity को "गाय" कहता हूं, ताकि नाम बदल दिया जाए।

मेरी समस्या यह है कि आप चीजों को नाम देने की कोशिश कर रहे हैं जैसे कि यह केवल सर्वर-साइड था, निश्चित रूप से सर्वर-साइड पर CowEntity Cow नामकरण केवल एपीआई समझ में आता है क्योंकि यह सचमुच गाय की पूरी अवधारणा है एक सर्वर।

लेकिन यहां क्लाइंट भी है, CowEntity Cow का नामकरण स्पष्ट रूप से गलत है क्योंकि गाय को इसके द्वारा परिभाषित किया गया है Entity जो कि गाय के गुणों को संभालने वाली वस्तु है, यह कैसे दुनिया और उसके लक्ष्यों के साथ बातचीत करता है; लेकिन इसके मॉडल और इसके रेंडरर द्वारा

CowEntity Cow नामकरण करके आप कक्षा के अर्थ का एक बड़ा हिस्सा छीन लेते हैं और फिर इसे भ्रामक बना देते हैं।

मैं इसके साथ ठीक रहूंगा यदि यार्न केवल सर्वर-साइड था, लेकिन ऐसा नहीं है।

सर्वर पर भी CowEntity पूरी तरह से एक गाय का प्रतिनिधित्व नहीं करता है क्योंकि इसमें डेटा-पैक में अलग से संग्रहीत लूट टेबल भी हैं। और जब तकनीकी रूप से बात कर रहा कह रहे हैं CowEntity के बजाय Cow । हम गेमप्ले ट्यूटोरियल नहीं बना रहे हैं, हम तकनीकी मैपिंग सेट बना रहे हैं। हाँ, आप सामान्य गेम-प्ले में ChestBlockEntity एक चेस्ट कहेंगे, लेकिन यह सामान्य गेम-प्ले नहीं है, यह मॉड-मेकिंग है, जहाँ आप ChestBlock को भ्रमित नहीं करना चाहते हैं, ChestBlockEntity और चेस्ट लूट टेबल। हां, आपको प्रत्यय को रखना चाहिए, भले ही वह रेंगने वालों के लिए बेमानी हो, क्योंकि अन्य सामान के लिए प्रत्यय बेमानी नहीं है ( LivingEntity , Entity , ItemEntity ), और IMO व्याकरणिक रूप से सही होने की तुलना में तकनीकी जानकारी में सुसंगत होना बेहतर है।

इसे बंद करना क्योंकि अधिकांश इसके खिलाफ हैं।