BungeeCord თუ Velocity: Minecraft proxy

ახალი Minecraft ქსელისთვის Velocity აირჩიე. მას PaperMC ავითარებს და გირჩევს, მისი modern forwarding რეჟიმი backend-ებს დამატებითი plugin-ების გარეშე იცავს და ერთ ბირთვზე BungeeCord-ზე მეტ მოთამაშეს უმკლავდება. BungeeCord-ს ჯერ კიდევ ავითარებენ და მსოფლიოს ქსელების დიდი ნაწილი ისევ მასზე მუშაობს, მასზე დარჩენის კი ზუსტად ერთი კარგი მიზეზი არსებობს: plugin, რომელზეც დამოკიდებული ხარ და Velocity-ის ვერსია არ აქვს. თუ ეს შენ არ გეხება, გადასვლა ერთი შუადღის საქმეა - ახალი კონფიგურაციის ფაილი, ერთი პარამეტრი თითო backend-ზე და plugin-ების აუდიტი - და ეს პოსტი მას ნაბიჯ-ნაბიჯ გადის, ორ proxy-ს შორის რეალურ განსხვავებებთან ერთად.

Velocity-ის სრული მოწყობა - velocity.toml-ის ყოველი ხაზი, საერთო უფლებები, forced hosts - აღწერილია Velocity ქსელის გზამკვლევში. ეს პოსტი შედარებასა და გადასვლას ეძღვნება.

რას აკეთებს ორივე proxy და სად განსხვავდებიან#

ორივე ერთი და იმავე ტიპის პროგრამაა. მოთამაშე proxy-ს უერთდება, proxy მას Mojang-თან ერთხელ ავთენტიფიცირებს, შემდეგ backend სერვერთან საკუთარ კავშირს ხსნის და პაკეტებს ორივე მიმართულებით გადასცემს. სერვერებს შორის გადასვლა ნიშნავს, რომ proxy ერთ backend კავშირს ხურავს და მეორეს ხსნის, მოთამაშის კავშირი კი ამ დროს ღია რჩება. არც ერთი proxy არაფერს ასიმულირებს: proxy-ზე არ არის სამყაროები, ბლოკები ან entity-ები, რის გამოც მას ძალიან ცოტა მეხსიერება სჭირდება.

განსხვავებები ოთხ ადგილასაა:

Forwarding ყველაზე მნიშვნელოვანი განსხვავებაა და ის, რაც ხალხს ყველაზე ნაკლებად ესმის. მას ქვემოთ ცალკე სექცია ეთმობა, რადგან სწორედ ის წყვეტს, შეუძლია თუ არა ნებისმიერს, ვინც backend-ის პორტს იპოვის, მასზე პირდაპირ შესვლა.

Plugin API-ები თავსებადი არ არის. BungeeCord plugin Velocity-ზე არ ჩაიტვირთება, Velocity plugin BungeeCord-ზე არ ჩაიტვირთება, ხოლო Paper plugin-ები არც ერთზე. დიდი ქსელური plugin-ების უმეტესობა - LuckPerms, Geyser და Floodgate, ViaVersion, ძირითადი ჩატისა და ban-ის plugin-ები - ორივესთვის გამოდის. პატარა ან მიტოვებული plugin-ები ხშირად მხოლოდ BungeeCord-ისთვის არსებობს, რომელიც 2013 წლიდან არსებობს.

წარმადობაში Velocity იგებს. ის ნულიდან დაიწერა Netty-ზე, Linux-ზე შეკუმშვისა და დაშიფვრის ნატიური ბიბლიოთეკებით, და თითო პაკეტზე ნაკლებ სამუშაოს აკეთებს. პრაქტიკაში ამას იშვიათად აქვს მნიშვნელობა რამდენიმე ასეულ ერთდროულ მოთამაშემდე, სადაც ორივე proxy ბირთვის მცირე ნაწილზე უქმად დგას. მნიშვნელობას დიდ ქსელებზე იძენს და ჰოსტებზე, სადაც თითო პროცესს CPU-ის მკაცრი ლიმიტი აქვს.

კონფიგურაცია ძირითადად თარგმნის სავარჯიშოა. ცნებები - listener-ები, სერვერების სია, try რიგი, forced hosts, შეკუმშვის ზღვარი - ორივეში არსებობს, უბრალოდ სხვადასხვა სახელით.

Waterfall დასრულდა და რას ნიშნავს ეს შენთვის#

Waterfall იყო PaperMC-ის BungeeCord-ის fork, წარმადობის გასწორებებითა და დამატებითი პარამეტრებით. ბევრი ქსელი, რომელიც თავს "BungeeCord-ზე მყოფად" თვლის, სინამდვილეში Waterfall-ზეა. PaperMC-მ Waterfall-ის განვითარება შეწყვიტა და ყველას Velocity-ზე მიუთითებს. ის ჯერ კიდევ მუშაობს, მაგრამ განახლებებს აღარ იღებს, რაც ნიშნავს, რომ Minecraft-ის პროტოკოლის ახალ ვერსიებს და უსაფრთხოების გასწორებებს აღარ მიიღებს.

თუ დღეს Waterfall-ზე ხარ, ორი არჩევანი გაქვს: დაბრუნდე upstream BungeeCord-ზე, რომელიც თითქმის იგივე config.yml-ს კითხულობს და იგივე plugin-ებს უშვებს, ან გადახვიდე Velocity-ზე. BungeeCord-ზე დაბრუნება უფრო პატარა ნაბიჯია; Velocity-ზე გადასვლა ის ნაბიჯია, რომლის გამეორებაც აღარ მოგიწევს. თუ ყველა backend-ს მაინც შეეხები, ერთხელ გააკეთე.

Forwarding: უსაფრთხოების განსხვავება#

როცა მოთამაშე proxy-ს გავლით უერთდება, backend კავშირს proxy-ის მისამართიდან ხედავს და არა მოთამაშისგან. დახმარების გარეშე ყველა მოთამაშე proxy-ის IP-ით და offline-mode UUID-ით მივიდოდა, რაც ამტვრევს ban-ებს, skin-ებს და ყველა plugin-ს, რომელიც მონაცემებს UUID-ით ინახავს. Forwarding არის გზა, რომლითაც proxy backend-ს ეუბნება, ვინ არის მოთამაშე სინამდვილეში.

BungeeCord-ის ip_forward

BungeeCord ამას ასე აკეთებს: მოთამაშის რეალურ მისამართს, UUID-ს და პროფილის თვისებებს handshake-ს ბოლოში ამატებს. ჩართვა ხდება proxy-ის config.yml-ში ip_forward: true-ით და თითოეული backend-ის spigot.yml-ში settings.bungeecord: true-ით.

პრობლემა ისაა, რომ backend-ს არ შეუძლია შეამოწმოს, მონაცემები მართლა შენი proxy-დან მოვიდა თუ არა. ის ენდობა ყველაფერს, რასაც handshake ამბობს. რადგან backend-ები online-mode=false-ით მუშაობს (ავთენტიფიკაცია proxy-მ გააკეთა), ნებისმიერს, ვისაც backend-ის პორტთან პირდაპირ მიწვდომა შეუძლია, შეუძლია გააგზავნოს გაყალბებული handshake, სადაც თავს ნებისმიერ მოთამაშედ, ოპერატორის ჩათვლით, აცხადებს, და backend მას შეუშვებს. ეს თეორიული სისუსტე არ არის; არსებობს საჯარო ინსტრუმენტები, რომლებიც სწორედ ამას აკეთებს, და ღია BungeeCord backend-ებს სკანერები საათებში პოულობენ.

ორი გამოსავალია: firewall, რომელიც backend-ებთან მხოლოდ proxy-ს უშვებს, ან BungeeGuard, plugin-ების წყვილი, რომელიც გადაცემულ მონაცემებს საიდუმლო token-ს უმატებს, რომ backend-ებმა მის გარეშე კავშირები უარყონ. საკუთარ მანქანაზე firewall უფრო ძლიერი ვარიანტია. გაზიარებულ პანელ ჰოსტზე, სადაც ყოველი სერვერი ცალკე container-ია საკუთარი საჯარო პორტით, საკუთარ backend-ებს ინტერნეტისგან firewall-ით ჩვეულებრივ ვერ გამოყოფ, და BungeeGuard არჩევითი არ არის.

Velocity-ის modern forwarding

Velocity-ის modern რეჟიმი იმავე იდენტობის მონაცემებს აგზავნის payload-ში, რომელიც proxy-სა და თითოეულ backend-ს შორის საერთო secret-ით არის ხელმოწერილი. Paper ხელმოწერას ამოწმებს და ყველაფერს, რასაც ვალიდური ხელმოწერა არ აქვს, login-ის დასრულებამდე უარყოფს. მოთამაშე, რომელიც backend-ის მისამართს იპოვის და პირდაპირ დაუკავშირდება, გაგდებული იქნება. არც firewall და არც დამატებითი plugin.

ფასი თავსებადობაა: modern forwarding-ს სჭირდება backend, რომელსაც ის ესმის, ანუ Paper 1.13 ან უფრო ახალი, ან Fabric ან NeoForge backend proxy-თავსებადობის mod-ით. უფრო ძველი backend-ებისთვის Velocity გთავაზობს legacy-ს (BungeeCord-ის სტილი, იმავე სისუსტით) და bungeeguard-ს (legacy პლუს BungeeGuard token).

კონფიგურაციები გვერდიგვერდ#

ტიპური BungeeCord config.yml, შემოკლებული იმ ნაწილებამდე, რომლებიც გადადის:

online_mode: trueip_forward: truenetwork_compression_threshold: 256connection_throttle: 4000player_limit: -1listeners:- host: 0.0.0.0:25565  motd: '&bThe Longhouse Network'  max_players: 200  force_default_server: true  priorities:  - lobby  forced_hosts:    survival.example.com: survival  ping_passthrough: false  query_enabled: falseservers:  lobby:    address: 10.0.0.11:25566    restricted: false    motd: 'Lobby'  survival:    address: 10.0.0.12:25567    restricted: false    motd: 'Survival'

და იგივე ქსელი velocity.toml-ში:

bind = "0.0.0.0:25565"motd = "<aqua>The Longhouse Network"show-max-players = 200online-mode = trueplayer-info-forwarding-mode = "modern"forwarding-secret-file = "forwarding.secret"[servers]lobby = "10.0.0.11:25566"survival = "10.0.0.12:25567"try = ["lobby"][forced-hosts]"survival.example.com" = ["survival"][advanced]compression-threshold = 256login-ratelimit = 3000

როგორ შეესაბამება გასაღებები ერთმანეთს:

ორი ქცევა ისე განსხვავდება, რომ ხალხს აკვირვებს. პირველი: BungeeCord-ზე force_default_server: true ყოველ შესვლაზე ყველა მოთამაშეს პირველ priority სერვერზე აგზავნის; Velocity პირველ შეერთებაზე ყოველთვის try სიას იყენებს და ბოლო სერვერს არ იმახსოვრებს, თუ ამას plugin არ აკეთებს. მეორე: BungeeCord-ს config.yml-ში მარტივი უფლებების სისტემა მოჰყვება (groups და permissions ბლოკები, მაგალითად ადმინად md_5-ით). Velocity-ს ასეთი არ აქვს: უფლებების plugin-ის გარეშე ადმინის ბრძანებებზე წვდომა მხოლოდ კონსოლს აქვს. LuckPerms proxy-ზე გადასვლის ნაწილად დააყენე და არა მის შემდეგ.

BungeeCord-იდან Velocity-ზე გადასვლა ნაბიჯ-ნაბიჯ#

დაგეგმე გათიშვის მოკლე ფანჯარა. Backend-ებს ერთი პარამეტრის შეცვლა და გადატვირთვა სჭირდება და ერთდროულად forwarding-ის ორივე სახეს ვერ მიიღებენ.

1. გააკეთე proxy-ის plugin-ების აუდიტი. ჩამოწერე BungeeCord-ის plugins საქაღალდის ყველა jar და თითოეულისთვის იპოვე Velocity-ის ვერსია. სადაც არ არის, იპოვე შემცვლელი ან გადაწყვიტე, რომ მის გარეშე ძლებ. ეს პირველად გააკეთე; ეს ის ნაბიჯია, რომელსაც გადასვლის შეჩერება შეუძლია.
2. შეამოწმე backend-ების ვერსიები და პროგრამა. Modern forwarding-ს Paper 1.13 ან უფრო ახალი სჭირდება. Spigot backend-ები Paper-ზე უნდა გადავიდნენ - ის იგივე სამყაროებს კითხულობს და იგივე plugin-ებს უშვებს. 1.13-ზე ძველი ყველაფერი legacy ან bungeeguard forwarding-ზე რჩება.
3. დააყენე Velocity BungeeCord-ის გვერდით. ჩადე velocity.jar ახალ დირექტორიაში, ერთხელ გაუშვი, რომ velocity.toml და forwarding.secret შეიქმნას, შემდეგ გააჩერე.
4. თარგმნე კონფიგურაცია ზემოთ მოცემული შესაბამისობის ცხრილით. BungeeCord-ის სერვერების სახელები შეინარჩუნე: backend-ებზე plugin-ები, რომლებიც მოთამაშეებს სახელით აგზავნიან (lobby, survival), იმუშავებენ, თუ სახელები არ შეიცვლება.
5. დააყენე proxy-ის plugin-ები, რომლებიც პირველ ნაბიჯზე იპოვე, LuckPerms-ით დაწყებული. თუ LuckPerms BungeeCord-ზე უკვე საერთო ბაზას იყენებდა, Velocity-ის ასლი იმავე ბაზაზე მიუთითე და ყველაფერი გადმოვა.
6. გააჩერე ქსელი. გააჩერე BungeeCord, შემდეგ თითოეული backend.
7. გადართე თითოეული backend. spigot.yml-ში დააყენე settings.bungeecord: false. config/paper-global.yml-ში შეავსე Velocity-ის ბლოკი და ჩასვი secret. თუ backend-ზე BungeeGuard იყო დაყენებული, წაშალე.
8. გაუშვი Velocity საჯარო პორტზე, შემდეგ backend-ები. Velocity-ის კონსოლში უყურე forwarding-ის შეცდომას, რომელიც პრობლემების მოგვარების სექციაშია აღწერილი.
9. შეამოწმე პირდაპირი კავშირები ყველა backend-თან და დარწმუნდი, რომ უარყოფილია.
10. BungeeCord-ის დირექტორია ერთი კვირა ხელუხლებლად დატოვე. უკან დაბრუნება ნიშნავს მე-7 ნაბიჯის შებრუნებას და ძველი jar-ის გაშვებას.

მე-7 ნაბიჯის backend-ის ცვლილება ასე გამოიყურება:

settings:  bungeecord: false

proxies:  bungee-cord:    online-mode: true  velocity:    enabled: true    online-mode: true    secret: 'paste-the-contents-of-forwarding.secret'

Paper-ის 1.19-მდე ვერსიებში ეს პარამეტრები config/paper-global.yml-ის ნაცვლად paper.yml-ში იყო, settings.velocity-support-ის ქვეშ. თუ შენი backend-ები ასეთი ძველია, გზამკვლევიდან აღებული გზის რედაქტირებამდე შეამოწმე, რომელი ფაილი გაქვს რეალურად.

Plugin messaging და backend-ის plugin-ები#

ბევრი backend plugin proxy-ს BungeeCord plugin messaging არხით ელაპარაკება: სერვერის ასარჩევი მენიუები, რომლებიც მოთამაშეებს სერვერზე აგზავნის, ნიშნები, რომლებიც მოთამაშეთა რაოდენობას აჩვენებს, მინიგეიმის plugin-ები, რომლებიც მოთამაშეებს lobby-ში აბრუნებს. ისინი BungeeCord-ისთვის დაიწერა და Velocity-ზეც მუშაობს, რადგან Velocity ამ არხს ახორციელებს. velocity.toml-ში ეს არის bungee-plugin-message-channel = true [advanced]-ის ქვეშ, ნაგულისხმევად ჩართული.

არ გადადის ის, რაც proxy-ზე BungeeCord plugin-ის არსებობას ეყრდნობოდა. თუ backend plugin proxy-ზე თანმხლებ plugin-ს ელოდება, ამ თანმხლებსაც Velocity-ის ვერსია სჭირდება. თითოეული plugin-ის გვერდზე "Velocity support" გადასვლის ღამემდე წაიკითხე და არა მის დროს.

ვერსიების თარგმნა მეორე გავრცელებული დამოკიდებულებაა. BungeeCord ქსელი, რომელიც კლიენტის რამდენიმე ვერსიას იღებს, ჩვეულებრივ ViaVersion-ს (ზოგჯერ ViaBackwards-ს და ViaRewind-საც) proxy-ზე ან backend-ებზე უშვებს. ViaVersion-ს Velocity-ის ვერსიაც აქვს და თანაბრად შეიძლება თითოეულ Paper backend-ზე იყოს; სად დადებ, გემოვნების საქმეა, ოღონდ ორივე ადგილას არ უნდა იყოს.

Bedrock მოთამაშეები Geyser-ითა და Floodgate-ით ორივე proxy-ზე მუშაობენ. Velocity-ზე Geyser და Floodgate proxy-ზე დააყენე, Floodgate კი თითოეულ backend-ზეც, იმავე key.pem-ით, რომ backend-ებმა Floodgate-ის მოთამაშეები ამოიცნონ - დეტალები Geyser-ის გზამკვლევშია.

ბრძანებები და ადმინისტრირება#

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

/velocity reload მართლა სასარგებლოა: ის velocity.toml-ში დამატებულ და წაშლილ სერვერებს ვინმეს გაგდების გარეშე ითვალისწინებს. BungeeCord-ის reload არასოდეს ყოფილა სანდო და BungeeCord-ის ადმინების უმეტესობა ნაცვლად proxy-ს გადატვირთავს, რაც მთელ ქსელს თიშავს.

Velocity-ის ყოველ ბრძანებას საკუთარი permission node აქვს (velocity.command.server, velocity.command.glist, velocity.command.send), ამიტომ მათ proxy-ზე LuckPerms-ით გასცემ და არა კონფიგურაციის ფაილში.

Proxy-ის ზომა პანელ ჰოსტზე#

არც ერთი proxy მძიმე არ არის. ნახევარი გიგაბაიტი heap-ი რამდენიმე ასეულ მოთამაშეზე ორივესთვის საკმარისია; სამუშაო ტრაფიკის შეკუმშვასა და დაშიფვრაზე დახარჯული CPU-ა. Proxy 1-2 GB გეგმაზე ერთი ბირთვით ნორმალურია. ფული backend-ებზე მიდის.

$ java -Xms512M -Xmx512M -XX:+UseG1GC -jar velocity.jar

ნებისმიერ პანელ ჰოსტზე ქსელი თითო პროცესზე ერთი სერვერია: proxy, lobby და ორი რეჟიმი ოთხი სერვერია, თითოეული საკუთარი მეხსიერების ლიმიტით, პორტით და backup-ებით. RE:NODE-ზე ყოველ Minecraft გეგმას ერთი port allocation მოჰყვება და მეტის დამატება Network ჩანართზე შეგიძლია; SFTP მონაცემები თითო სერვერზეა, რითაც ერთსა და იმავე forwarding.secret-ს ყველა backend-ზე ხელახლა აკრეფის გარეშე ატვირთავ. ყოველი სერვერი ცალკე container-ია საკუთარი საჯარო პორტით, ამიტომ forwarding-ის სექციაში აღწერილი პირდაპირი კავშირის ტესტი ფორმალობა არ არის - სწორედ modern forwarding იცავს ამ backend პორტებს თვითმარქვიებისგან. სამუშაოს ასე დაყოფის ზოგადი არგუმენტი აღწერილია სტატიაში CPU თუ RAM თამაშის სერვერებისთვის.

როცა proxy გაეშვება, მის წინ სახელი დააყენე A და SRV ჩანაწერებით, რომ მოთამაშეებმა მხოლოდ mc.example.com აკრიფონ - ზუსტი ჩანაწერი მოცემულია სტატიაში SRV ჩანაწერები Minecraft-ისთვის.

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

Velocity ლოგში წერს "Your server did not send a forwarding request to the proxy". Backend modern forwarding-ზე არ არის გამართული: proxies.velocity.enabled ჯერ კიდევ false-ია, ამ Paper ვერსიისთვის არასწორი ფაილი დარედაქტირდა, ან backend არ გადაიტვირთა.

მოთამაშეებს აგდებს შეტყობინებით "Unable to verify player details" ან decoder-ის შეცდომით. Backend-ზე secret არ ემთხვევა forwarding.secret-ს. მოძებნე კოპირებისას მოყოლილი ბოლო ახალი ხაზი ან ჰარი.

"If you wish to use IP forwarding, please enable it in your BungeeCord config as well!" ეს backend გეუბნება, რომ spigot.yml-ში ჯერ კიდევ bungeecord: true აქვს, proxy კი BungeeCord-ის სტილის მონაცემებს არ აგზავნის. Velocity-ზე modern forwarding-ით დააყენე false.

ყველა ახალ მოთამაშედ შემოდის. Forwarding გამორთულია ან none რეჟიმშია, ამიტომ backend-ები offline-mode UUID-ებს ხედავენ. სანამ არ გაასწორებ, თამაშის უფლება არავის მისცე; ყოველი შესვლა ქმნის მოთამაშის მონაცემებს, რომელთა გასუფთავებაც მოგიწევს.

Plugin, რომელიც BungeeCord-ზე მუშაობდა, არაფერს აკეთებს. ეს BungeeCord plugin იყო, რომელიც Velocity-ის plugins საქაღალდეში იდო. Velocity გაშვებისას ლოგში წერს, რომ მისი ჩატვირთვა ვერ მოახერხა; ზემოთ აახვიე.

სტაფმა ადმინის ბრძანებები დაკარგა. უფლებებს BungeeCord-ის config.yml-ის ჯგუფები ამუშავებდა. Velocity-ის node-ები LuckPerms-ში გასცე. LuckPerms-ის გზამკვლევი აჩვენებს, როგორ შემოფარგლო ისინი proxy-ით server კონტექსტის გამოყენებით.

FAQ#

BungeeCord-ს ჯერ კიდევ ავითარებენ?

დიახ. md_5 მას Minecraft-ის ახალი ვერსიებისთვის ანახლებს და ის კვლავ ფართოდ გამოიყენება. მიტოვებული არ არის; უბრალოდ ნაგულისხმევად ნაკლებად უსაფრთხო და Velocity-ზე ნელია, და მის forwarding-ს უსაფრთხოებისთვის firewall ან BungeeGuard სჭირდება.

შემიძლია BungeeCord plugin-ები Velocity-ზე გავუშვა?

არა. ორივეს ცალკე plugin API აქვს. თითოეული plugin-ისთვის Velocity-ის ვერსია მოძებნე; პოპულარული ქსელური plugin-ების უმეტესობას აქვს. Backend plugin-ები, რომლებიც მხოლოდ BungeeCord messaging არხს იყენებს, აგრძელებენ მუშაობას.

გადასვლისას backend-ებზე რამის შეცვლა მჭირდება?

დიახ, თითოზე ერთი გადართვა: გამორთე bungeecord spigot.yml-ში, ჩართე Velocity-ის მხარდაჭერა Paper-ის global კონფიგურაციაში და ჩასვი forwarding secret. სამყაროები, plugin-ები და მოთამაშის მონაცემები ისე რჩება, როგორც იყო.

ჩემი backend-ები 1.12.2-ზეა. მაინც შემიძლია Velocity-ის გამოყენება?

დიახ, modern-ის ნაცვლად legacy ან bungeeguard forwarding-ით. ჩაშენებულ დაცვას კარგავ, ამიტომ დაამატე BungeeGuard ან backend-ები ინტერნეტიდან მიუწვდომელი გახადე - იგივე სიფრთხილე, რასაც BungeeCord მოითხოვს.

შეამჩნევენ მოთამაშეები გადასვლას?

მხოლოდ გათიშვას და, თუ შეცვალე, MOTD-ს. მისამართი იგივე რჩება, UUID-ები იგივე რჩება, თუ forwarding გადასვლამდეც და მის შემდეგაც სწორი იყო, ხოლო სერვერების სახელები შეიძლება იგივე დარჩეს, რომ არსებულმა ასარჩევმა მენიუებმა იმუშაოს.

უსაფრთხოა Waterfall-ის გაშვების გაგრძელება?

მუშაობს, მაგრამ პროტოკოლის განახლებებს და უსაფრთხოების გასწორებებს აღარ იღებს. გადადი Velocity-ზე, ან დაბრუნდი BungeeCord-ზე, სანამ Minecraft-ის შემდეგი ვერსია გამოვა, რომლის მხარდაჭერაც გინდა.