Minecraft ops.json-ის მაგალითი: whitelist, ban-ები და usercache

Minecraft-ის სერვერი თავის ხალხს სერვერის root-ში ხუთ JSON ფაილში ინახავს: ops.json (ოპერატორები და მათი დონე), whitelist.json (ვის შეუძლია შესვლა), banned-players.json და banned-ips.json (ვის არ შეუძლია) და usercache.json (სახელებიდან UUID-ებზე გადამყვანი ცხრილი). ყოველი ჩანაწერი UUID-ითაა იდენტიფიცირებული და არა სახელით. სერვერი ფაილებს გაშვებისას მეხსიერებაში კითხულობს და მთელ სიას დისკზე თავიდან წერს, როცა რომელიმე ბრძანება მას ცვლის. ამიტომ ხელით შესწორებული ფაილი, რომელიც სერვერის მუშაობისას შეცვალე, ჩუმად უბრუნდება წინა მდგომარეობას. უსაფრთხო წესი მოკლეა: სერვერის მუშაობისას გამოიყენე /op, /whitelist და /ban, ფაილები კი მხოლოდ გაჩერებულ სერვერზე შეასწორე.

მუშა ops.json ასე გამოიყურება:

[  {    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",    "name": "Notch",    "level": 4,    "bypassesPlayerLimit": true  },  {    "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6",    "name": "jeb_",    "level": 2,    "bypassesPlayerLimit": false  }]

ამ პოსტის დანარჩენ ნაწილში თითოეულ ფაილს ველების მიხედვით განვიხილავთ: რას წერენ ბრძანებები, რისი გაკეთება შეუძლია ხელით რედაქტირებას და რას ვერ აკეთებენ ბრძანებები, როგორ ამტვრევს offline mode ერთბაშად ყველა ამ სიას და, რადგან ეს ძიება ხშირად აქ მოდის, რას ნიშნავს level-type-ის მნიშვნელობები server.properties-ში. პოლიტიკის მხარე - ვინ უნდა იყოს საერთოდ ოპერატორი და როგორ ააგო რანგები LuckPerms-ით - აღწერილია პოსტში Minecraft whitelist და უფლებები; ეს პოსტი თავად ფაილებზეა.

ხუთი ფაილი ერთი შეხედვით#

ხუთივე ობიექტების JSON მასივია. ხუთივე server.properties-ის გვერდითაა და არა სამყაროს საქაღალდეში, ამიტომ ისინი ყველა განზომილებისთვის საერთოა და level-name-ის შეცვლას გადაურჩება. ახალი სეზონისთვის ახალი სამყარო დაიწყე და ოპერატორები, whitelist და ban-ები ხელუხლებელი დარჩება. სამყაროს საქაღალდეს თუ წაშლი, ისინი მაინც იქ იქნება; სერვერის root-ს თუ წაშლი, დაიკარგება, რაც გასახსენებელია, როცა წყვეტ, რას მოიცავს შენი backup-ები.

ისინი 1.7.6-ში ჩაანაცვლა ტექსტურმა ფაილებმა, როცა Minecraft სახელებიდან UUID-ებზე გადავიდა. თუ ძველ სერვერზე ops.txt, white-list.txt, banned-players.txt ან banned-ips.txt ნახე, ისინი ნარჩენებია. თანამედროვე სერვერი მათ ერთხელ გადაიყვანს და მერე აღარ აქცევს ყურადღებას, ამიტომ მათი რედაქტირება არაფერს ცვლის.

იგივე ფაილები არსებობს vanilla, Paper, Spigot, Purpur, Fabric და NeoForge სერვერებზე, რადგან ისინი vanilla სერვერის კოდს ეკუთვნის, რომელზეც ყველა ესენია აგებული. plugin-ებს შეუძლიათ თავიანთი სიები დაამატონ - EssentialsX მოთამაშეების მონაცემებს ინახავს, LuckPerms-ს საკუთარი საცავი აქვს - მაგრამ აქ აღწერილი ხუთი ფაილი ყველა მათგანზე ერთნაირად იქცევა.

ops.json, ველი ველით#

თითოეული ოპერატორი ერთი ობიექტია ოთხი ველით.

uuid ერთადერთი ველია, რომლითაც სერვერი მოთამაშეს ცნობს. name შენთვისაა ჩაწერილი და განახლდება, როცა მოთამაშე ახალი სახელით შედის; ძველი სახელი არაფერს აფუჭებს. პირიქით კი არ მუშაობს: ჩანაწერი, რომელსაც uuid აკლია ან არასწორია, ფაილის ჩატვირთვისას გამოტოვდება და შეცდომას, რომელსაც შეამჩნევ, ვერ ნახავ, ამიტომ ხელით დაწერილი ჩანაწერი მხოლოდ სახელით სერვერისთვის უბრალოდ არ არსებობს.

level ის ადგილია, სადაც ხელით რედაქტირება გამართლებულია. /op <player> ყოველთვის წერს op-permission-level-ის მნიშვნელობას server.properties-იდან, რომელიც ნაგულისხმევად 4-ია. /op-ს არ აქვს არგუმენტი, რომელიც დონეს დააყენებს, ამიტომ თუ ერთი მოთამაშე 4-ზე გინდა და მეორე 2-ზე, ან op-permission-level უნდა შეცვალო ყოველი /op-ის წინ და შუაში restart გააკეთო, ან რიცხვი ფაილში ჩაწერო. ოთხი დონე მოკლედ:

• 1 - უვლის spawn-ის დაცვას და სხვა არაფერს.
• 2 - ჩითის ტიპის ბრძანებები, როგორიცაა /gamemode, /give, /tp და command block-ები.
• 3 - მოთამაშეების მართვა: /kick, /ban, /op, /whitelist.
• 4 - ყველაფერი, /stop-ის ჩათვლით.

სრული ცხრილი და მიზეზი, რის გამოც დონეები plugin-ებიან სერვერზე ბევრად ნაკლებს ნიშნავს, ვიდრე ჩანს - plugin-ები თავიანთ უფლებებს, როგორც წესი, ყველა ოპერატორს აძლევენ დონის მიუხედავად - აღწერილია უფლებების პოსტში. Paper-ზე level მხოლოდ vanilla ბრძანებებს აკონტროლებს.

bypassesPlayerLimit ამ მოთამაშეს საშუალებას აძლევს შევიდეს, როცა სერვერზე უკვე max-players ადამიანია. /op ახალი ოპერატორისთვის false-ს წერს და უკვე არსებულ მნიშვნელობას ინარჩუნებს, როცა ვინმეს თავიდან op-ს აძლევ, ხოლო არცერთი ბრძანება მას true-ზე არ ცვლის, ამიტომ ჩასართავად ერთადერთი ადგილი თავად ფაილია. სწორედ ეს პარამეტრი აძლევს ადმინს შევსებულ სერვერში შესვლის საშუალებას, რომ გაარკვიოს, რამ შეავსო.

კიდევ ორი ურთიერთქმედება, რომელიც უნდა იცოდე. ოპერატორები whitelist-ს მთლიანად უვლიან გვერდს, ამიტომ ოპერატორის ძველი ჩანაწერი შესასვლელია, რომელსაც whitelist remove ვერ დახურავს. და /deop ჩანაწერს მთლიანად შლის და არა დონეს ამცირებს - არ არსებობს 0 დონე, რომელზეც ვინმეს ჩამოქვეითებ.

whitelist.json#

[  { "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5", "name": "Notch" },  { "uuid": "853c80ef-3c37-49fd-aa49-938b674adae6", "name": "jeb_" }]

ორი ველი, იგივე წესები: uuid ემთხვევა, name დეკორაციაა. ფაილს სერვერი მხოლოდ მაშინ ეკითხება, როცა server.properties-ში white-list=true-ა, და whitelist-ის გამორთვისას ფაილი რჩება, ამიტომ მოგვიანებით ჩართვისას ზუსტად იგივე ადამიანები აღდგება.

Whitelist ერთადერთი სიაა, რომელსაც reload ბრძანება აქვს. /whitelist reload whitelist.json-ს დისკიდან თავიდან კითხულობს, რის გამოც ხუთიდან ის ერთადერთია, რომელიც სერვერის მუშაობისას უსაფრთხოდ შეგიძლია ხელით შეასწორო - იმ პირობით, რომ reload გაუშვებ მანამ, სანამ ფაილს სხვა რამ დაწერს. enforce-whitelist=true-ს შემთხვევაში reload ონლაინ მყოფსაც გათიშავს, ვინც სიაში აღარ არის.

როცა /whitelist add <name>-ს უშვებ, სერვერს ამ სახელის UUID სჭირდება. ჯერ usercache.json-ს ამოწმებს და თუ სახელი იქ არაა, Mojang-ის პროფილების სერვისს ეკითხება. ამიტომ მუშაობს ბრძანება მოთამაშეზე, რომელიც არასდროს შესულა, და ამიტომ ვარდება შეტყობინებით "That player does not exist", როცა სახელი არასწორადაა დაწერილი, შეცვლილია ან Java ანგარიშის კი არა, Bedrock gamertag-ს ეკუთვნის.

banned-players.json და banned-ips.json#

ban-ის სიებს მეტი ველი აქვს, რადგან ban-ი იმახსოვრებს, ვინ გააკეთა, როდის და რატომ.

[  {    "uuid": "36532b5e-c442-3dbb-a24c-c7e55d0f979a",    "name": "Griefer123",    "created": "2026-10-15 14:03:22 +0000",    "source": "Server",    "expires": "forever",    "reason": "Lava-cast over the spawn town"  }]

[  {    "ip": "203.0.113.45",    "created": "2026-10-15 14:05:10 +0000",    "source": "Server",    "expires": "forever",    "reason": "Ban evasion"  }]

source იმის სახელია, რამაც ბრძანება გაუშვა: Server კონსოლისთვის, Rcon დისტანციური კონსოლისთვის ან ოპერატორის სახელი. მიზეზის გარეშე vanilla წერს Banned by an operator.

expires ყველაზე საინტერესოა. vanilla-ის /ban-ს ხანგრძლივობის არგუმენტი არ აქვს და ყოველთვის forever-ს წერს, მაგრამ სერვერი ამ ველში თარიღს მაინც პატივს სცემს. ჩაწერე დროის ანაბეჭდი იმავე ფორმატში, რაც created-ს აქვს - "2026-10-22 14:00:00 +0000" - და ban-ი ამ მომენტის შემდეგ აღარ მოქმედებს. სწორედ ასე ინახება დროებითი ban-ები plugin-ებიდან, როგორიცაა EssentialsX: ამავე ფაილში, რეალური ვადის თარიღით. ფორმატი თუ არასწორია, თარიღი შეიძლება ვერ დაპარსდეს, ამიტომ created-ის ფორმა ზუსტად გადმოიღე, დროის სარტყლის წანაცვლებამდე არსებული გამოტოვების ჩათვლით.

ბრძანებები, ყველა ოპერატორის მე-3 დონეზე:

ban-ip, როცა მოთამაშის სახელი მიეცემა, ბანავს ამ მოთამაშის მიმდინარე მისამართს, რაც მოსახერხებელი ფორმაა, როცა ის ონლაინაა. მისამართით ban-ი უხეში ინსტრუმენტია. ბევრი სახლის კავშირი ხელახლა დაკავშირებისას მისამართს იცვლის, მობილურ ქსელებში ათასობით ადამიანი ერთ მისამართს უკან დგას და VPN მას წამებში ამარცხებს. ჯერ ანგარიშის ban გამოიყენე, მისამართისა კი დამატებად, როცა ჯიუტი alt-ანგარიშების პრობლემა გაქვს, და გაითვალისწინე, რომ დროდადრო უდანაშაულო მოთამაშეს გაამართლებ.

არც ერთ ban-ის სიას vanilla-ში reload ბრძანება არ აქვს, ამიტომ მათ ხელით რედაქტირებას გაჩერებული სერვერი სჭირდება.

usercache.json#

[  {    "name": "Notch",    "uuid": "069a79f4-44e9-4726-a5be-fca90e38aaf5",    "expiresOn": "2026-11-15 14:03:22 +0000"  }]

ეს უფლებების ფაილი არაა. ეს სახელებისა და UUID-ების cache-ია, რომლებიც სერვერმა გადაწყვიტა და რომელიც მოთამაშის ყოველ შესვლაზე ახლდება. ბრძანებები მას იყენებენ, რომ სახელი UUID-ად აქციონ Mojang-ისთვის კითხვის გარეშე, და ასევე იყენებენ მოთამაშის თავები, /whitelist add და ban-ის ბრძანებები ოფლაინ მოთამაშეებისთვის. expiresOn დაახლოებით ერთი თვით წინაა დაყენებული; ვადაგასული ჩანაწერი თავიდან მოიძებნება, როცა შემდეგ ჯერზე დასჭირდება. ფაილი ბოლოს გამოყენებული დაახლოებით ათასი ჩანაწერით შემოიფარგლება, ამიტომ დატვირთულ სერვერზეც პატარა რჩება.

რადგან ის მხოლოდ cache-ია, usercache.json-ის წაშლა გაჩერებულ სერვერზე უსაფრთხოა - მოთამაშეების შესვლისას თავიდან აშენდება. ეს ზოგჯერ სწორედ ის გამოსავალია, როცა გადარქმეული მოთამაშის ძველი სახელი ისევ არასწორ ანგარიშზე წყდება ან როცა online და offline რეჟიმებს შორის გადართვამ ის UUID-ებით აავსო, რომლებიც აღარაფერს ემთხვევა. მოთამაშის იდენტობის "გასასწორებლად" ხელით ნუ შეასწორებ; სერვერი შენს ცვლილებას მომდევნო შესვლაზე მაინც გადაწერს, ხოლო მნიშვნელოვანი იდენტობა სხვა ოთხ ფაილშია.

რატომ იშლება ხელით შესწორება სერვერის მუშაობისას#

ქცევას, რომელიც ყველას ებმება, მარტივი მიზეზი აქვს. გაშვებისას სერვერი ყველა სიას მეხსიერებაში კითხულობს. მას შემდეგ ნამდვილი მეხსიერებაში არსებული ასლია. როცა რომელიმე ბრძანება სიას ცვლის - /op, /deop, /whitelist add, /ban, /pardon ან plugin, რომელიც იმავე კოდს იძახებს - სერვერი მეხსიერებაში არსებულ სიას სერიალიზებს და მთელ ფაილს თავიდან წერს. რაც მას ჩატვირთული არ ჰქონია, ამ ჩაწერას ვერ გადაურჩება.

ამიტომ ops.json-ის რედაქტირება ფაილების მენეჯერში სერვერის მუშაობისას თითქოს მუშაობს - დისკზე ფაილი შენს ცვლილებას აჩვენებს - და მერე ქრება, როგორც კი ვინმეს op-ს მისცემენ, დაბანავენ ან whitelist-ში ჩაამატებენ. შენი ცვლილება მეხსიერებაში არასდროს ყოფილა და მომდევნო ჩაწერა ფაილს იმით ანაცვლებს, რაც იქ იყო. იგივე პირიქითაც მოქმედებს: სერვერის მუშაობისას გაკეთებული შესწორება არ მოქმედებს, სანამ არ ჩაიტვირთება, რაც op-ებისა და ban-ებისთვის restart-ს ნიშნავს.

არსებობს უფრო უსიამოვნო ვარიანტიც. თუ ამ ფაილებიდან ერთ-ერთს JSON-ის სინტაქსის შეცდომით შეინახავ - ყველაზე ხშირია მძიმე ბოლო ჩანაწერის შემდეგ, მეორე - ამოვარდნილი ბრჭყალი - სერვერი სიის ჩატვირთვის უშედეგობისას გაფრთხილებას დაწერს და მეხსიერებაში ცარიელი სიით განაგრძობს. შენი ოპერატორები აღარ არიან ოპერატორები, whitelist არავის უშვებს ops-ის გარდა და ban-ები მოხსნილია. შემდეგი ბრძანება, რომელიც ამ სიას შეეხება, ცარიელ სიას დისკზე უკან ჩაწერს და შენს გატეხილ ფაილსა და მის ყველა ჩანაწერს ჩაანაცვლებს.

პროცედურა, რომელიც ყოველთვის მუშაობს:

1. გააჩერე სერვერი და დაელოდე, სანამ სრულად გაითიშება.
2. გააკეთე იმ ფაილის ასლი, რომლის შესწორებასაც აპირებ, ან სერვერის backup.
3. შეასრულე შესწორება. JSON მასივი ვალიდური დატოვე: მძიმეები ობიექტებს შორის, ბოლოს არცერთი, ყველა გასაღები და string ორმაგ ბრჭყალებში.
4. თუ დარწმუნებული არ ხარ, ფაილი ჩასვი ნებისმიერ JSON ვალიდატორში.
5. გაუშვი სერვერი და ლოგის დასაწყისი წაიკითხე ჩატვირთვის გაფრთხილებებისთვის.
6. კონსოლიდან გაუშვი /op ან /whitelist list ან /banlist, რომ დარწმუნდე, სია იმას შეიცავს, რასაც ელოდები.

მხოლოდ whitelist-ისთვის მოკლე გზაა: შეასწორე, შეინახე და მაშინვე /whitelist reload.

RE:NODE-ზე ფაილების მენეჯერი ამ ფაილებს ბრაუზერში ასწორებს სინტაქსის გამოკვეთით, რის გამოც ზედმეტი მძიმე შენახვამდე ჩანს, ხოლო SFTP ყოველი სერვერისთვის გენერირებული მონაცემებით მუშაობს, თუ საკუთარ რედაქტორს გირჩევნია - დეტალები SFTP და ფაილების მენეჯერი პოსტშია. კონსოლი ბრძანებების ისტორიას ინახავს, ამიტომ შემოწმების ნაბიჯი რამდენიმე ღილაკზე დაჭერაა. ხოლო backup-ის სლოტი არსებობს, რომ რედაქტირებამდე snapshot გადაიღო; აღდგენა ერთი ღილაკია და აღწერილია პოსტში Minecraft-ის სამყაროს backup და აღდგენა.

Offline mode და UUID-ის ხაფანგი#

აქ ყველა სია UUID-ითაა იდენტიფიცირებული და online-mode წყვეტს, საიდან მოდის UUID-ები. ამიტომ ის პარამეტრია, რომელიც ყველაზე ხშირად ამტვრევს ხუთივე ფაილს ერთდროულად.

online-mode=true-ს დროს მოთამაშის UUID-ს Mojang გასცემს. ის ანგარიშს ეკუთვნის, სახელის შეცვლას გადაურჩება და სწორედ ის იწერება ყველა ბრძანებით. ესენი მე-4 ვერსიის UUID-ებია: სიმბოლოების მესამე ჯგუფი 4-ით იწყება, როგორც 069a79f4-44e9-4726-...-ში.

online-mode=false-ს დროს სერვერი Mojang-ს არაფერს ეკითხება. ის UUID-ს თავად სახელიდან გამოითვლის: ტექსტ OfflinePlayer:-ს ზუსტ მომხმარებლის სახელთან ერთად ჰეშავს. ესენი მე-3 ვერსიის UUID-ებია და მესამე ჯგუფი 3-ით იწყება. ერთი და იგივე ანგარიში ორ სრულიად განსხვავებულ იდენტობას იძლევა:

შედეგები პირდაპირ გამომდინარეობს:

• რეჟიმის გადართვა ყველა ჩანაწერს ობლად ტოვებს. ოპერატორი, რომელსაც online რეჟიმში მიეცა op, offline რეჟიმზე გადართვის შემდეგ ოპერატორი აღარაა და whitelist თავის წევრებიდან არავის უშვებს. მათი ინვენტარი, მიღწევები და plugin-ების მონაცემებიც UUID-ითაა იდენტიფიცირებული, ამიტომ ისინიც თითქოს ქრება - ძველი მოთამაშის ფაილები სამყაროს საქაღალდეში ძველი UUID-ებით ისევ არის.
• offline-ზე სახელის რეგისტრს მნიშვნელობა აქვს. ჰეში ზუსტი სტრიქონისაა, ამიტომ Notch და notch ორი სხვადასხვა offline მოთამაშეა.
• offline-ზე გადარქმევა ახალი მოთამაშეა. სახელის უკან ანგარიში არ დგას, ამიტომ ახალი სახელი ახალ UUID-სა და ცარიელ ინვენტარს ნიშნავს.
• offline whitelist-მა შეიძლება არასწორი UUID ჩაწეროს. ბევრ ვერსიაზე /whitelist add და /op ჯერ მაინც Mojang-ის მოძიებას ცდილობენ, როცა სახელი ნამდვილ Java ანგარიშს ეკუთვნის, და offline UUID-ზე მხოლოდ მაშინ გადადიან, თუ ეს ვერ მოხერხდა. ჩანაწერში online UUID რჩება და offline მოთამაშეს, რომელიც უერთდება, არასდროს ემთხვევა. საიმედო გამოსავალია, მოთამაშე ერთხელ შედიოდეს გამორთული whitelist-ით, რომ cache-ში მისი offline UUID მოხვდეს, ან offline UUID ფაილში თავად ჩაწერო.

offline UUID-ის გამოთვლა Python-ის რამდენიმე ხაზით შეგიძლია. Java მას UUID.nameUUIDFromBytes-ით აგებს და ეს კოდი ზუსტად იმავეს იძლევა:

import hashlib, uuid, sysname = sys.argv[1]h = bytearray(hashlib.md5(("OfflinePlayer:" + name).encode("utf-8")).digest())h[6] = (h[6] & 0x0F) | 0x30  # version 3h[8] = (h[8] & 0x3F) | 0x80  # IETF variantprint(uuid.UUID(bytes=bytes(h)))

$ python3 offline_uuid.py Notchb50ad385-829d-3141-a216-7e7d7539ba7f

online-mode=false-ის ერთადერთი კანონიერი ადგილი Velocity-ის ან BungeeCord-ის proxy-ს უკან მდგომი backend სერვერია. proxy Mojang-თან ავტორიზდება და, forwarding-ის გამართვისას, backend-ს ნამდვილ online UUID-ს გადასცემს - ამიტომ backend-ის სიებში მე-4 ვერსიის UUID-ებია, თუმცა მისი საკუთარი online-mode გამორთულია. თუ proxy-ს უკან მდგომი backend-ის usercache.json-ში მე-3 ვერსიის UUID-ები ჩნდება, forwarding არ მუშაობს და ყველა მოთამაშე სახელიდან წარმოებული იდენტობით მოდის. forwarding გაასწორე, სანამ სხვა რამეს გააკეთებ; ამას Velocity-ის ქსელის გზამკვლევი განიხილავს. Bedrock მოთამაშეები Geyser-ისა და Floodgate-ის გავლით მესამე შემთხვევაა, საკუთარი გენერირებული UUID-ებით - იხილე Geyser და Bedrock crossplay.

სერვერის offline რეჟიმიდან online რეჟიმზე სწორად გადატანა ნიშნავს ყოველი სიის ახალი UUID-ებით გადაწერას და თითოეული მოთამაშის მონაცემთა ფაილების გადარქმევას world/playerdata/-ში, ასევე ყველაფრის, რასაც plugin-ები UUID-ზე ინახავენ. ეს მიგრაციაა და არა პარამეტრის შეცვლა და მანამდე backup უნდა გააკეთო.

level-type server.properties-ში#

კითხვის მეორე ნახევარი, რომელიც ხალხს აქ მოჰყავს, არის ხაზი level-type=minecraft\:normal. ის ირჩევს სამყაროს პრესეტს, რომელიც სამყაროს გენერაციისას გამოიყენება. 1.19-ში და მის შემდეგ მნიშვნელობებს namespace აქვთ:

ორწერტილამდე უკანა ხაზი Java properties ფაილის ფორმატია: სერვერის საკუთარი ჩამწერი ყველა ორწერტილს ეკრანირებს, ამიტომ მის მიერ გენერირებულ ფაილში წერია minecraft\:normal. როცა სერვერი ფაილს უკან კითხულობს, მნიშვნელობაში minecraft\:normal და minecraft:normal ზუსტად ერთსა და იმავეს ნიშნავს, ამიტომ ორივე ფორმა შეგიძლია დაწერო. რაც არ გამოდგება, არის ამოუცნობი მნიშვნელობა - მაგალითად, შეცდომა minecraft:largebiomes - რომელიც მიმდინარე ვერსიებზე ნათელი შეცდომის ნაცვლად ჩვეულებრივ სამყაროს გაძლევს და ამას მხოლოდ მაშინ ამჩნევ, როცა მოთამაშეები უკვე დადიან.

ძველი ვერსიები შიშველ სიტყვებს იყენებდნენ: default, flat, largeBiomes, amplified და ზოგ ვერსიაში buffet ან customized. თანამედროვე სერვერები გავრცელებულ ძველ სახელებს namespace-იან სახელებად თარგმნიან, ამიტომ ძველი ფაილი მაინც მუშაობს, მაგრამ ახალ ფაილში namespace-იანი ფორმა დაწერე.

სამი პრაქტიკული მომენტი:

• ის მხოლოდ სამყაროს შექმნისას მოქმედებს. როცა level.dat არსებობს, გენერატორი სამყაროშია შენახული და level-type-ის შეცვლა არაფერს ცვლის. სხვა პრესეტის საცდელად level-name ახალ საქაღალდეზე შეცვალე, რომ სერვერმა ძველის გვერდით ახალი სამყარო შექმნას.
• `amplified` რეალურ CPU-ს ხარჯავს. amplified chunk-ების გენერაცია შესამჩნევად უფრო ნელია, ვიდრე ჩვეულებრივის, და გაზიარებულ core-ზე ეს ლაგის ნახტომებად ჩანს, სანამ მოთამაშეები იკვლევენ. სანამ სერვერს გახსნი, სათამაშო ტერიტორია წინასწარ დააგენერირე - როგორ, ამას სამყაროს საზღვარი და წინასწარი გენერაცია განმარტავს.
• `large_biomes` დიდი მოთამაშეთა რაოდენობისთვისაა. ბიომების გადაშლა ყველას ადგილს უტოვებს, ოღონდ კონკრეტული ბიომის საპოვნელად გრძელი სიარულის ფასად.

Seed-ები, ბრტყელი სამყაროების generator-settings JSON და worldgen datapack-ები, როგორიცაა Terralith, განხილულია სამყაროს საკუთარი გენერაციის პოსტში, ფაილის დანარჩენი ნაწილი კი - server.properties-ის ყველა გასაღების პოსტში.

სიების პრობლემების გადაჭრა#

`ops.json` შევასწორე და არავინ არის ოპერატორი. ან სერვერი მუშაობდა და შენი ცვლილება გადაწერა, ან JSON არ დაიპარსა და სერვერმა ცარიელი სია ჩატვირთა. გააჩერე სერვერი, გახსენი ფაილი და შეამოწმე.

მოთამაშე `whitelist.json`-შია, მაგრამ ვერ შედის. შეადარე ფაილში არსებული UUID usercache.json-ში არსებულს მას შემდეგ, რაც ის დაკავშირებას ცდის. ერთ მხარეს მე-3 და მეორეზე მე-4 ვერსიის UUID online/offline შეუსაბამობას ნიშნავს. ასევე შეამოწმე, რომ white-list ის არის, რასაც ფიქრობ: /whitelist on პარამეტრს დისკზე წერს, ამიტომ ძველმა ხელით შესწორებულმა server.properties-მა შეიძლება იმას არ დაემთხვეს, რასაც სერვერი აკეთებს.

`/whitelist add` ამბობს, რომ მოთამაშე არ არსებობს. მართლწერა, ახლახანს გადარქმევა, Bedrock gamertag, ან სერვერს Mojang-ის პროფილების სერვისთან წვდომა არ აქვს. მოთამაშე ერთხელ შედიოდეს გამორთული whitelist-ით, ან UUID ხელით დაამატე გაჩერებულ სერვერზე.

შეწყალებული მოთამაშე ისევ დაბანილია. შეამოწმე banned-ips.json. მოთამაშე, რომელიც ban-ip-ით დაიბანა, pardon-ის შემდეგაც გარეთ რჩება, რადგან მისამართის ban-ი ცალკე სიაა და pardon-ip სჭირდება.

ban-ები restart-ის შემდეგ დაბრუნდა. ვიღაცამ ფაილში შეიწყალა, სანამ სერვერი მუშაობდა. მეხსიერებაში არსებულ სიას ban ისევ ჰქონდა და უკან ჩაწერა. გამოიყენე /pardon.

სერვერი სავსეა და ადმინი ვერ შედის. გაჩერებულ სერვერზე ადმინის ჩანაწერში დააყენე "bypassesPlayerLimit": true ან გაზარდე max-players - მნიშვნელობა, რომელიც მხოლოდ ადგილებს ზღუდავს და არა თავისთავად წარმადობას.

FAQ#

შემიძლია ოპერატორის დამატება სერვერის გაშვების გარეშე?

დიახ. ჩაწერე ჩანაწერი ops.json-ში მოთამაშის UUID-ით, 1-დან 4-მდე დონით და bypassesPlayerLimit-ით, ფაილი ვალიდურ JSON-ად შეინარჩუნე და გაუშვი სერვერი. UUID სწორი უნდა იყოს; მოძებნე ის წინა შესვლიდან usercache.json-ში ან online-mode სერვერებისთვის Mojang-ის ნებისმიერი UUID-ის საძიებლით.

გამოიყენება ამ ფაილებში name ველი რამისთვის?

თითქმის არა. შედარება UUID-ით ხდება და სერვერი სახელს განაახლებს, როცა მოთამაშე შემდეგ ჯერზე შევა. ჩანაწერში არასწორი ან მოძველებული სახელი პრობლემას არ ქმნის, სანამ UUID სწორია; სწორი სახელი არასწორი UUID-ით კი საერთოდ არაფერს აკეთებს.

როგორ გავაკეთო დროებითი ban plugin-ის გარეშე?

ჩვეულებრივ დაბანე მოთამაშე, გააჩერე სერვერი, ამ ჩანაწერის expires forever-დან შეცვალე დროის ანაბეჭდზე created-ის ფორმატში და ისევ გაუშვი სერვერი. ban-ი ამ დროის შემდეგ აღარ მოქმედებს.

უსაფრთხოა usercache.json-ის წაშლა?

გაჩერებულ სერვერზე - დიახ. ის მხოლოდ cache-ია და მოთამაშეების შესვლისას თავიდან აშენდება. წაშლა ნიშნავს, რომ პირველ ბრძანებას, რომელიც ოფლაინ მოთამაშეს ასახელებს, Mojang-ისთვის ხელახლა მოუწევს კითხვა.

რატომ არ იძლევა /op იმ დონეს, რომელიც ops.json-ში დავაყენე?

ის ყოველ ჯერზე წერს op-permission-level-ს server.properties-იდან და ამ მოთამაშის წინა დონეს გადააწერს. დონეები ფაილში გაჩერებულ სერვერზე დააყენე და ამ მოთამაშეს მერე თავიდან op-ს ნუ მისცემ.

ცვლის თუ არა level-type არსებულ სამყაროს?

არა. გენერატორი სამყაროს შექმნისას ფიქსირდება და level.dat-ში ინახება. ხაზის შეცვლა მხოლოდ ცვლილების შემდეგ დაგენერირებულ სამყაროს ეხება, ჩვეულებრივ იმიტომ, რომ level-name ახალ საქაღალდეზე მიუთითებს.