Rust-ის wipe-ები: განრიგი, blueprint-ები და მოთამაშეების შენარჩუნება

Rust ყოველი თვის პირველ ხუთშაბათს რუკის wipe-ს გაიძულებს: სწორედ მაშინ უშვებს Facepunch ყოველთვიურ განახლებას, save-ის ფორმატი იცვლება და ძველი სამყაროები აღარ იტვირთება. ეს ერთადერთი wipe-ია, რომელსაც შენ ვერ ირჩევ. ყველაფერი დანარჩენი - მიჰყვება თუ არა blueprint-ები რუკას, რა ხდება სამ კვირაში შუალედში და რას ეუბნები ამის შესახებ მოთამაშეებს - შენზეა, და ამაში შეცდომა სერვერს ნებისმიერ დაგვიანებაზე უფრო სწრაფად ცარიელებს.

ეს არის მთელი საქმე: რას ამტვრევს იძულებითი wipe სინამდვილეში, რომელ ფაილებს შლის თითოეული ტიპის wipe-ი, როგორ აირჩიო ციკლი, რომელსაც შეინარჩუნებ, რა გააკეთო თავად დღეს და რა ვუყო იმ plugin-ებს, რომლებიც ავტორების დაწევამდე არ იტვირთება.

რას აიძულებს იძულებითი wipe სინამდვილეში#

თვის პირველ ხუთშაბათს, ჩვეულებრივ 19:00 UTC-ის ახლოს, Facepunch ერთდროულად უშვებს კლიენტის და სერვერის განახლებას. სამი რამ იცვლება ერთად და თავში მათი განცალკევება გამოგადგება.

• ქსელური პროტოკოლი. ახალ build-ზე მყოფი კლიენტები ძველ სერვერზე ვერ შედიან და პირიქით. სანამ არ განაახლებ, ყველა მოთამაშე connection protocol error-ს ხედავს და ასკვნის, რომ შენი სერვერი გათიშულია.
• Save-ის ვერსია. სამყაროს save ფაილის სახელში ვერსიის ნომრით იწერება და ახალი build წინას აღარ ტვირთავს. სწორედ ეს ხდის რუკის wipe-ს სავალდებულოდ და არა უბრალოდ სასურველად.
• პროცედურული გენერაცია. რუკის გენერაცია უმეტეს თვეს იცვლება. იგივე seed და იგივე სამყაროს ზომა იძულებითი wipe-ის შემდეგ სხვა რუკას იძლევა, ამიტომ რუკის შენარჩუნება არჩევანი არ არის, თუნდაც მოგწონდეს.

Blueprint-ებს ამათგან არაფერი ეხება. იძულებითი wipe რუკის wipe-ია; blueprint-ების მონაცემთა ბაზა ცალკე ფაილია და გადარჩება, თუ თავად არ წაშლი. ყველა კამათი "სრულ wipe-სა" და "რუკის wipe-ს" შორის, რაც კი გინახავს, ერთ ფაილზე კამათია.

რუკის wipe და blueprint wipe სხვადასხვა ფაილებია#

ყველაფერი, რასაც Rust-ის სერვერი ახსოვს, ინსტალაციის დირექტორიაში ცხოვრობს, server/<identity>/-ში, სადაც <identity> არის ის, რასაც +server.identity-ს გადასცემ. ისწავლე ეს საქაღალდე და wipe-ი შეწყვეტს იდუმალებას.

server/  main/                                      the identity folder    cfg/      server.cfg                             convars executed at startup      users.cfg                              ownerid, moderatorid, bans    proceduralmap.3500.1934572.248.map       the generated terrain    proceduralmap.3500.1934572.248.sav       everything built on it    player.blueprints.3.db                   what players have learned    player.deaths.3.db    player.identities.3.db    player.states.3.db    player.tokens.dboxide/  plugins/  config/  data/  logs/            if you run Oxide

რუკის ფაილის სახელი არის proceduralmap.<worldsize>.<seed>.<version>.map, რაც მართლაც გამოსადეგია: მოქმედი სერვერის სამყაროს ზომასა და seed-ს პირდაპირ დისკიდან ამოიკითხავ და ერთი შეხედვით დაინახავ, რომ ვერსიის ნომერი განახლების შემდეგ გადაინაცვლა.

რამდენიმე შენიშვნა, რომელიც მოგვიანებით კამათს დაგიზოგავს. თუ წაშლი მხოლოდ .sav-ს და .map-ს დატოვებ, იგივე რელიეფს მიიღებ, რომელზეც არაფერი ააშენებია. ეს კანონიერი არჩევანია სერვერისთვის, რომლის რუკაც ხალხს მოსწონს - სანამ შემდეგი იძულებითი wipe მაინც არ გააუქმებს ამ ფაილს. oxide/data არის ადგილი, სადაც plugin-ები კლანის წევრობას, ბალანსებს, cooldown-ებს და სახლების მდებარეობას ინახავენ, ამიტომ "სრული wipe", რომელიც მას ხელს არ უხლებს, ახალ რუკაზე ყველას მის ძველ კლანსა და ძველ ბანკის ბალანსს დაუბრუნებს. ეს გადაწყვიტე შეგნებულად და არა შემთხვევით.

ციკლის არჩევა და მისი დაცვა#

ოთხი ციკლი მუშაობს და ერთი წესი, რომელიც უფრო მნიშვნელოვანია, ვიდრე არჩევანი: დაიცავი ის. სერვერი, რომელიც წლის განმავლობაში ყოველ ხუთშაბათს 19:00 UTC-ზე იწმინდება, თამაშის მოყვარულებში ჩვევას ქმნის. სერვერს, რომელიც იწმინდება "როცა მოსაბეზრებელი გახდება", დაბრუნებადი მოთამაშეები არ ჰყავს, რადგან ვერავინ დაგეგმავს საღამოს შეგრძნების გარშემო.

გასათვალისწინებელი რამ მოსახლეობის მრუდია. უმეტეს community სერვერზე wipe-ის შემდგომი პირველი ორმოცდარვა საათი ციკლის თამაშის დროის უმეტეს ნაწილს იძლევა და მეხუთე დღისთვის სერვერი პიკის მცირე ნაწილზე მუშაობს. ყოველკვირეული ციკლი შენ უმეტესად პიკთან გაჩერებს და მშენებლებს ღლის. ყოველთვიური ციკლი მშენებლებს იმას აძლევს, რისთვისაც მოვიდნენ, შენ კი სამ მშვიდ კვირას და რიგს wipe-ის დღეს გიტოვებს. Biweekly ამიტომაც არის გავრცელებული კომპრომისი.

Blueprint-ის wipe-ები მეორე სახელურია. Blueprint-ების შენარჩუნება დაბრუნებას იაფს ხდის - მოთამაშე, რომელმაც კვირა გამოტოვა, უკან არ არის - და პირველ დღეს scrap-ის ნაცვლად რესურსებისთვის შეჯიბრად აქცევს. მათი წაშლა ყველას ათანაბრებს, ოღონდ პირველ დღეს tech tree-ს გრინდად აქცევს, რომლისგანაც გასაქცევადაც ზოგი Rust-ს თამაშობს. არცერთი არასწორი არ არის. არასწორია ამის შეცვლა უთქმელად, რადგან მოთამაშეები, რომლებმაც საღამო BP wipe-ის გარშემო დაგეგმეს, ამას შესვლისას აღმოაჩენენ.

Seed, სამყაროს ზომა და რა გიჯდება ისინი#

ახალი რუკა ნიშნავს ახალ seed-ს და შესაძლოა ახალ ზომას. ორივე გაშვების ხაზზე დგინდება და ორივეს ლანდშაფტზე მეტი შედეგი აქვს.

$ ./RustDedicated -batchmode -nographics \    +server.identity "main" \    +server.hostname "Longship | Biweekly | Next wipe Thu 2 Oct 19:00 UTC" \    +server.port 28015 \    +server.level "Procedural Map" \    +server.seed 1934572 \    +server.worldsize 3500 \    +server.maxplayers 100 \    +server.saveinterval 300 \    +server.tickrate 10 \    +rcon.web 1 +rcon.port 28016 +rcon.password "a-long-random-string" \    +app.port 28082

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

ამ ცხრილში ორი რამ ხალხს უკვირს. პირველი ისაა, რომ Rust-ის მეხსიერების მოხმარება ყველაზე დაბალია wipe-ის დღეს და ყველაზე მაღალი შემდეგის წინა დღეს, რადგან ბაზები და deployable-ები გროვდება - ამიტომ სერვერს, რომელიც პარასკევის სურათით შეარჩიე, ოთხშაბათისთვის არ ეყოფა. მეორე ისაა, რომ რუკის გენერაცია თავად არის სერვერის ცხოვრების ყველაზე მძიმე მომენტი: wipe-ის შემდეგ პირველი გაშვება მთელ სამყაროს მეხსიერებაში აგებს, სანამ .map ფაილს ჩაწერს, და სერვერს გენერაციისას შეიძლება მეხსიერება ამოეწუროს ისეთ გეგმაზე, რომელიც მზა რუკას სრულიად კარგად გაუძლებდა. თუ შენი wipe გაშვებისას ვარდება და რუკის შემცირების შემდეგ მეორე ცდაზე მუშაობს, ეს მოხდა.

Port-ები და დისტანციური ადმინისტრირება#

თუ შენი ჰოსტი ცალკე query port-ს გამოყოფს, server.queryport ცხადად დააყენე და ნაგულისხმევზე ნუ დაეყრდნობი. RCON არის ინსტრუმენტი, რომლითაც wipe-ს რეალურად ჩაატარებ: Facepunch-ის RCON გვერდის web კონსოლით ან desktop კლიენტით. ის პაროლით ავთენტიფიცირდება კავშირზე, რომელიც საჭიროზე ფართოდ არ უნდა გახსნა - RCON-ის უსაფრთხო გამოყენება პრაქტიკაში აღწერს, რას ნიშნავს ეს. Game server-ის port-ები ახსნილი ხსნის, საერთოდ რატომ არსებობს query port.

ბრძანებები, რომლებიც wipe-ის დღემდე უნდა იცოდე, მოკლეა. server.save აიძულებს save-ს. server.writecfg users.cfg-ს და მფლობელობის ცვლილებებს დისკზე წერს - გამოტოვე და შენი moderator-ების სია შემდეგ restart-ზე გაქრება. quit არის სუფთა გამორთვა, რომელიც ჯერ ინახავს; ყველაფერი, რაც პროცესს კლავს, კარგავს სამყაროს server.saveinterval წამამდე.

Wipe-ის დღის runbook#

1. წინა დღეს გააკეთე identity საქაღალდის სრული backup და დაბლოკე rotation-ისგან. გამოაქვეყნე შეხსენება. ეს არის backup, რომელიც დაგჭირდება, თუ არასწორ რამეს წაშლი, და მისი გაკეთების ერთადერთი შანსი გაქვს.
2. Wipe-ის საათზე სერვერი სუფთად გააჩერე. გამოიყენე კონსოლის quit ბრძანება ან პანელის Stop ღილაკი. Kill ბოლო რამდენიმე წუთს კარგავს, რაც არ აქვს მნიშვნელობა რუკაზე, რომლის წაშლასაც აპირებ, მაგრამ დიდი მნიშვნელობა აქვს, თუ უკან დაბრუნება გადაწყვიტე.
3. განაახლე სერვერი. steamcmd +force_install_dir <path> +login anonymous +app_update 258550 validate +quit. Anonymous login მუშაობს; validate ნელია და ნაწილობრივი განახლების ერთადერთი საიმედო გამოსწორებაა. დანარჩენი SteamCMD-ის ახსნაშია.
4. დაელოდე შენს mod framework-ს. ნუ გამოტოვებ. იხილე შემდეგი თავი.
5. წაშალე save ფაილები. რუკის wipe-ისთვის *.sav და *.map, BP wipe-ისთვის დამატებით player.blueprints.*.db, და რასაც შენი გეგმა კიდევ მოითხოვს. ინსტრუმენტი file manager ან SFTP-ია; ჩანიშნული დავალება ფაილებს ვერ წაშლის.
6. დააყენე ახალი seed და სამყაროს ზომა გაშვების ხაზზე და შეამოწმე, რომ ისინი იგივეა, რაც გამოაცხადე.
7. გაუშვი და უყურე. რუკის გენერაცია დიდ რუკაზე რამდენიმე წუთი გრძელდება და გამოსავალი, რომელიც პროგრესს ჰგავს, არ არის. დაელოდე startup-complete ხაზს, სანამ ვინმეს ეტყვი.
8. ხელახლა გამოაქვეყნე დეტალები: hostname, აღწერა, Discord, wipe tracker-ები. სერვერი მხოლოდ მაშინ არის გაწმენდილი, როცა სხვები ამას იციან.

მთელი თანმიმდევრობა ოცდაათიდან სამოც წუთამდე გრძელდება, თუ არაფერი გაფუჭდა, და ის დაახლოებით ოთხიდან ერთ თვეს ფუჭდება, რაც არგუმენტია იმისთვის, რომ ის გააკეთო ფიქსირებულ საათზე, როცა ფხიზლად ხარ, და არა შუაღამით.

Oxide, Carbon და plugin-ები wipe-ის დღეს#

თუ შენი სერვერი Oxide-ს (uMod) ან Carbon-ს უშვებს, ყოველთვიური განახლება მას ამტვრევს. არა ხანდახან - ყოველ თვე, დიზაინით, რადგან framework-ები ჩაერთვებიან თამაშის კოდში, რომელიც ახლახან შეიცვალა. ახალი პროტოკოლის build ჩვეულებრივ საათებში ჩნდება, და სერვერის გაშვება მის გამოჩენამდე გაძლევს სერვერს, რომელიც საერთოდ plugin-ების გარეშე მუშაობს: არც permission-ები, არც kit-ები, არც კლანების სისტემა, არც anti-cheat, და მოთამაშეები ჩუმად იყენებენ იმას, რასაც შენი plugin-ები აკავებდა.

ჩვევა, რომელიც ამას თავიდან გაცილებს: SteamCMD-ის განახლების შემდეგ შეამოწმე, რომ framework-მა გამოაქვეყნა build ახალი ვერსიისთვის, სანამ გაუშვებ. თუ შენი სერვერი ჩატვირთვისას თავად განახლდება, ეს ნიშნავს, რომ wipe-ის დღეს auto-start უნდა გამორთო.

• Plugin-ები ცხოვრობენ oxide/plugins-ში, როგორც .cs ფაილები, და იტვირთებისას კომპილირდებიან; plugin, რომელიც ვერ დაკომპილირდა, შეცდომას კონსოლში ბეჭდავს, დანარჩენები კი აგრძელებენ.
• კონფიგურაცია oxide/config-შია, მონაცემები oxide/data-ში და ეს ორი გამუდმებით ერევათ. მონაცემების წაშლა მოთამაშის მხარის მდგომარეობას აბრუნებს; კონფიგურაციის წაშლა შენს პარამეტრებს.
• Permission-ები wipe-ებს გადაურჩებიან, თუ არ გაასუფთავებ. oxide.grant group default kit.use და მისთანანი ინახება და არ გამოითვლება.

შეინახე განახლებამდელი მუშა oxide საქაღალდის ასლი და ჩანაწერი, რომელ plugin-ის ვერსიებზე იყავი. რა უნდა გააკეთო, როცა mod-ის განახლება ტეხავს ამ პრობლემის ზოგადი ვერსიაა, ხოლო modded სერვერის სისუფთავე ის ჰიგიენაა, რომელიც plugin-ების სიას ერთი წლის wipe-ების განმავლობაში მართვადს ტოვებს.

შეტყობინება იქ, სადაც ხალხი მართლა წაიკითხავს#

wipe-ის შეტყობინებების უმეტესობა ვარდება, რადგან ისინი იქ იდება, სადაც მხოლოდ ისინი ხედავენ, ვისაც ისედაც ყურადღება აქვს.

• სერვერის სახელი თავად არის შეტყობინება. server.hostname ერთადერთი ველია ბრაუზერში, რომელსაც ყველა კითხულობს. ჩასვი მასში ციკლი და შემდეგი თარიღი: Longship | Biweekly | Next wipe Thu 2 Oct. განაახლე ის wipe-ის დასრულებისთანავე და არა შემდეგის წინა დღეს.
• `server.description` და `server.url` სერვერის ინფო პანელზე ჩანს. აღწერა რამდენიმე ხაზს იტევს და სწორი ადგილია წესებისთვის, ციკლისთვის და Discord-ის მოწვევისთვის.
• Wipe tracker-ები თავად გაგინახავენ. ისინი ახალ რუკას query მონაცემებიდან ამოიცნობენ, ამიტომ არაფრის გაგზავნა არ გჭირდება. რასაც აკონტროლებ, ისაა, ეუბნება თუ არა სახელი და აღწერა tracker-იდან მოსულ მოთამაშეს, როდის იქნება შემდეგი wipe.
• თამაშში, დღით ადრე და საათით ადრე, და არა ხუთი წუთით ადრე. RCON-ით say მუშაობს; countdown plugin უკეთესია, რადგან მეორდება.
• Discord, დაგეგმილი. შეტყობინება, რომლის გაგზავნაც უნდა გახსოვდეს, შეტყობინებაა, რომელსაც იმ თვეს დაგავიწყდება, როცა ყველაფერი დანარჩენი ფუჭდება.

ზედმეტი კომუნიკაციის მიზეზი თავაზიანობა არ არის. მოთამაშე, რომელიც შედის და თავის ბაზას გაუჩინარებულს ხედავს გაფრთხილების გარეშე, ასკვნის, რომ სერვერი შემთხვევით ან მტრულად განწყობილი ადმინის მიერ გადაიტვირთა, და აღარ ბრუნდება იმის გასარკვევად, რომელი. მოთამაშე, რომელმაც იცოდა, რომ ეს მოდის, wipe-ის დღეს შემოდის იმ საათზე, რომელიც უთხარი. Game server community-ის გაზრდა ამ წრის დანარჩენ ნაწილზეა.

Backup-ები და რა გადაურჩება wipe-ს#

Wipe-ი და შეცდომა დილით ერთნაირად გამოიყურება, ამიტომ wipe-მდელი backup ერთადერთი რამ არის "გავწმინდეთ" და "არასწორი სერვერი დავკარგეთ" შორის. გააკეთე ის ყოველ wipe-მდე, შეინახე შემდეგამდე და გაიტანე მანქანიდან, რომელიც ორიგინალს ინახავს.

RE:NODE-ზე Schedules tab cron გამოსახულებას აწესრიგებულ დავალებებით უშვებს - backup, კონსოლის ბრძანება, power action - ამიტომ wipe-მდელი backup და გაჩერება ფიქსირებულ საათზე შეიძლება მოხდეს, გაღვიძებული ხარ თუ არა; cron გამოსახულებები ახსნილი გამოსახულების წერას ფარავს, ხოლო დაგეგმილი დავალებები, რომლებიც ღირს ამბობს, კიდევ რა უნდა იყოს იქ. Backup slot-ები ყველა გეგმაზეა, backup-ები ინახება იმ მანქანის გარეთ, რომელსაც იცავენ, და backup შეიძლება დაიბლოკოს, რომ rotation არ წაშალოს - სწორედ ეს სჭირდება wipe-მდელ snapshot-ს. Save ფაილების წაშლა მაინც file manager-ის ან SFTP-ის საქმეა; განრიგი ამ ნაწილს ვერ გააკეთებს.

რასაც ვერ გააკეთებს, ისაა, რომ დაამტკიცოს backup-ის მუშაობა. Backup-ები, რომლებიც მართლა აღდგება ამას ვრცლად ამტკიცებს; მოკლე ვერსია ასეა: ერთხელ, მშვიდ კვირას, მისი სატესტო სერვერზე აღდგენა უფრო ღირს, ვიდრე მათი წლიანი აღება. Rust-ის სამყარო რამდენიმე ფაილია და აღდგენა სწრაფია, სწორედ ამიტომ არავინ არასოდეს ამოწმებს.

მეხსიერება ციკლის განმავლობაში დასაკვირვებელი მეორე რამ არის. Rust-ის სერვერის მოხმარება იზრდება, რაც ბაზები შენდება, და სერვერი, რომელიც მეხსიერების ლიმიტს მიაღწევს, ჩერდება და თავიდან იწყება და swap-ზე არ რჩება - სუფთად, მაგრამ კარგავს ყველაფერს, რაც შენახული არ იყო. ხშირ სერვერზე შეამოკლე server.saveinterval და წაიკითხე restart განრიგები, რომლებიც გვეხმარება, სანამ ღამის restart-ს დაამატებ, რომელიც არავის უთხოვია.

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

მოთამაშეები ყოველთვიური განახლების შემდეგ connection protocol error-ს იღებენ. სერვერი ჯერ არ განახლებულა. გაუშვი SteamCMD validate-ით და გადატვირთე.

სერვერმა ახალი რუკა შექმნა, თუმცა wipe არ გაგიკეთებია. შეიცვალა seed, სამყაროს ზომა ან save-ის ვერსია. შეადარე .map ფაილის სახელი შენს გაშვების არგუმენტებს - ფაილის სახელში მყოფი რიცხვები არის სამყაროს ზომა და seed, რომლითაც ის შეიქმნა.

სამყარო wipe-ის შემდეგ დაბრუნდა. .sav წაიშალა, მაგრამ სერვერმა ჩატვირთა .sav.old ან ფაილი სხვა identity საქაღალდეში. შეამოწმე server.identity და საქაღალდის შიგთავსი ჩამოწერე და file manager-ის ძებნას ნუ ენდობი.

განახლების შემდეგ plugin-ები არ ჩაიტვირთა. Framework ახალი პროტოკოლისთვის არ გადაშენებულა, ან გადაშენდა და არ დაყენებულა. კონსოლი გაშვებისას ამბობს, რომელია.

Moderator-ებმა restart-ზე უფლებები დაკარგეს. ownerid-ისა და moderatorid-ის ცვლილებები users.cfg-ში არასოდეს ჩაწერილა. მინიჭების შემდეგ გაუშვი server.writecfg.

სერვერს wipe-ის შემდეგ პირველ გაშვებაზე მეხსიერება ამოეწურა. ეს რუკის გენერაციაა და არა თამაში. შეამცირე server.worldsize, ან გაუშვი გენერაცია ერთხელ უფრო დიდ გეგმაზე და შეინახე .map ფაილი.

FAQ#

როდის არის ზუსტად Rust-ის იძულებითი wipe?

ყოველი თვის პირველ ხუთშაბათს, როცა Facepunch ყოველთვიურ განახლებას უშვებს, ჩვეულებრივ UTC-ით საღამოს. განახლება save-ის ფორმატს ცვლის, ამიტომ წინა რუკა ვერ ჩაიტვირთება, რაც არ უნდა გირჩევნია.

უნდა წავშალო blueprint-ები, როცა რუკა იწმინდება?

არა. Blueprint-ები ცხოვრობს player.blueprints.*.db-ში, რომელსაც იძულებითი wipe არ ეხება. მისი წაშლა ცალკე, შეგნებული არჩევანია და ის ყველაზე დიდი გადაწყვეტილებაა იმაზე, როგორ იგრძნობა შენი სერვერი.

რა ხშირად უნდა იწმინდებოდეს Rust-ის სერვერი?

იმდენად ხშირად, რამდენსაც შეინარჩუნებ. ყოველკვირეული რუკები ყოველთვიური blueprint-ებით დატვირთულ სერვერებს უხდება, biweekly უხდება უმეტეს community-ს, ხოლო მხოლოდ იძულებითი - მშენებლებს და roleplay-ს. თანმიმდევრულობა ინტერვალზე მნიშვნელოვანია.

შემიძლია იმავე რუკის შენარჩუნება wipe-ის მიღმა?

იძულებით wipe-ებს შორის - დიახ: წაშალე .sav და დატოვე .map და ყველა იცნობ რელიეფზე თავიდან იწყებს. იძულებით wipe-ს მიღმა - არა: გენერაცია იცვლება, ამიტომ იგივე seed სხვა რუკას იძლევა.

რატომ იყენებს ჩემი სერვერი წინა კვირაზე მეტ მეხსიერებას?

იმიტომ, რომ მოთამაშეები აშენებდნენ. Rust-ის მეხსიერების მოხმარება ობიექტების რაოდენობას მისდევს, რომელიც wipe-ის ციკლში იზრდება და wipe-ისას განულდება. გაზომე wipe-ის წინა დღეზე და არა მის შემდეგ დღეზე.

უნდა ვუთხრა მოთამაშეებს wipe-მდე?

დიახ, და საჭიროზე ადრე. დღით ადრე თამაშში, კვირით ადრე სერვერის სახელში. გაუფრთხილებელი wipe შემთხვევითისგან არ გამოირჩევა და მოთამაშეები მას ისე აღიქვამენ.