Factorio-ს მოდები და UPS: რა ჯდება megabase სერვერი

Factorio სერვერს ერთი მწარმოებლურობის რიცხვი აქვს და ის UPS-ია: updates per second, სამიზნე - 60. 60-ზე დაბლა თავად თამაში ნელდება - ლენტები უფრო ნელა მოძრაობს, ღუმელები უფრო ნელა დნობს, კუთხეში მდებარე საათი რეალურ დროს ჩამორჩება - ყველასთვის, ვინც დაკავშირებულია, და არც გამტარუნარიანობა და არც მეხსიერება ამას ვერ გამოასწორებს. UPS იმით განისაზღვრება, რამდენ ხანს გრძელდება სიმულაციის ერთი tick ერთ CPU core-ზე, მოდები კი ამ tick-ის გაგრძელების ყველაზე სწრაფი გზაა. ეს პოსტი აღწერს, როგორ დააყენო მოდები headless სერვერზე სწორად, წესს, რომელზეც ყველა ებმევა (ყველა კლიენტი ერთსა და იმავე სიას უშვებს), იმას, რა ჭამს tick-ის ბიუჯეტს რეალურად, და როგორ გაზომო save გამოცნობის ნაცვლად.

UPS არის მნიშვნელოვანი რიცხვი და არა FPS#

Factorio სიმულაციას ფიქსირებულ 60 update-ზე წამში უშვებს. ეს სერვერს აძლევს 16.67 მილიწამს, რომ ყველა surface-ზე ყველა entity ერთხელ განაახლოს. თუ ამას 9 ms-ში მორჩება, თამაში 60 UPS-ზე მუშაობს და მარაგიც რჩება. თუ 22 ms სჭირდება, თამაში დაახლოებით 45 UPS-ზე მუშაობს და სამყაროში ყველაფერი ნორმალური სიჩქარის სამ მეოთხედზე ხდება.

FPS ცალკე, კლიენტის მხარეს არსებული რიცხვია: რამდენჯერ ხატავს შენი მანქანა სამყაროს. headless სერვერს renderer საერთოდ არ აქვს, ამიტომ FPS-იც არ აქვს. ეს პირველია, რაც უნდა გაარკვიო, როცა ვინმე ამბობს, რომ სერვერი ჭედავს, რადგან სამი გავრცელებული საჩივარი სამ სხვადასხვა მიზეზს ეკუთვნის:

• ყველაფერი ნელია, ყველასთვის, საათის ჩათვლით. ეს UPS-ია. სერვერი საკმარისად სწრაფად ვერ ახდენს სიმულაციას.
• ჩემი თამაში ბუქსაობს, მაგრამ ქარხანა ნორმალურად მუშაობს. ეს კლიენტის FPS-ია, მის მანქანაზე.
• ჩემი პერსონაჟი უკან ბრუნდება, სხვები კარგად ჩანან. ეს მისი კავშირია და არა სერვერი.

იგივე განსხვავება გასდევს პოსტს რას ნიშნავს tick rate სინამდვილეში სხვა თამაშებისთვის. Factorio უჩვეულოა მხოლოდ იმით, რომ სიმულაციის სიჩქარე და თამაშის დროის შეგრძნება ერთი და იგივეა, ამიტომ UPS-ის დაკარგვა რეალური სიჩქარის დაკარგვაა და არა სიგლუვის.

რადგან update ციკლი ფაქტობრივად ერთი thread-ია, UPS-ს მხოლოდ უფრო სწრაფი core ზრდის. Factorio-ს გეგმაზე vCPU-ს დამატება გიყიდის მარაგს შენახვისთვის, ქსელისა და რამდენიმე ფონური ამოცანისთვის, სხვა არაფერს. ეს ყველაზე ნათელი შემთხვევაა იმ აზრისა, რომელიც წარმოდგენილია პოსტში CPU თუ RAM game სერვერებისთვის: ისინი ურთიერთშეცვლადი არ არის და მხოლოდ ერთია შენი ვიწრო ადგილი.

მოდების დაყენება headless სერვერზე#

მოდები არის zip ფაილები დაყენების mods/ დირექტორიაში, რომლებიც ზუსტად Name_Version.zip ფორმატით იწოდება - Krastorio2_1.4.0.zip, და არა Krastorio2.zip ან Krastorio2 (1).zip. ფაილის სახელში ვერსია მოდის info.json-ში მითითებულს უნდა ემთხვეოდეს, რადგან Factorio ასე ადგენს დამოკიდებულებებს.

/opt/factorio/mods/  mod-list.json  mod-settings.dat  Krastorio2_1.4.0.zip  flib_0.15.0.zip  stdlib_1.4.6.zip

headless build-ს მოდების ბრაუზერი არ აქვს, ამიტომ ორი პრაქტიკული გზა არსებობს. ჩამოტვირთე zip-ები mods.factorio.com-იდან ბრაუზერით და ატვირთე, ან - გზა, რომელიც რეალურად მასშტაბირდება - ააწყვე მოდების სია ერთმოთამაშიან თამაშში შენს მანქანაზე, სადაც თამაშის შიგნით მენეჯერი დამოკიდებულებებს შენთვის წყვეტს, და მთელი mods საქაღალდე ატვირთე. SFTP-ით ან file manager-ით ატვირთვა ორივე შემთხვევაში ერთი და იგივე საქმეა; SFTP და file manager შეიცავს დაკავშირების დეტალებს, თუ ეს ჯერ არ გიქნია.

დამოკიდებულებები თითოეული მოდის info.json-შია აღწერილი, და სერვერი უარს ამბობს გაშვებაზე, თუ რომელიმე აკლია, და ბეჭდავს სახელს და ვერსიების დიაპაზონს, რომელიც სჭირდებოდა. ეს შეცდომა ყველაზე სასარგებლო რამაა log-ში მოდების დაყენებისას, ამიტომ წაიკითხე და მოდებს შემთხვევით ნუ დააყენებ ხელახლა. დამოკიდებულებაში წინა ? ნიშნავს არასავალდებულოს, ! - შეუთავსებელს, ხოლო ~ ნიშნავს, რომ მოდი აუცილებელია, მაგრამ ჩატვირთვის თანმიმდევრობაზე გავლენას არ ახდენს.

მოდები ერთსა და იმავე საქაღალდეში იდება, რა ჰოსტზეც არ უნდა იყო. RE:NODE-ზე mods საქაღალდე პირველივე ჩატვირთვიდან არის და მოდები პირდაპირ მასში ვარდება SFTP-ით ან ბრაუზერის file manager-ით, რომელიც არქივებსაც ადგილზე ხსნის.

mod-list.json, ვერსიები და mod-settings.dat#

mods/mod-list.json წყვეტს, არსებული zip-ებიდან რომელი ჩაიტვირთოს რეალურად. მას თამაში წერს და ხელით რედაქტირება უსაფრთხოა:

{  "mods": [    { "name": "base", "enabled": true },    { "name": "elevated-rails", "enabled": true },    { "name": "quality", "enabled": true },    { "name": "space-age", "enabled": true },    { "name": "flib", "enabled": true },    { "name": "Krastorio2", "enabled": false }  ]}

ორი რამ არის შესამჩნევი. base მოდია და ყოველთვის სიაშია. და Space Age-ის გაფართოება სამ ცალკე მოდად მოდის - space-age, quality და elevated-rails - რომლებიც დამოუკიდებლად შეიძლება ჩაირთოს, ამიტომ სერვერს შეუძლია elevated rails დანარჩენის გარეშე გაუშვას.

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

mods/mod-settings.dat ყველა მოდის პარამეტრს შეიცავს. ეს binary ფაილია, ამიტომ ტექსტურ რედაქტორში ვერ შეცვლი, headless სერვერს კი პარამეტრების GUI არ აქვს. startup პარამეტრის შეცვლის ერთადერთი გონივრული გზა ისაა, რომ იგივე მოდების ნაკრები ერთმოთამაშიან თამაშში შენს მანქანაზე ჩატვირთო, იქ ყველაფერი დააყენო და მიღებული mod-settings.dat ატვირთო. Runtime-global პარამეტრები თამაშში ადმინს შეუძლია შეცვალოს; startup პარამეტრები restart-ის გარეშე საერთოდ ვერ იცვლება, რადგან ისინი prototype-ებს ცვლის.

მოდების სინქრონი, desync-ები და ერთნაირი სიის წესი#

Factorio-ში მხოლოდ კლიენტის მხარეს არსებული მოდის ცნება არ არსებობს. ყველა მოდი სიმულაციის ნაწილია - მაშინაც კი, თუ ის მხოლოდ GUI-ს ამატებს, ის Lua-ს უშვებს, რომელიც ყველა მანქანამ ერთნაირად უნდა გაუშვას - ამიტომ სერვერს და ყველა კლიენტს ერთი და იგივე მოდები უნდა ჰქონდეს ერთი და იგივე ვერსიებით და ერთი და იგივე startup პარამეტრებით. თამაში ამას აღასრულებს: შეუსაბამობას შესვლისას უარი ეთქმის და ნაჩვენებია სია იმისა, რაც განსხვავდება.

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

Desync-ები დეტერმინიზმის მეორე მხარეა. თუ ერთი მანქანის სიმულაცია სერვერისას გადაუხვევს, Factorio ამას აღმოაჩენს, კლიენტს გათიშავს, desync-ის ანგარიშს დაწერს და რუკას თავიდან ჩამოტვირთვას აიძულებს. ვანილაში ეს იმდენად იშვიათია, რომ ბაგად ღირს დარეპორტება. მოდებთან ეს ჩვეულებრივ მოდია, რომელიც რაღაც არადეტერმინისტულს აკეთებს, და თამაში ხშირად ამას log-ში პირდაპირ გეუბნება - მაგალითად, math.random()-ის event-ის გარეთ გამოძახება არასწორია სწორედ იმიტომ, რომ სხვადასხვა მანქანა სხვადასხვა რიცხვს მიიღებდა.

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

რა ჭამს UPS-ს რეალურად#

tick-ის ბიუჯეტი თითქმის მთლიანად აქტიური entity-ების განახლებაზე იხარჯება. ის, რაც სძინავს, თითქმის უფასოა; Factorio აგრესიულად აძინებს უსაქმო inserter-ებს, მანქანებსა და ლენტებს. ამიტომ კითხვა არასოდეს არის "რა ზომისაა ჩემი ბაზა", არამედ "რამდენი რამ აკეთებს რაღაცას ყოველ tick-ზე".

სამი მათგანი ცხრილის სტრიქონზე მეტს იმსახურებს.

Bot-ები ლენტების წინააღმდეგ. logistics ქსელი, რომელიც bot-ებით წამში ათას ნივთს გადააქვს, tick-ზე ბევრად მეტ სამუშაოს აკეთებს, ვიდრე ლენტების ნაკრები, რომელიც იმავეს გადააქვს, რადგან თითოეული bot ცალკე entity-ა პოზიციითა და მუხტის მდგომარეობით, ლენტები კი ტრანსპორტის ხაზის მაღალოპტიმიზებულ წარმოდგენას იყენებს, სადაც შეკუმშული ნივთების მწკრივი თითქმის უფასოა. Bot-ები მშვენიერია მშენებლობისთვის, დაბალი გამტარობის logistics-ისთვის და ყველაფრისთვის, რაც არარეგულარულია. ისინი არასწორი ინსტრუმენტია მთავარი bus-ისთვის. პირდაპირი insertion - მანქანიდან მანქანაში, არც ლენტი და არც bot - ორივეზე იაფია.

Beacon-ები და productivity. ყველაზე იაფი entity ის არის, რომელიც არ არსებობს. ოცი beacon-იანი assembler, რომელიც ისევე აწარმოებს, როგორც ოთხმოცი beacon-ის გარეშე, არა მხოლოდ ადგილის დაზოგვაა; ეს სამოცით ნაკლები entity-ის განახლებაა, სამოცით ნაკლები inserter და უფრო მოკლე ლენტების ქსელი. სწორედ ამიტომ გამოიყურება megabase-ები ისე, როგორც გამოიყურება.

მოდის Lua. მოდი, რომელიც ყოველ-tick event-ზე handler-ს არეგისტრირებს და მასში რეალურ სამუშაოს აკეთებს, ამ ხარჯს წამში სამოცჯერ იხდის სამუდამოდ, იმ entity-ების გარდა, რომლებსაც ამატებს. Overhaul პაკეტები ამ მხრივ ჩვეულებრივ კარგადაა დაწერილი; პატარა კომფორტის მოდებია ისინი, რომლებიც ჩუმად tick-ზე 2 ms ჯდება. ქვემოთ მოცემული benchmark გეტყვის, რომელია, რადგან იგივე save-ის გაშვება მოდთან და მის გარეშე შეგიძლია.

გაზომვა benchmark დროშით#

გამოცნობა შუადღის ფუჭად დაკარგვაა. headless build-ს შეუძლია save-ის გაშვება იმდენად სწრაფად, რამდენადაც CPU იძლევა, კლიენტებისა და rendering-ის გარეშე, და ანგარიში, რამდენ ხანს გაგრძელდა tick:

$ cd /opt/factorio$ ./bin/x64/factorio --benchmark ./saves/world.zip \    --benchmark-ticks 2000 --benchmark-runs 3 \    --benchmark-verbose all --mod-directory ./mods

--benchmark-ticks არის, რამდენი tick უნდა დასიმულირდეს, --benchmark-runs მთლიან პროცესს იმეორებს, რომ დისპერსია ნახო, ხოლო --benchmark-verbose all ამატებს სისტემების მიხედვით დაშლას: entity-ების განახლება, transport lines, circuit network, trains, ელექტრო ქსელი, სითხეები, robots და დანარჩენი. --mod-directory საშუალებას გაძლევს, სხვა mods საქაღალდეზე მიუთითო, და ზუსტად ასე ამოწმებ "რა ჯდება ეს მოდი" - save-ს ორჯერ ამოწმებ ორი საქაღალდით.

წაიკითხე საშუალო მილიწამები tick-ზე 16.67 ms ბიუჯეტის წინააღმდეგ. 10 ms-ის ქვემოთ კომფორტულია. 12-დან 16 ms-მდე სერვერი 60 UPS-ს მშვიდ მანქანაზე შეინარჩუნებს და მის ქვემოთ ჩამოვა, როცა ყუთზე სხვა რამე დაკავებულია. 16.67 ms-ზე მეტზე თამაში უკვე ნელა მუშაობს.

ორი გაფრთხილება. benchmark save-ს დეტერმინისტულად წინ უშვებს, ამიტომ ის ქარხანას ზომავს და არა მოთამაშეებს; თორმეტი ადამიანი, რომელიც რუკის ხედს ხსნის და blueprint-ებს აყენებს, სამუშაოს ამატებს, რასაც ის ვერ ხედავს. და benchmark შენს საკუთარ desktop-ზე შენი desktop-ის CPU-ს შესახებ გეუბნება და არა სერვერისას. გაუშვი იმ მანქანაზე, რომელიც რუკას მასპინძლობს, თუ შეგიძლია - პანელის კონსოლი ბრძანებას მიიღებს, რადგან ეს იგივე binary-ა.

გრაფიკულ კლიენტში F4 ხსნის debug პარამეტრებს, F5 კი debug overlay-ს რთავს, სადაც დროის გამოყენების პანელი იმავე სისტემების მიხედვით დაშლას ცოცხლად გაჩვენებს. მულტიპლეერულ თამაშში ის შენი მანქანის სამუშაოს აჩვენებს, მაგრამ UPS-ის მაჩვენებელი საერთოა.

Overhaul პაკეტები, Space Age და მეხსიერება#

დიდი მოდების პაკეტები ზომის შესახებ საუბარს მთლიანად ცვლის. Krastorio 2, Bob's და Angel's, Industrial Revolution 3, Pyanodons და სხვადასხვა კოსმოსური overhaul-ები prototype-ებს, რეცეპტებს და ხშირად მთელ ახალ surface-ებს ამატებს. ეფექტი სერვერზე სამმხრივია: თამაში გაშვებისას უფრო დიდხანს იტვირთება, მეხსიერების მოხმარება მუდმივად იზრდება, და tick თითოეულ entity-ზე უფრო ძვირი ხდება, რადგან თამაშში მეტი ტიპის entity-ა.

Space Age ამის ოფიციალური ვერსიაა. ყოველი პლანეტა, რომელსაც დაასახლებ, კიდევ ერთი surface-ა, რომელიც სიმულირდება, როცა მასზე რამე აქტიურია, ხოლო მოგზაურობაში მყოფი პლატფორმა კიდევ ერთია. ხუთი surface-ის Space Age თამაში უფრო ახლოა ხუთი სერვერის გაშვებასთან, ვიდრე ერთისა, და 4-6 GB რეალისტური რიცხვია და არა გულუხვი.

მეხსიერება UPS-გან განსხვავებულად იქცევა და ხალხი მათ ურევს. მეტი მეხსიერება განახლების სიხშირეს არ ზრდის. ის იძლევა უფრო დიდი რუკის, მეტი surface-ისა და მეტი მოდის prototype-ის შენახვის საშუალებას იმ გარეშე, რომ კონტეინერი ლიმიტზე გაჩერდეს. Factorio-ს შენახვისას მომენტალურად უფრო მეტი მეხსიერება სჭირდება, ვიდრე მუშაობისას, სწორედ ამიტომ კვდება სერვერი, რომელიც საათის განმავლობაში კარგადაა, ზუსტად autosave-ზე. RE:NODE-ზე მეხსიერების ლიმიტის მიღწევისას კონტეინერი ჩერდება და სუფთად იწყება ხელახლა და არ ხვდება swap-ში, რაც ამ თამაშისთვის სწორი ქცევაა - მაგრამ tick-ის შუაგულში restart ბოლო autosave-ის შემდეგ ყველაფერს გიღირს, ამიტომ ღირს პიკზე მაღალი ზომის არჩევა და არა პიკის ტოლი. როდის განაახლო შენი გეგმა ამ განსჯის ზოგადი ვერსიაა.

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

UPS-ის დაბრუნება ნელდებულ სერვერზე#

დაახლოებით იმ თანმიმდევრობით, რამდენს აბრუნებს ისინი ძალისხმევასთან შედარებით:

1. ჯერ benchmark. გაარკვიე, რომელი სისტემაა ძვირი, სანამ რამეს შეცვლი. Factorio-ს "ოპტიმიზაციის" ნახევარი არასწორ ქვესისტემას უმიზნებს.
2. წაშალე ზედმეტი radar-ები. ბაზის დამფარავი რამდენიმე radar კარგია. ხილვადობისთვის რუკაზე გაშლილი ოცდაათი რეალური ხარჯია გეიმფლეის ღირებულების გარეშე; გამოიყენე რუკის ping-ები და რამდენიმე დაზვერილი chunk.
3. შეამცირე უსაქმო bot-ები. გადახედე logistics ქსელის tab-ს: bot-ები, რომლებიც მუდმივად ჰაერში არიან, ძვირია. ქსელში roboport-ების რაოდენობის შემცირება ან მაღალი გამტარობის bot-კავშირის ლენტით ჩანაცვლება მაჩვენებელს ამოძრავებს.
4. გამორთე, რასაც არ იყენებ. გამორთე მტრის გაფართოება map-settings.json-ში ან გადადი მშვიდობიან რეჟიმზე, თუ biter-ების თამაში შენი თამაშის აზრი არ არის. დაბინძურების დიფუზია და pathfinding დიდ დაბინძურებულ რუკაზე ნამდვილად ძვირია.
5. Beacon-ებითა და module-ებით აღჭურვე დიდი საწარმოო ბლოკები. ნაკლები მანქანა, რომელიც მეტს აკეთებს, სტრუქტურული გამოსწორებაა.
6. გადახედე combinator-ების სპაგეტს. ყოველ-tick არითმეტიკა ასობით combinator-ზე გროვდება. ჩააყენე clock-ის უკან.
7. სერვერი ყოველკვირეულად გადატვირთე. UPS-ის გამოსწორება არ არის, მაგრამ მეხსიერებას ბრტყელს ინახავს და სუფთა save-ის წერტილს გაძლევს. Schedules tab-ს ამის გაკეთება შეუძლია - იხილე restart-ის გრაფიკები, რომლებიც გვეხმარება.

და შემდეგ გაჩერდი. სერვერი, რომელიც 60 UPS-ზე დგას 6 ms მარაგით, ოპტიმიზაციას არ საჭიროებს, და მომუშავე ბაზის თავიდან აგება რიცხვისთვის, რომელსაც ვერავინ აღიქვამს, სწორედ ისაა, როგორ კარგავენ ჯგუფები რუკის მიმართ ინტერესს. ოპტიმიზაცია მაშინ, როცა საათი ჩამორჩება და არა მანამდე.

თუ UPS კარგადაა, მაგრამ სერვერი მაინც არასწორად იგრძნობა, პრობლემა სხვაგანაა: ხმაურიანი მეზობელი გაზიარებულ ტექნიკაზე, jitter-იანი ქსელური გზა ან კლიენტი, რომელიც ვერ ასწრებს. გაზიარებული CPU და ხმაურიანი მეზობლები პირველს განიხილავს, ხოლო latency, jitter და packet loss - მეორეს.

მოდების განახლება save-ის გატეხვის გარეშე#

პორტალზე მოდები განახლდება, როცა მათი ავტორები აქვეყნებენ, და dependency lock ფაილი არ არსებობს. სერვერზე, რომელიც მნიშვნელოვანია, mods საქაღალდე დაფიქსირებულ მდგომარეობად მიიჩნიე:

1. აიღე save-ის backup და მთელი mods საქაღალდის ასლი, სანამ რამეს შეეხები. Backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა, ამიტომ ხანდახან აღადგინე ერთი - backup-ები, რომლებიც მართლა აღდგება ამას სიღრმისეულად ამტკიცებს.
2. განაახლე ერთ-ერთ მოდი ერთდროულად, როცა შეგიძლია, და წაიკითხე მისი changelog მიგრაციის შენიშვნებისთვის.
3. გაუშვი სერვერი და უყურე log-ს ჩატვირთვის განმავლობაში. მიგრაციის სკრიპტები ერთხელ, განახლების შემდეგ პირველ ჩატვირთვაზე მუშაობს, და იქ არსებული შეცდომები ის შეცდომებია, რომლებიც save-ს აზიანებს.
4. უთხარი მოთამაშეებს, რომ სერვერიდან დაასინქრონონ და თვითონ პორტალიდან არ განაახლონ, რომ ვერსიები ერთმანეთისგან ვერ გაიწიოს.

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

FAQ#

რამდენ მოდს გაუშვებს Factorio სერვერი?

ლიმიტი არ არსებობს და რაოდენობა არასწორი საზომია. ორმოცდაათი პატარა კომფორტის მოდი შეიძლება ერთ overhaul პაკეტზე ნაკლები დაჯდეს. მნიშვნელობა აქვს, რამდენი entity აქვს მიღებულ რუკას და რამდენი Lua მუშაობს ყოველ tick-ზე, რასაც benchmark დროშა წუთში გეტყვის.

რატომ არის ჩემი სერვერი 45 UPS-ზე, როცა CPU გრაფიკი 40%-ს აჩვენებს?

იმიტომ, რომ გრაფიკი core-ებზე საშუალოს იღებს. Factorio სიმულაციისთვის ერთ მათგანს იყენებს და ის 100%-ზეა. ოთხ core-იანი გამოყოფა ერთ-thread-იან დატვირთვასთან ყოველთვის დაუტვირთავად გამოიყურება, სინამდვილეში კი სრულად გაჯერებულია.

უნდა დააყენონ მოთამაშეებმა მოდები თვითონ?

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

შემიძლია მოდის დამატება უკვე მომუშავე რუკაზე?

დამატება ჩვეულებრივ უსაფრთხოა; ამოღება - არა. ახალი მოდის კონტენტი უბრალოდ ჩნდება. ამოღება წაშლის ყველა entity-ს, რომელსაც ის იძლეოდა, სამუდამოდ. ორივემდე save-ის backup აიღე და overhaul პაკეტი ცოცხალი რუკიდან არასოდეს ამოიღო.

ზრდის მეტი RAM UPS-ს?

არა. მეხსიერება სერვერს საშუალებას აძლევს, უფრო დიდი რუკა დაიჭიროს და არ მოკვდეს; ის tick-ს არ ამოკლებს. ამას მხოლოდ უფრო სწრაფი CPU core ან უფრო იაფი ქარხანა აკეთებს.

რა არის რეალისტური UPS-ის სამიზნე დიდი ბაზისთვის?

სამოცი, და დიზაინი ისე უნდა გააკეთო, რომ იქ დარჩე. სერიოზული megabase-ის მშენებლები ნაკლებს იღებენ, რადგან წარმოების მაჩვენებელს მისდევენ, მაგრამ ერთად მოთამაშე ჯგუფისთვის იმ წამს, როცა საათი ნელდება, თამაში სწორად აღარ იგრძნობა, ამიტომ 60 UPS შეზღუდვად მიიჩნიე და მის ფარგლებში ააშენე.