Minecraft-ის datapack-ები: ინსტალაცია, თანმიმდევრობა და გამართვა

Datapack არის JSON ფაილებისა და .mcfunction სკრიპტების საქაღალდე, რომელსაც თამაში ისე ტვირთავს, თითქოს მისი ნაწილი იყოს. მას შეუძლია რეცეპტების, loot-ის, advancement-ების, სამყაროს გენერაციისა და game rule-ების შეცვლა, ის მთლიანად სერვერზე მუშაობს, ამიტომ არავის არაფრის დაყენება არ სჭირდება, და vanilla-ზეც და Paper-ზეც ერთნაირად მუშაობს. ჩააგდე world/datapacks/-ში, გაუშვი /datapack list და თუ იქ არ ჩანს, ცხრა შემთხვევაში ათიდან zip-ში ერთი ზედმეტი საქაღალდეა. ამ პოსტის დანარჩენი ნაწილი დანარჩენი ერთი შემთხვევისთვისაა.

რას შეუძლია და რას არ შეუძლია datapack-ს#

Datapack-ები თამაშის საკუთარი modding ფორმატია და იმის სია, რასაც ისინი მოიცავს, ბევრად გაიზარდა. მიმდინარე ვერსიებში pack-ს შეუძლია განსაზღვროს ან ჩაანაცვლოს:

• ხელით დამზადების, გამოწვის, smithing-ისა და stonecutting-ის რეცეპტები.
• Loot table-ები, რომლებითაც ბლოკები, მობები, ლუქები და თევზაობა წყვეტს, რას მოგცემს.
• Advancement-ები, იმათ ჩათვლით, რომლებიც დამალულია და მხოლოდ event-ის trigger-ად გამოიყენება.
• ფუნქციები - ბრძანებების სიები - და tag-ები, რომლებიც მათ ჩატვირთვისას ან ყოველ tick-ზე უშვებს.
• Predicate-ები და item modifier-ები, loot-სა და advancement-ების მიერ გამოძახებადი ხელახლა გამოყენებადი პირობები და გარდაქმნები.
• Tag-ები: ბლოკების, ნივთების, არსებების, სითხეებისა თუ ფუნქციების ჯგუფები, რომლებზეც თამაში და სხვა pack-ები სახელით მიუთითებენ.
• სამყაროს გენერაცია: განზომილებები, განზომილების ტიპები, ბიომები, სტრუქტურები, feature-ები და ხმაურის პარამეტრები.
• ახალი data-driven რეესტრები, როგორიცაა damage type-ები, ჯადოქრობები, banner-ის ნახატები და trim-ის მასალები, რომლებიც ვერსიის მიხედვით განსხვავდება.

რას ვერ აკეთებს, ისევე მნიშვნელოვანია, რადგან ხალხი plugin-ის მოლოდინით მოდის. Datapack-ს თვითნებური event-ის მოსმენა არ შეუძლია; ერთადერთი კაუჭები load და tick ფუნქციის tag-ები და advancement trigger-ების სიაა. ის ვერ ინახავს მდგომარეობას scoreboard-ებისა და command storage-ის მიღმა, ვერაფერს აკეთებს მთავარი thread-ის გარეთ, ვერ ხსნის კონფიგურაციის ეკრანს, ვერ უკავშირდება მონაცემთა ბაზას და ვერ ხედავს ან ცვლის იმას, რასაც plugin აკეთებს. Permission-ები, ჩატის ფორმატირება, ტერიტორიის დაცვა, ეკონომიკა და rollback plugin-ის სფეროა.

ბოლო სტრიქონს შენიშვნა აქვს. რადგან datapack სერვერის მხარეს მუშაობს, მისი ეფექტები ყველა მოთამაშეს აღწევს, Geyser-ით შემოსული Bedrock მოთამაშეების ჩათვლით. ყველაფერი, რაც გარეგნობით შესაბამის resource pack-ზეა დამოკიდებული, მათთვის სწორად არ გამოიყურება და ხშირად Java მოთამაშეებისთვისაც არა, თუ pack-ს არ გასცემ. თუ datapack-ებს plugin-ებთან ზოგადად ადარებ, Paper, Fabric თუ vanilla გვიჩვენებს, რომელი სერვერის პროგრამა რა შესაძლებლობას გაძლევს.

სად ცხოვრობს datapack-ები სერვერზე#

ერთი ბილიკი: world/datapacks/, სადაც world არის ის, რასაც server.properties-ში level-name ამბობს. ყოველი pack საქაღალდეა ან .zip და ორივე ერთნაირად იქცევა.

world/  level.dat  datapacks/    house-rules/      pack.mcmeta      data/    vt-multiplayer-sleep.zip

აქ ორი რამ ხალხს აკვირვებს.

პირველი, Paper-სა და Spigot-ზე nether და end ცალკე დირექტორიებია - world_nether და world_the_end - მაგრამ datapack-ები მაინც მხოლოდ მთავარი სამყაროს საქაღალდიდან იტვირთება. pack-ის world_nether/datapacks/-ში ჩაგდება საერთოდ არაფერს აკეთებს. Pack-ები სერვერისთვის ერთხელ იტვირთება და ყველა განზომილებაზე მოქმედებს.

მეორე, zip-ს pack.mcmeta არქივის ზედა დონეზე უნდა ჰქონდეს. თუ Windows Explorer-ში საქაღალდეს მონიშნავ და შეკუმშავ, არქივში ერთი საქაღალდე იქნება, რომელშიც pack.mcmeta დევს, და სერვერი მას იგნორირებს. მონიშნე შიგთავსი - pack.mcmeta და data - და ისინი შეკუმშე. იგივე ხაფანგი პირიქითაც ჩნდება, როცა panel-ის ფაილ მენეჯერს იყენებ, რომელიც არქივებს ადგილზე ხსნის: სწორად აგებულ pack zip-ს გახსნი და datapacks/-ში pack-ის საქაღალდის ნაცვლად ცალკეული ფაილები მიგიღია. zip ატვირთე და დატოვე შეკუმშული, ან გახსენი მისივე საკუთარ საქაღალდეში. SFTP და ფაილ მენეჯერი შეიცავს კავშირის დეტალებს იმისთვის, რომელ გზასაც არჩევ.

pack.mcmeta, pack_format და 1.21-ის გადარქმევა#

ყოველ pack-ს ზუსტად ერთი pack.mcmeta სჭირდება თავის ძირში:

{  "pack": {    "pack_format": 48,    "description": "House rules"  }}

pack_format არის თავად data pack ფორმატის ვერსიის ნომერი და ის იცვლება ყოველ ჯერზე, როცა თამაში ფაილების ფორმას ცვლის. დასამახსოვრებლად ღირს:

შემდგომი რელიზები ნომერს ზრდიან, ხანდახან ერთ მინორულ ვერსიაში ორჯერაც, ამიტომ უფრო ახალი ვერსიის ნომერი ამ ვერსიის release notes-იდან აიღე და არ გამოიცნო. 1.20.2-დან pack-ს დიაპაზონის გამოცხადებაც შეუძლია, ასე ერთი ჩამოტვირთვა რამდენიმე ვერსიას ემსახურება:

{  "pack": {    "pack_format": 48,    "supported_formats": { "min_inclusive": 41, "max_inclusive": 57 },    "description": "House rules"  }}

არასწორი pack_format ყოველთვის ფატალური არ არის - რაც სინამდვილეში მნიშვნელოვანია, ისაა, არის თუ არა შიგნით ფაილები იმ განლაგებაში, რომელსაც ეს ვერსია ელოდება - მაგრამ სერვერი pack-ს შეუთავსებლად მონიშნავს და ეს პირველი რამაა შესამოწმებელი, როცა pack იტვირთება და არაფერს აკეთებს.

განლაგების ცვლილება, რომელმაც ყველაზე მეტ ძველ pack-ს დააზიანა, 1.21-ში მოვიდა: data/<namespace>/-ის შიგნით დირექტორიები მრავლობითიდან ერთობითზე გადავიდა.

თავად tags/-მა სახელი შეინარჩუნა; მის შიგნით საქაღალდემ - არა. 1.20-ისთვის დაწერილი pack, 1.21-ის სერვერზე ჩაგდებული, ჩვეულებრივ შეცდომის გარეშე იტვირთება და ჩუმად არაფერს აკეთებს, რადგან სერვერი function/-ში ეძებს და ცარიელ რეესტრს პოულობს. თუ pack, რომელიც იცი რომ კარგია, ეფექტს არ იძლევა და ლოგში არაფერია, ყველაფერზე ადრე საქაღალდეების სახელები შეამოწმე.

Namespace-ები გზის მეორე ნახევარია. data/minecraft/... თამაშის საკუთარ ფაილებს გადაფარავს - ასე აიძულებს pack ხრეშს ყოველთვის კაჟი დააგდოს, საკუთარი data/minecraft/loot_table/blocks/gravel.json-ის მიწოდებით. data/yourname/... ახალ რამეებს განსაზღვრავს. Namespace-ისა და ფაილების სახელები პატარა ასოებით უნდა იყოს და მხოლოდ ასოებს, ციფრებს, ქვედა ტირეს, წერტილსა და დეფისს შეიცავდეს.

ჩართვა, თანმიმდევრობა და გადატვირთვა#

საქაღალდეში სამყაროს ჩატვირთვისას ნაპოვნი pack-ები პირველად ავტომატურად ირთვება; ამის შემდეგ ჩართულთა სია და მათი რიგი level.dat-ში ცხოვრობს. მართე ის კონსოლიდან:

$ datapack list$ datapack list available$ datapack enable "file/house-rules" last$ datapack disable "file/vt-multiplayer-sleep.zip"

სახელი არის file/ პლუს საქაღალდის ან zip-ის სახელი ზუსტად ისე, როგორც დისკზეა, და ციტირება სჭირდება slash-ის გამო. enable არჩევით პოზიციას იღებს: first, last, before <other> ან after <other>.

რიგი წყვეტს, ვინ იმარჯვებს. როცა ორი pack ერთსა და იმავე ფაილს განსაზღვრავს - ორივე ერთი ნივთის რეცეპტს იძლევა ან ორივე ერთსა და იმავე loot table-ს ცვლის - რიგში უფრო გვიანი pack ადრინდელს მთლიანად ანაცვლებს. ეს merge არ არის. ჩაშენებული vanilla pack ყოველთვის პირველია, სწორედ ამიტომ შეუძლია ნებისმიერ pack-ს თამაშის გადაფარვა. ფუნქციის tag-ები სხვანაირად იქცევა და ერთიანდება, ამიტომ ორი pack, რომელიც #minecraft:tick-ს ამატებს, ორივე მუშაობს.

ცვლილების რესტარტის გარეშე გამოსაყენებლად გადატვირთე - ოღონდ ფრთხილად, რომელ reload-ს იღებ. Paper-სა და Spigot-ზე უბრალო /reload Bukkit-ის plugin reload-ია, რაც მოქმედი სერვერის გატეხვის კარგად ცნობილი გზაა. vanilla-ს namespace აქვს:

$ minecraft:reload

ის ხელახლა აგებს რეცეპტებს, loot table-ებს, advancement-ებს, tag-ებსა და ფუნქციებს და ხელახლა უშვებს ყველაფერს #minecraft:load tag-ში. ის რელიეფს თავიდან არ აგენერირებს და არ აუქმებს იმას, რაც ფუნქციამ უკვე გააკეთა.

კიდევ ერთი კონტროლი, რომლის ცოდნაც ღირს, server.properties-შია:

initial-enabled-packs=vanillainitial-disabled-packs=

ისინი წყვეტენ, რომელი pack-ებით იწყებს ახალი სამყარო, და ასევე ასე რთავ თამაშის საკუთარ ექსპერიმენტულ feature pack-ებს dedicated server-ზე, რადგან იქ სამყაროს შექმნის ეკრანი არ არის, სადაც უჯრას მონიშნავდი. ამ feature pack-ების სახელები ყოველ რელიზზე იცვლება, ამიტომ release notes-იდან აიღე. ამ ფაილში დანარჩენი ყველაფერი აღწერილია პოსტში server.properties ახსნილი.

Vanilla Tweaks და სხვა მზა pack-ები#

Vanilla Tweaks ნაკრებია, რომლითაც სერვერების უმეტესობა იწყებს. საიტზე თამაშის ვერსიას ირჩევ, გინდა pack-ებს ნიშნავ და ერთ zip-ს ჩამოტვირთავ. ეს გარე zip კონტეინერია: გახსენი და მიიღებ თითო zip-ს თითო pack-ისთვის, და სწორედ ეს შიდა zip-ები იდება datapacks/-ში. გარე zip-ის ატვირთვა Vanilla Tweaks-ის ინსტალაციის უშედეგობის მეორე ყველაზე გავრცელებული მიზეზია.

ისინი, რომლებიც multiplayer სერვერზე თავის ადგილს იმსახურებს:

• Graves, რომელიც მოთამაშის ინვენტარს გაფანტვის ნაცვლად აღსადგენ საფლავში ათავსებს. გამოცადე, სანამ ენდობი; ის ცუდად ურთიერთქმედებს keepInventory-სთან და ნებისმიერ plugin-თან, რომელიც სიკვდილსაც ამუშავებს.
• მეტი მობის თავი, ორმაგი shulker-ის ნაჭუჭები და ფოთლების სწრაფი გაქრობა - პატარა კომფორტის ცვლილებები, რომლებზეც არავინ კამათობს.
• Anti-grief pack-ები creeper-ებისა და enderman-ებისთვის, რომლებიც სამყაროს დაცვის plugin-ის გარეშე სუფთად ინახავს.
• Coordinates HUD, რომელიც კოორდინატებს scoreboard-ის გვერდით პანელზე აჩვენებს მოთამაშეებს, რომლებსაც F3 არ ხედავენ.
• Armour statues, armour stand-ის რედაქტორი, რომელიც ყველაზე მოთხოვნადი სამშენებლო ხელსაწყოა.

ზოგი ძველი ფავორიტი ახლა ზედმეტია. Multiplayer sleep gamerule-ია: playersSleepingPercentage ნაგულისხმევად 100-ია და 30-ზე დაყენება ნიშნავს, რომ მოთამაშეების მესამედს ღამის გამოტოვება შეუძლია. სანამ pack-ს დაამატებ, შეამოწმე, ხომ არ აკეთებს თამაში ამას თვითონ.

Vanilla Tweaks იმავე სახელებით resource pack-ებსაც აქვეყნებს და ისინი კლიენტის მხარისაა. თუ გინდა, რომ ყველა მოთამაშეს ჰქონდეს, ეს არის resource-pack და resource-pack-sha1 server.properties-ში, რაც სხვა საქმეა - იხილე MOTD, icon და resource pack-ები. Modrinth-საც დიდი datapack კატალოგი აქვს. ამ ყველაფრისთვის ერთი დაწკაპუნებით დამყენებელი არ არსებობს; ყოველი pack ფაილია, რომელსაც ატვირთავ.

საკუთარის დაწერა და გამართვა#

ყველაზე პატარა სასარგებლო pack ოთხი ფაილია. ჩატვირთვის ფუნქცია საქმის მოსამზადებლად, tick ფუნქცია ტაიმერით დაცული, რომ წამში ოცჯერ რეალურ სამუშაოს არ აკეთებდეს, და ორი tag, რომლებიც მათ უშვებს.

scoreboard objectives add hr.timer dummytellraw @a {"text":"House rules loaded","color":"gray"}

scoreboard players add #t hr.timer 1execute if score #t hr.timer matches 20.. run function houserules:second

scoreboard players set #t hr.timer 0execute as @a[nbt={OnGround:1b}] at @s run particle happy_villager ~ ~ ~

{  "values": ["houserules:tick"]}

შესაბამისი data/minecraft/tags/function/load.json, რომელიც houserules:load-ზე მიუთითებს, ამთავრებს საქმეს. გაუშვი /minecraft:reload და კონსოლს უყურე.

როცა რაღაც არ მუშაობს, ეს სია თანმიმდევრობით გაიარე:

1. /datapack list ჩართულად აჩვენებს? თუ ის სიაშიც კი არ არის, პრობლემა zip-ის სტრუქტურაა ან არასწორი სამყაროს საქაღალდე.
2. კონსოლი გადატვირთვისას შეცდომას აჩვენებს? Parse-ის შეცდომები ფაილს ასახელებს და ჩვეულებრივ ხაზსა და სიმბოლოსაც.
3. გაუშვი ფუნქცია ხელით: /function houserules:load. თუ ხელით მუშაობს, მაგრამ ავტომატურად არა, tag-ის ფაილია არასწორი - არასწორი საქაღალდის სახელი, არასწორი namespace ან შეცდომა ფუნქციის ბილიკში.
4. შეამოწმე ფაილის გაფართოება. Windows ნაგულისხმევად ცნობილ გაფართოებებს მალავს, ამიტომ ფაილი, რომელიც შენ tick.mcfunction გგონია, ხშირად tick.mcfunction.txt-ია.
5. შეამოწმე JSON ბოლოში დარჩენილ მძიმეებზე. თამაშის parser მკაცრია და ბოლოში დარჩენილი მძიმე მთელ ფაილს კლავს.

ლოგიკისთვის, რომელსაც რამის მოხდენაზე უნდა რეაგირება, სტანდარტული ხერხია advancement trigger-ით, ჯილდოს ფუნქციით და ამ ფუნქციის ბოლოს revoke-ით, რომ ხელახლა ამოქმედდეს. ეს plugin listener-თან შედარებით მოუხერხებელია, მაგრამ იმის უმეტესობას ფარავს, რაც ხალხს უნდა: მოთამაშე მობს კლავს, ნივთს ამზადებს, ბიომში შედის ან რამეს იღებს. სერვერის ბრძანებების cheatsheet შეიცავს selector-ისა და execute-ის სინტაქსს, საიდანაც ეს ფუნქციები აიგება.

ორი ზღვარი, რომელიც უნდა იცოდე. function-permission-level server.properties-ში ნაგულისხმევად 2-ია, ამიტომ ფუნქციებს არ შეუძლიათ ისეთი ბრძანებების გაშვება, რომლებსაც დონე 3 ან 4 სჭირდება, მაგალითად /ban ან /op. და maxCommandChainLength, gamerule ნაგულისხმევი 65536-ით, ზღუდავს, რამდენი ბრძანება შეიძლება გაუშვას ერთმა ჯაჭვმა, სანამ თამაში გააჩერებს, რაც უსაფრთხოების ბადეა, რომელიც გაუკონტროლებელ რეკურსიულ ფუნქციას სერვერის თან წაყოლას უშლის.

რა ღირს ცუდი datapack და როგორ დაინახო ეს#

ყველაფერი, რასაც datapack აკეთებს, სერვერის მთავარ thread-ზე ხდება, tick-ის შიგნით. #minecraft:tick-ში მყოფი ფუნქცია სამუდამოდ წამში ოცჯერ მუშაობს და თუ ის execute as @e-ით იწყება, ის ყოველ ჩატვირთულ chunk-ში ყველა ჩატვირთულ არსებას წამში ოცჯერ გადის, იცვლება რამე თუ არა.

გამოსწორებები იგივეა, რაც tick-ბიუჯეტის ნებისმიერ პრობლემას აქვს:

• გამოიყენე scoreboard მთვლელი, რომ ძვირი ნაწილი წამში ერთხელ ან ყოველ ხუთში ერთხელ მუშაობდეს და არა ყოველ tick-ზე.
• @e-ს @a ამჯობინე და როცა არსებები გჭირდება, selector შეავიწროვე: type=, distance=, tag=, limit=. მხოლოდ type= ფილტრი ხშირად სამუშაოს ორი რიგით ამცირებს.
• ძვირი რამის გაკეთებამდე execute if-ით დაიცავი, სამუშაოს გაკეთებისა და შედეგის გადაგდების ნაცვლად.
• ძალიან ფრთხილად იყავი fill-თან, clone-თან და forceload-თან. Pack, რომელიც chunk-ებს ძალით ტვირთავს, მათ სამუდამოდ tick-ში ინახავს, რაც დროებითი feature-ის მუდმივი ფასია.

გასაზომად vanilla-ს საკუთარი profiler აქ spark-ზე უკეთესია, რადგან დროს ცალკეულ ფუნქციებს სახელით მიაწერს:

$ minecraft:debug start$ minecraft:debug stop

ის სერვერის debug საქაღალდეში ჩაწერს ანგარიშს, სადაც სექციებად არის დაშლილი, სად წავიდა tick-ის დრო, ფუნქციებიც ჩათვლით. spark გეტყვის, რომ ფუნქციის მენეჯერი ძვირია; vanilla-ს ანგარიში გეტყვის, რომელი ფუნქცია. ყველაფრისთვის დანარჩენისთვის - plugin-ები, არსებები, chunk-ების ჩატვირთვა, garbage collection - გამოიყენე spark, როგორც აღწერილია პოსტში Minecraft-ის lag-ის დიაგნოსტიკა spark-ით.

pack-ის მოხსნა და ვერსიის განახლებისგან გადარჩენა#

Pack-ის გამორთვა, რომელიც მხოლოდ რეცეპტებს, advancement-ებს, loot table-ებს ან ფუნქციებს ამატებდა, უსაფრთხოა. მოთამაშეებს უკვე არსებული ნივთები რჩებათ, რეცეპტები წიგნიდან ქრება და სამყაროში არაფერი ზიანდება.

Pack-ის გამორთვა, რომელმაც სამყაროს გენერაცია დაამატა, უსაფრთხო არ არის და სწორედ ეს კარგავს სამყაროებს.

Worldgen pack-ებს უფრო ჩუმი პრობლემაც აქვს: ისინი მხოლოდ იმ chunk-ებზე მოქმედებს, რომლებიც ჩართვის შემდეგ დაგენერირდა. ბიომის pack-ის ჩართვა სამყაროზე, რომელიც ხალხმა უკვე შეისწავლა, ძველ და ახალ რელიეფს შორის მკვეთრ ნაკერს გაძლევს, დაგენერირებული არეალის კიდეზე. Worldgen-ზე გადაწყვიტე გაშვებამდე და არა მის შემდეგ - რაც ერთ-ერთი მიზეზია border-ის შიგნით წინასწარი გენერაციისა, როგორც პოსტშია სამყაროს border და წინასწარი გენერაცია.

ვერსიის განახლებისას ყველა pack უნდა გადაამოწმო. შეამოწმე, აქვს თუ არა თითოეულს სამიზნე ვერსიის build, განაახლე pack_format და 1.21-ს თუ კვეთ, დირექტორიები გადაარქვი. გააკეთე ეს სამყაროს ასლზე და არა ცოცხალზე. Minecraft-ის ვერსიის განახლებები უფრო ფართო თანმიმდევრობას აღწერს და გულწრფელი რჩევა უცვლელია: backup pack-ის ჩართვამდე აიღე და არა მას შემდეგ, რაც რამე დააზიანა. RE:NODE-ზე თამაშის გეგმები ორ backup სლოტს მოიცავს, მოთხოვნით ან განრიგით, და აღდგენა ერთი ღილაკია, ამიტომ pack-ის შენი სამყაროს ერთადერთ ასლზე ტესტირებას გამართლება არ აქვს.

FAQ#

სჭირდებათ თუ არა მოთამაშეებს რამის დაყენება datapack-ის გამოსაყენებლად?

არა. Datapack-ები სერვერის მხარისაა და ტვირთება მანამ, სანამ ვინმე დაუკავშირდება. ერთადერთი გამონაკლისი გარეგნობაა: თუ pack საკუთარ ტექსტურებს ან მოდელებს ეყრდნობა, ისინი resource pack-იდან მოდის, რაც ცალკე კლიენტის მხარის ფაილია.

რატომ არ ჩანს ჩემი pack /datapack list-ში?

თითქმის ყოველთვის არქივია. pack.mcmeta zip-ის ზედა დონეზე უნდა იდოს და არა შემფუთავ საქაღალდეში. ამის შემდეგ შეამოწმე, მთავარ სამყაროს საქაღალდეში ჩააგდე თუ world_nether-ში და server.properties-ის level-name იქ მიუთითებს თუ არა, სადაც ფიქრობ.

მუშაობს datapack-ები Paper-ზე?

სრულად. Paper მათ ზუსტად ისე ტვირთავს, როგორც vanilla. ერთადერთი Paper-ის სპეციფიკური ხაფანგია /reload, რომელიც datapack-ების ნაცვლად plugin-ებს ტვირთავს; გამოიყენე /minecraft:reload.

შეუძლია datapack-ს plugin-ის ჩანაცვლება?

რეცეპტებისთვის, loot-ისთვის, drop-ებისთვის, advancement-ის ჯილდოებისა და პატარა წესების ცვლილებისთვის ხშირად დიახ და ნაკლები დატვირთვით. Permission-ებისთვის, ეკონომიკისთვის, ტერიტორიების დაცვისთვის, ჩატის ფორმატირებისა და rollback-ისთვის არა - მათ API სჭირდება, რომელიც datapack-ს არ აქვს.

იმუშავებს ჩემი datapack-ები Minecraft-ის განახლების შემდეგაც?

ზოგჯერ. მინორული განახლებები ჩვეულებრივ მხოლოდ pack_format-ს ზრდის. 1.21-ის გადარქმევამ მრავლობითიდან ერთობით დირექტორიების სახელებზე ძველი pack-ების უმეტესობა პირდაპირ გააფუჭა და ახალი data-driven რეესტრები რეგულარულად ჩნდება. ცოცხალი სერვერის განახლებამდე ყოველი pack სამყაროს ასლზე გამოცადე.

რამდენი datapack არის ზედმეტი?

ისეთი რიცხვი, რომელიც ზედმეტია, არ არსებობს. მნიშვნელობა აქვს, რამდენ სამუშაოს აკეთებენ ისინი თითო tick-ზე. ოცი pack, რომელიც მხოლოდ რეცეპტებს განსაზღვრავს, გაზომვადად არაფერი ღირს; ერთ pack-ს, რომელიც ყოველ tick-ზე ყველა არსებას სკანირებს, შეუძლია შენი ყველა plugin-ზე მეტი დაგიჯდეს.