सामग्री अपडेट:
सभी उपकरणों के लिए सही Bedrock आधार चुनें
Minecraft Bedrock सर्वर पर संगत Bedrock खिलाड़ी एक ही दुनिया में खेल सकते हैं। फोन, टैबलेट और Windows साथ आ सकते हैं, यदि उनका संस्करण और प्रवेश रास्ता समर्थित हो। Java और Bedrock अलग protocols इस्तेमाल करते हैं। इसलिए केवल Minecraft नाम देखकर यह नहीं मानना चाहिए कि कोई भी client किसी भी server से जुड़ जाएगा।
सर्वर बनाने से पहले हर खिलाड़ी का उपकरण, Edition और वास्तविक version लिखें। Windows वाले से पूछें कि वह Java खोलता है या Bedrock। यह भी तय करें कि मौजूदा दुनिया लानी है, Java खिलाड़ियों को शामिल करना है या खास add-ons चाहिए। कंसोल के लिए बाहरी सर्वर जोड़ने की वास्तविक सुविधा अलग जांचें।
होस्टिंग Minecraft की लाइसेंस या Microsoft account उपलब्ध नहीं कराती। हर व्यक्ति को अपना गेम और multiplayer की जरूरी अनुमतियां चाहिए। वर्तमान software और योजना की सीमाएं कॉन्फिगरेटर में देखें। मुफ्त शुरुआत से आप compatibility जांच सकते हैं, लेकिन बड़ी दुनिया की आवश्यकता उसके व्यवहार, entities और विस्तारों से तय होती है।
Bedrock Dedicated Server और Geyser में अंतर समझें
Bedrock Dedicated Server मूल Bedrock दुनिया चलाता है। Java server पर Geyser लगाने से समर्थित Bedrock connections Java तक पहुंच सकते हैं, लेकिन दुनिया और उसकी आधारभूत mechanics Java की रहती हैं। दो रास्ते फोन को प्रवेश दे सकते हैं, फिर भी उनका world format और सामग्री का व्यवहार समान नहीं होता।
| आधार | कौन प्रवेश करता है | दुनिया किस प्रकार की रहती है |
|---|---|---|
| Bedrock Dedicated Server | संगत Bedrock clients | मूल Bedrock |
| बिना bridge का Java | संगत Java clients | Java |
| Geyser वाला Java | Java और समर्थित Bedrock clients | Java |
| Geyser और Floodgate वाला Java | वही समूह, Floodgate पहचान के साथ | Java |
यदि सब Bedrock खेलते हैं और स्रोत map Bedrock का है तो मूल Bedrock विकल्प पहले देखें। यदि Java दोस्त और compatible server plugins जरूरी हैं तो bridge वाले विकल्प की जांच करें। केवल crossplay शब्द पर्याप्त नहीं है। जिन menus, farms, commands और सामग्री पर आपका प्रोजेक्ट निर्भर है, उन्हें असली उपकरण से जांचें।
Floodgate Bedrock खाते को अतिरिक्त Java लाइसेंस के बिना प्रमाणित करने का तरीका देता है। खिलाड़ी को Bedrock की अपनी उपलब्धता फिर भी चाहिए। यह फोन में अनिवार्य Java client mods नहीं जोड़ता। ऐसे modpack को अलग समझें जिसमें नए blocks, interfaces या client code चाहिए।
फोन, Windows और कंसोल का प्रवेश अलग देखें
समर्थित Bedrock client में बाहरी सर्वर जोड़ते समय उसका host और port दिया जाता है। कंसोल की server सूची और विकल्प दूसरे हो सकते हैं। सभी platform के लिए एक ही menu क्रम का वादा करने से पहले वास्तविक उपकरण पर जांच करें।
| उपकरण | शुरुआत में क्या देखें | सामान्य गलतफहमी |
|---|---|---|
| Windows | वास्तविक Edition कौन सी खुली है? | Java को Bedrock समझ लेना |
| Android या iOS | stable version और बाहरी server entry | Preview या गलत port |
| कंसोल | platform का multiplayer और server access | सीमित server menu |
| Java कंप्यूटर | संगत Geyser bridge उपलब्ध है? | सीधे native Bedrock में प्रवेश की कोशिश |
यदि खाते में family restrictions हैं तो multiplayer की अनुमति जांचें। ऐसी रोक और server timeout अलग समस्याएं हैं। नया port या server restart खाते की अनुमति नहीं बदलता। उपकरण का पूरा error पढ़ें और समय लिखें, ताकि बाद में सही कारण की जांच हो।
कंसोल के लिए समुदाय के helper तरीके network, platform और update पर निर्भर हो सकते हैं। उन्हें hosting की सुनिश्चित सुविधा न मानें। Geyser के console दस्तावेज से सीमाएं समझें। महत्वपूर्ण पुरानी दुनिया स्थानांतरित करने से पहले कंसोल के खिलाड़ी से वास्तविक प्रवेश करवाएं।
चरण 1: कॉन्फिगरेटर में उचित सर्वर बनाएं
कॉन्फिगरेटर खोलें और अपने समूह की जरूरत से software मिलाएं। मूल Bedrock दुनिया के लिए Bedrock समर्थन चाहिए। Java और Bedrock समूह के लिए compatible Java base, bridge और Bedrock entry जरूरी है। किसी लोकप्रिय software नाम को उसकी capabilities जाने बिना न चुनें।
- native Bedrock या Java bridge का रास्ता तय करें।
- उसी रास्ते का उपलब्ध server software चुनें।
- client के साथ compatible version रखें।
- योजना के वर्तमान संसाधन और शर्तें पढ़ें।
- निर्माण पूरा करके panel में स्थापना खोलें।
- प्रक्रिया start करें और console में पूरा startup देखें।
- गेम host और आवंटित Bedrock port लिखें।
पहली दुनिया generate होने में समय लग सकता है। प्रक्रिया रुक जाए तो उसकी महत्वपूर्ण console error ठीक करें। फोन से कई बार join करना बंद server को चालू नहीं करेगा। server ready होने और फॉर्म जमा होने को अलग चरण मानें।
पहले नई साफ दुनिया में प्रवेश करें। फिर पुरानी map लाएं और अतिरिक्त सामग्री डालें। काम करने वाला पहला आधार तुलना का बिंदु देता है। अगर map और कई components साथ बदलेंगे तो एक error से कारण समझना कठिन होगा।
चरण 2: सही host और Bedrock port कॉपी करें
गेम data panel के web address से अलग है। client में https://, account page की path या खरीद की लिंक न डालें। server list में नाम केवल पहचान का label है। वास्तविक host और port उस स्थापना के लिए panel से लें।
Bedrock में आम तौर पर host और port अलग fields में भरते हैं। दोनों मित्रों को स्पष्ट रूप से दें। किसी दूसरे tutorial में दिखा सामान्य port आपकी network allocation का port जरूरी नहीं है। केवल file में संख्या बदलना प्रदाता की नई entry नहीं बनाता।
Geyser setup में Java और Bedrock ports अलग हो सकते हैं। सफल Java प्रवेश Bedrock रास्ते की पुष्टि नहीं है। Java नाम का SRV record भी अपने आप Bedrock के port field का विकल्प नहीं बनता। दोनों Editions के लिए अलग connection note रखें।
सामान्य Java connection TCP इस्तेमाल करता है, जबकि conventional Bedrock और Geyser entry में UDP चाहिए। वर्तमान native Bedrock release के लिए वास्तविक transport उसकी ताजा documentation से जांचें। पुराने गाइड के नियम हर आगे की release पर लागू मानना ठीक नहीं होगा। बाहरी hosting में उसका network entry घर के router से बाहर होता है।
चरण 3: असली Bedrock client से परीक्षण करें
compatible stable Bedrock खोलें और नया server entry बनाकर host तथा port भरें। Beta और Preview हमेशा stable server के protocol से मेल नहीं खाते। फोन स्वतः update हुआ हो तो client, server और bridge के वास्तविक versions देखें।
दुनिया में जाएं, कुछ दूरी चलें, block रखें, chest खोलें और inventory देखें। बाहर जाकर फिर प्रवेश करें। सूची में online response मिलना इन सभी कार्यों का प्रमाण नहीं है। केवल TCP port scan भी Bedrock protocol, authentication और सही दुनिया की जांच नहीं करता।
दूसरी internet connection वाले मित्र से प्रवेश करवाएं। mixed group में एक Java और एक Bedrock client एक ही समय आएं। वे एक-दूसरे को देखें और प्रोजेक्ट के जरूरी menus तथा commands इस्तेमाल करें। अलग उपकरणों के लिए बनाई दुनिया में उन मुख्य उपकरणों का परीक्षण आवश्यक है।
Minecraft की आधिकारिक joining गाइड, अंग्रेजी में मूल menus समझाती है। परीक्षण का उपकरण, version, समय और सफल कार्य लिखें। अगली automatic update के बाद यही नोट बताता है कि पहले किस configuration में प्रवेश काम करता था।
चरण 4: जरूरत होने पर Geyser और Floodgate लगाएं
Geyser का रूप वास्तविक server software और topology के अनुसार चुनें। plugin, loader component और अलग प्रक्रिया का configuration समान नहीं है। Geyser की स्थापना documentation से अपने रास्ते के लिए उचित विधि लें।
लक्षित Java server address और आवंटित Bedrock listening port जांचें। startup के बाद देखें कि bridge लोड हुआ और binding या version error नहीं है। अलग प्रक्रिया इस्तेमाल करते हैं तो ध्यान दें कि वह किस मशीन पर चलती है। वहां का localhost उसी मशीन को दर्शाता है।
Floodgate चाहिए तो आधिकारिक Floodgate setup के अनुसार सही authentication path रखें। keys और proxy configuration प्रशासनिक data हैं। सामान्य दोस्तों को गेम पता देने के लिए ये secrets नहीं चाहिए, इसलिए सार्वजनिक invitation में इन्हें शामिल न करें।
बिना समझे Java authentication बंद करना login समस्या का सामान्य समाधान नहीं है। पहले पहचानें कि failure account, bridge, key, version या अनुमति सूची में है। सुधार के बाद असली Bedrock account से फिर प्रवेश करें; मालिक का Java login पूरी chain का test नहीं करता।
अनुमति सूची और वास्तविक खिलाड़ी पहचान जांचें
निजी दुनिया के लिए supported allowlist इस्तेमाल करें। पता आगे साझा हो सकता है, इसलिए उसका जानना प्रशासनिक अधिकार का आधार न बने। installed software के अनुसार प्रवेश control और ordinary player permissions अलग समझें।
native Bedrock में उसी release की commands और allowlist format लें। Java की commands दूसरे software में सार्वभौमिक नहीं हैं। Bedrock Dedicated Server की आधिकारिक documentation configuration और administration का आधार देती है।
Geyser और Floodgate में server को दिखने वाली Bedrock identity जांचें। उसका नाम या identifier सामान्य Java account के representation से अलग हो सकता है। पहले एक व्यक्ति की entry और inventory जांचें, फिर समूह बढ़ाएं। इससे गलत identity को permission देने की संभावना घटती है।
प्रवेश की परेशानी दूर करने के लिए सबको operator न बनाएं। building, किसी menu का access और server administration अलग powers हैं। operator बिना सामान्य खाते का परीक्षण करें। diagnosis में दिए temporary अधिकार वापस लें और दोस्त की वास्तविक gameplay जरूरत तक permission रखें।
दुनिया आयात करते समय format न भूलें
Bedrock और Java worlds अलग formats इस्तेमाल करते हैं। directory का नाम बदलकर conversion नहीं होता। Bedrock export को भी server की अपेक्षित file structure में निकालना पड़ सकता है। upload से पहले source Edition, version और archive का प्रकार पहचानें।
पूर्ण original copy अलग बचाएं। target process रोकें, active world setting देखें और जरूरी files डालें। दुनिया की map के अलावा packages तथा संबंधित settings भी आवश्यक हो सकती हैं। दूसरे server software का एक folder पहचानकर केवल वही copy न करें।
startup के बाद परिचित भवन, spawn, player inventory और मुख्य dimensions जांचें। नई खाली दुनिया दिखे तो active path और archive के extra directory level देखें। इसका अर्थ हमेशा original data खोना नहीं है; server दूसरी जगह से दुनिया खोल रहा हो सकता है।
Editions के बीच conversion केवल copy पर जांचें। हर block, entity या add-on behavior पूरी तरह बच जाए, इसकी गारंटी न मानें। अपनी टीम के महत्वपूर्ण objects और mechanics की तुलना करके मुख्य दुनिया बदलने का निर्णय लें। original Edition और software की वापस जाने योग्य प्रति रखें।
Bedrock add-ons और Java plugins अलग रखें
native Bedrock के resource और behavior packs अलग mechanism हैं। Java server base plugins या loader के mods इस्तेमाल कर सकता है। नाम या file extension बदलकर ये समान नहीं बनते। चुनी गई सामग्री उसी आधार के लिए समर्थित होनी चाहिए।
Bedrock add-on में release compatibility, dependencies, world binding और जरूरी settings देखें। सक्रिय packages का record रखें। पहले से world content बनाने वाला package हटाना saved objects बदल सकता है। इसलिए copy बनाना installation change का जरूरी हिस्सा है।
Geyser वाले प्रोजेक्ट में वास्तविक Bedrock client से plugin features जांचें। Java inventory आधारित menus, custom items और client mods पर निर्भर functions सीमित हो सकते हैं। console में plugin दिखना फोन पर उसकी सुविधा सही चलने की पुष्टि नहीं है।
एक component जोड़कर startup, ordinary account login, permissions और saving जांचें। उसका version और परिणाम लिखें। फिर अगला component जोड़ें। किसी समस्या पर ज्ञात अच्छे set में लौटना आसान होगा, बजाय पूरी अनजान pack में failure का कारण तलाशने के।
connection किस चरण में विफल है, यह पहचानें
| दिखाई देने वाली समस्या | पहले क्या जांचें | सहायता के लिए उपयोगी जानकारी |
|---|---|---|
| server जोड़ने का विकल्प नहीं | platform की क्षमता | उपकरण और उपलब्ध menu |
| server उत्तर नहीं देता | प्रक्रिया, host और Bedrock port | सही data और प्रयास का समय |
| Java चलता है, Bedrock नहीं | Geyser और Bedrock entry | bridge version तथा महत्वपूर्ण log |
| incompatible version | client, server और bridge release | सभी वास्तविक version numbers |
| login अस्वीकार | account, Floodgate और allowlist | पूरा संदेश, secrets के बिना |
| प्रवेश है, सुविधा नहीं चलती | permissions और plugin compatibility | दोहराने योग्य steps |
प्रक्रिया start से लेकर gameplay action तक क्रम से जाएं। server बंद है तो फोन की graphics settings नहीं बदलें। केवल एक menu के permission में समस्या है तो पूरी network setup बदलना असंबंधित failures बना सकता है।
एक स्पष्ट असफल प्रयास का समय console से मिलाएं। जरूरत हो तो दूसरा compatible client या अलग network तुलना के लिए लें। passwords, keys और पूरी panel access साझा न करें। versions, error का चरण और काम करने वाला अंतिम परीक्षण diagnosis को दिशा देते हैं।
सुधार के बाद उसी मूल scenario को दोहराएं। यदि साधारण Bedrock खिलाड़ी का menu विफल था तो उसके account और उसी menu से जांच जरूरी है। केवल administrator का Java प्रवेश सफल होना मूल समस्या ठीक होने का प्रमाण नहीं होगा।
server lag और उपकरण का FPS अलग समझें
फोन पर कम frames, network delay और server के slow ticks अलग समस्याएं हैं। पहले पूछें कि सभी खिलाड़ियों को एक समय परेशानी होती है, किसी एक क्षेत्र में होती है या सिर्फ एक उपकरण पर होती है। इस तुलना से सही दिशा मिलती है।
सभी को mobs और actions देर से दिखते हों तो server load, नए chunks, entities और बड़े mechanisms जांचें। केवल एक फोन की image धीमी हो तो graphics, तापमान और client render distance देखें। server में अधिक RAM हर local rendering सीमा नहीं ठीक करेगी।
बड़ी simulation distance और कई खिलाड़ियों की साथ में खोज world work बढ़ाती है। एक setting बदलें और समान गतिविधि दोहराएं। समय, क्षेत्र और active players लिखें। इस तरह तुलना वास्तविक होगी, बजाय हर map के लिए एक fixed capacity वादा करने के।
मुफ्त process sleep में हो तो सामान्य ticks नहीं चलते। बैठक से पहले start की योजना बनाएं। continuous simulation चाहिए तो उस जरूरत के अनुसार वर्तमान plan conditions देखें। केवल saved address होने से फार्म हमेशा सक्रिय रहेंगे, ऐसा न मानें।
update से पहले recovery तैयार करें
server, Geyser, Floodgate और add-ons की versions लिखें। update से पहले consistent world copy और आवश्यक configuration बचाएं। copy को बदलती installation से बाहर रखें। महत्वपूर्ण प्रोजेक्ट में अलग नियंत्रित स्थापना में restore करके वास्तविक readiness जांचें।
समूह को client version और maintenance समय बताएं। compatible components update करें और console startup देखें। फिर वास्तविक फोन तथा दूसरे महत्वपूर्ण उपकरणों से ordinary login, permissions, inventory और जरूरी menus जांचें। नया block save करके निकलें और वापस आने पर उसे देखें।
rollback चाहिए तो previous compatible software, settings और update से पहले का world साथ बहाल करें। नए release से लिखे world को पुराने program में खोलने की support बिना जांचे न मानें। केवल executable बदलना मूल state वापस नहीं लाता और recovery कठिन कर सकता है।
अंत में दूसरे network का मित्र प्रवेश जांचे। Edition, version, host, port और meeting से पहले start का तरीका साझा note में सुधारें। मुख्य उपकरणों के सफल परीक्षण रखें। इससे अगली update पर समूह के पास जुड़ने का दोहराने योग्य तरीका और समस्या सुधारने की स्पष्ट शुरुआत रहती है।