RimWorld Multiplayer-ის მოდები: თავსებადობა და ჩატვირთვის რიგი

RimWorld-ის მოდების უმეტესობა Multiplayer მოდთან მუშაობს, ხოლო ისინი, რომლებიც არ მუშაობს, ერთნაირად და ადვილად გამოსაცნობად ტყდება. მოდები, რომლებიც მხოლოდ მონაცემებს ამატებს - ახალ ნივთებს, ცხოველებს, ტანსაცმელს, შენობებს, XML-ში დაწერილ ფრაქციებს - ყოველთვის თავსებადია, რადგან მათში არაფერია, რაც desync-ს გამოიწვევდა. პრობლემა C# კოდიან მოდებშია: ყველაფერი, რაც ამატებს ღილაკს, gizmo-ს ან მენიუს, რომელიც თამაშს ცვლის, უნდა სინქრონიზდებოდეს, ხოლო ყველაფერი, რაც საკუთარ შემთხვევით რიცხვებს აგენერირებს ან საკუთარ ტაიმერებს ინახავს, უნდა დაპაჩდეს. Multiplayer მოდი შენი სიის ყველა მოდისთვის აჩვენებს საზოგადოების მიერ შეგროვებულ ქულას, Multiplayer Compatibility მოდი პოპულარული მოდების გრძელ სიას აპაჩებს, ხოლო ჩატვირთვის რიგის თავი ფიქსირებულია: Prepatcher, Harmony, Core, შენი DLC-ები, შემდეგ Multiplayer. ამ სახელმძღვანელოს დანარჩენი ნაწილი გასწავლის, როგორ წაიკითხო ქულები, როგორ შეადგინო სია, რომელსაც ოთხი ადამიანი გამოიყენებს, და როგორ დარწმუნდე, რომ ის მუშაობს, სანამ კოლონიაზე სამოც საათს დახარჯავ.

თუ ჯერ არ გაგირჩევია Multiplayer მოდსა და RimWorld Together-ს შორის, ჯერ წაიკითხე RimWorld-ის multiplayer სერვერის გზამკვლევი. ეს პოსტი მხოლოდ Multiplayer მოდზეა - ერთი საერთო კოლონია, დეტერმინისტული lockstep, ყველა მანქანა ერთსა და იმავე სიმულაციას აწარმოებს - რადგან სწორედ აქ წყვეტს მოდების თავსებადობა, შეგიძლია თუ არა საერთოდ თამაში.

რატომ ტყდება multiplayer ზოგ მოდთან და ზოგთან - არა#

Multiplayer მოდი ქსელში თამაშის მდგომარეობას არ აგზავნის. ის ბრძანებებს აგზავნის. როცა მოთამაშე pawn-ს დრაფტავს, bill-ს ცვლის ან ხეს მოსაჭრელად მონიშნავს, ეს მოქმედება იფუთება, tick-ით იღებს ბეჭედს და ყველა მანქანაზე ერთსა და იმავე მომენტში სრულდება. კოლონიის ყველა ასლი ერთსა და იმავე შედეგს ითვლის, რადგან მოდი RimWorld-ის სიმულაციას დეტერმინისტულს ხდის: შემთხვევითი რიცხვები ერთნაირი seed-ით არის ინიციალიზებული, ხოლო ყველაფერი, რაც მანქანებს შორის განსხვავდებოდა, ან სინქრონიზდება, ან სიმულაციის გარეთ რჩება.

მოდი ამას სამიდან ერთი გზით არღვევს.

1. ის თამაშს მომხმარებლის ინტერფეისიდან ცვლის sync-ის გვერდის ავლით. ახალი gizmo, მარჯვენა ღილაკის პუნქტი, პარამეტრების ფანჯარა, რომელიც შენობას ცვლის. კლიკი მხოლოდ ერთ მანქანაზე ხდება, დანარჩენები ამას ვერ იგებენ და კოლონიები იშლება. ეს ყველაზე გავრცელებული პრობლემაა და სწორედ მას ასწორებს თავსებადობის პაჩები - ისინი Multiplayer-ს ეუბნება, რომელი მეთოდები უნდა დასინქრონდეს.
2. ის იყენებს შემთხვევითობას ან მდგომარეობას, რომელსაც მოდი ვერ ხედავს. კოდი, რომელიც RimWorld-ის საკუთარის გარდა სხვა შემთხვევითი რიცხვების გენერატორს იძახებს, სისტემურ საათს კითხულობს, შედეგებს იმის მიხედვით ინახავს, რასაც ლოკალური მოთამაშე უყურებს, ან სამუშაოს ფონურ thread-ზე ასრულებს. ორი მანქანა ორ განსხვავებულ პასუხს იღებს.
3. ის ცვლის tick-ების მუშაობას. პროდუქტიულობის მოდები, რომლებიც ეკრანს გარეთ მყოფი ობიექტების tick-ებს ტოვებს, აჯგუფებს ან ზღუდავს, განსაკუთრებულ რისკს ქმნის, რადგან ის, რაც ეკრანზეა, ყოველ მოთამაშეს განსხვავებული აქვს. ზოგი მათგანი თავსებადი გახდა; დაშვებამდე შეამოწმე.

XML-ზე დაფუძნებული მოდები სამივეს თავს არიდებს, ამიტომ თამაშში თავსებადობის ფანჯარა პირდაპირ წერს, რომ ისინი ყოველთვის თავსებადია. ერთი პირობაც ახლავს: XML მოდი შეიძლება C# კოდიან framework მოდზე იყოს დამოკიდებული, და მაშინ ეს framework-იც უნდა იყოს თავსებადი.

მოდის შემოწმება: ქულები და სად ვიპოვოთ ისინი#

Multiplayer მოდი RimWorld-ის საკუთარ Mods ეკრანზე ამატებს Multiplayer compatibility ღილაკს. ის ხსნის ფანჯარას, სადაც ჩამოთვლილია შენი აქტიური, დაინსტალირებული და მოძველებული მოდები, თითოეულს სტატუსის ქულითა და შენიშვნებით. მონაცემები საზოგადოებისგან გროვდება, ჩამოიტვირთება Multiplayer-ის გუნდის სერვერიდან, ლოკალურად ინახება MpCache საქაღალდეში და შეიძლება გამოირთოს პარამეტრით "Show crowd-sourced compat info", თუ მათ ჩამოტვირთვას არ ისურვებ.

იგივე სკალა (0-ით, რაც ტესტირების გარეშეს ნიშნავს) გამოიყენება საზოგადოების ცხრილში, რომელიც მოდის Workshop გვერდზეა მიბმული, და Discord-ის mod-report არხზე, საიდანაც ქულები მოდის. მიიჩნიე ისინი საწყის წერტილად და არა გარანტიად. 4 ნიშნავს, რომ ვიღაცამ ამ მოდით ითამაშა და პრობლემა ვერ დაინახა; ის არაფერს გვეუბნება იმაზე, როგორ იქცევა მოდი შენი სიის დანარჩენ 150 მოდთან ერთად. თავად Multiplayer-ის გუნდის FAQ ამას პირდაპირ ამბობს: ორი მოდი, რომელთაგან თითოეული სრულად თავსებადად არის მითითებული, ერთად მაინც შეიძლება დესინქრონიზდეს.

როგორ მოვიქცეთ თითოეული ქულის შემთხვევაში:

• 4: ჩართე.
• 3: წაიკითხე შენიშვნები. "Minor" ჩვეულებრივ ერთი ღილაკი ან ერთი ფანჯარაა, რომელიც არ სინქრონიზდება. თუ შენი ჯგუფი ამ ფუნქციას არ გამოიყენებს, ის ფაქტობრივად 4-ია.
• 2: მხოლოდ მაშინ, თუ გაფუჭებული ნაწილის სრულად თავიდან აცილება შეგიძლია, და ტესტი განზრახ ჩაატარე.
• 1: დატოვე სიის გარეთ. ჩატვირთვის რიგის არანაირი გადალაგება 1 ქულას ვერ გამოასწორებს.
• Unknown: თავად შეამოწმე და შედეგი შეატყობინე, რომ შემდეგ ჯგუფს ეს აღარ მოუწიოს.

ქულები ვერსიებთან არის მიბმული. მოდი, რომელსაც ორი RimWorld ვერსიის წინ 4 ჰქონდა, შეიძლება კოდის ნახევარს მას შემდეგ გადაწერდა, და სწორედ ამიტომ არსებობს ფანჯარაში "Outdated" განყოფილება.

Multiplayer Compatibility მოდი#

Multiplayer Compatibility (პაკეტის id rwmt.MultiplayerCompatibility, იმავე RimWorld Multiplayer Team-ისგან) ერთი მოდია, სავსე სხვის მოდებზე პაჩებით. საკუთარი კონტენტი მას არ აქვს. თითოეული მხარდაჭერილი მოდისთვის ის არეგისტრირებს მეთოდებს, რომლებიც უნდა დასინქრონდეს, ნიშნავს მათ, რომლებიც მხოლოდ ლოკალურად უნდა გაეშვას, და ასწორებს შემთხვევითობას - ანუ ასრულებს იმ სამუშაოს, რომელსაც ორიგინალი მოდის ავტორი გააკეთებდა, multiplayer-ისთვის რომ დაეწერა.

მხარდაჭერილთა სია გრძელია და მუდმივად იცვლება. წერის დროისთვის მასში შედის Vanilla Expanded framework და Vanilla Expanded სერიის დიდი ნაწილი, Common Sense, Simple Sidearms, Pick Up And Haul, RimFridge, LWM's Deep Storage, Prison Labor, Alpha Animals და Alpha Biomes, სხვა მრავალთან ერთად. ავტორიტეტული სია მოდის საკუთარი აღწერა და მისი GitHub README-ა და არა შარშანდელი ფორუმის პოსტი.

სამი წესი:

• დააყენე ის, როცა კი C# მოდებს იყენებ. იმ მოდებისთვის, რომლებსაც არ აპაჩებს, ის არაფერს აკეთებს, ამიტომ მისი ქონა არაფრად ღირს.
• მას სჭირდება მიმდინარე Multiplayer. ის Multiplayer-ს დამოკიდებულებად აცხადებს და მასთან ერთად ახლდება. ერთის ძველი ასლი მეორის ახალ ასლთან ვერსიების შეუსაბამობას ელოდება.
• მოდის მის სიაში ყოფნა მოდს 4-იანად არ აქცევს. პაჩმა შეიძლება ძირითადი ფუნქციები დაფაროს და დანარჩენი დატოვოს. წასაკითხი მაინც თავსებადობის ფანჯრის ქულაა.

ზოგს ის საერთოდ არ სჭირდება, რადგან მათი ავტორები multiplayer-ს ნატიურად უჭერენ მხარს - Multiplayer API-ს თავად იძახებენ. Achtung! ჩვეულებრივი მაგალითია. ისინი პაჩის გარეშეც თავსებადად ჩანს.

ჩატვირთვის რიგი multiplayer-ის მოდების სიისთვის#

RimWorld-ის ჩატვირთვის რიგი ModsConfig.xml-ში activeMods სიაა, და გვიანდელი მოდები ადრეულს გადაფარავს. ზოგადი წესებისთვის - დამოკიდებულებები, გადაფარვები, კოდის კონფლიქტები - იხილე მოდების ჩატვირთვის რიგი ახსნილი. Multiplayer-ისთვის სიის თავი მოდების საკუთარი მეტამონაცემებით არის ფიქსირებული, და მისი არასწორად დალაგება სტარტზე შეცდომებს იწვევს და არა დახვეწილ ბაგებს.

• Prepatcher პირველია, Harmony-ზე და Core-ზე ზემოთ. Multiplayer-ის მიმდინარე რელიზები მას მკაცრ დამოკიდებულებად ასახელებს (0.11 ხაზში მან ძველი Harmony დამოკიდებულება ჩაანაცვლა), და სწორედ ის ამუშავებს multiplayer-ში რიტუალებს.
• Harmony შემდეგია. Prepatcher-ს საკუთარი Harmony-ის ასლი მოჰყვება, მაგრამ სხვა კოდიანი მოდების უმეტესობა მაინც brrainz.harmony-ს აცხადებს დამოკიდებულებად, ამიტომ დატოვე.
• Core და DLC-ები თავიანთი ჩვეულებრივი რიგით: Royalty, Ideology, Biotech, Anomaly, Odyssey.
• Multiplayer უშუალოდ ბოლო DLC-ის ქვემოთ. მოდის აღწერა ამას მსხვილი შრიფტით წერს, ხოლო მისი მეტამონაცემები აცხადებს, რომ HugsLib-მდე და Vanilla Expanded framework-მდე იტვირთება.
• Multiplayer Compatibility დაუყოვნებლივ Multiplayer-ის შემდეგ.
• შემდეგ framework-ები (HugsLib, Vanilla Expanded framework და ა.შ.), კონტენტ მოდები, და ბოლოს - პაჩ მოდები.

<activeMods>  <li>zetrith.prepatcher</li>  <li>brrainz.harmony</li>  <li>ludeon.rimworld</li>  <li>ludeon.rimworld.royalty</li>  <li>ludeon.rimworld.ideology</li>  <li>ludeon.rimworld.biotech</li>  <li>ludeon.rimworld.anomaly</li>  <li>ludeon.rimworld.odyssey</li>  <li>rwmt.multiplayer</li>  <li>rwmt.multiplayercompatibility</li>  <li>unlimitedhugs.hugslib</li>  <li>oskarpotocki.vanillafactionsexpanded.core</li>  <!-- content mods, then patches --></activeMods>

ფაილი RimWorld-ის შენახვის მონაცემების Config საქაღალდეშია: Windows-ზე %USERPROFILE%\AppData\LocalLow\Ludeon Studios\RimWorld by Ludeon Studios\Config, Linux-ზე ~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/Config. ხელით რედაქტირება იშვიათად გჭირდება - თამაშის Mods ეკრანი და დალაგების ხელსაწყოები, მაგალითად RimSort, მას თავად წერს და თითოეული მოდის loadAfter, loadBefore და modDependencies-ს კითხულობს - მაგრამ ეს ერთადერთი ადგილია, სადაც შეგიძლია ნახო, რა ჩატვირთა თამაშმა სინამდვილეში.

multiplayer-ში რიგს single player-ზე მეტი მნიშვნელობა აქვს ერთი მარტივი მიზეზით: შეერთებისას ამას ამოწმებს. თუ ყველას ერთი და იგივე მოდები სხვადასხვა რიგით აქვს, შემოერთებულ მოთამაშეს ეუბნება, რომ სიები ემთხვევა, მაგრამ რიგი - არა, და მას გადატვირთვა უწევს.

DLC-ები და ვერსიები: ყველაფერი უნდა ემთხვეოდეს#

Multiplayer-ის გუნდის პასუხი კითხვაზე "გვჭირდება თუ არა ერთი და იგივე DLC-ები" ისაა, რომ ყველაფერი ერთნაირი უნდა იყოს. მოთამაშე Biotech-ის გარეშე ვერ შეუერთდება თამაშს, სადაც host-ს Biotech ჩართული აქვს, რადგან host-ის სამყაროში არის Biotech-ის განსაზღვრებები, რომელთა ჩატვირთვაც client-ს არ შეუძლია. პრაქტიკული შედეგია, რომ ჯგუფის DLC-ების ნაკრები იმის თანაკვეთაა, რაც ყველას აქვს. თუ ერთ მეგობარს მხოლოდ ძირითადი თამაში აქვს, ან ისინი იყიდის DLC-ებს, ან ამ კოლონიისთვის ყველა თავისას გამორთავს.

თითოეული DLC-ის მხარდაჭერაც სხვადასხვა დროს გაჩნდა. Royalty და Ideology წლებია, მხარდაჭერილია. Anomaly-ის მხარდაჭერა 1.5 რელიზებში ეტაპობრივად შემოვიდა, რიტუალები და ზოგი მექანიკა დანარჩენზე გვიან გასწორდა, და გუნდის FAQ დიდხანს აფრთხილებდა მასთან desync-ებზე. Odyssey და gravship-ები მხარდაჭერილია 1.6 რელიზებში, რომლებიც ჯერ კიდევ აქტიურად ისწორება. თუ უახლესი DLC-ის გარშემო გრძელ კოლონიას გეგმავ, ჯერ წაიკითხე ბოლო release notes Multiplayer-ის GitHub releases გვერდზე და ტესტით კონკრეტულად DLC-ის მთავარი მექანიკები შეამოწმე (იხილე ტესტის გეგმა ქვემოთ).

ვერსიები სამ დონეზე უნდა ემთხვეოდეს:

Multiplayer მიმდინარე RimWorld ვერსიას მიჰყვება და აღწერაში მინიმალურ build-ს მიუთითებს; გუნდი მოდების ახალ ვერსიებს თამაშის ძველ ვერსიებზე არ ტესტავს. ყველა უახლეს საჯარო RimWorld build-ზე გყავდეს და beta ბრენჩზე არ გადახვიდეთ, თუ ამას მთელი ჯგუფი ერთად არ გააკეთებს.

რას ამოწმებს შეერთების ეკრანი და Sync configs#

როცა მოთამაშე უერთდება, Multiplayer მის თამაშს host-ისას ადარებს და თუ რამე განსხვავდება, აჩვენებს Data mismatch ეკრანს. მას ოთხი ჩანართი აქვს და თითოეული სხვადასხვას გვეუბნება.

• General: RimWorld-ის ვერსია და Multiplayer-ის ვერსია. სანამ ესენი არ დაემთხვევა, სხვა არაფრის გასწორება არ შეიძლება.
• Mod list: host-ის მოდები შენსას ადარებს, ყველაფერს, რაც აკლია, "Not installed" ეწერება. "Subscribe to missing" გამოგიწერს ყველა მოდს, რომელიც აკლია და Workshop-ზეა, და ფონურად ჩამოტვირთავს. "Apply server's mod list" შენს აქტიურ სიას host-ისით ანაცვლებს - შენი სია გადაიწერება, ამიტომ, თუ ის გენდომება, ჯერ შეინახე.
• Files: მოდები ერთი და იგივე სახელით, მაგრამ განსხვავებული ფაილებით. ჩვეულებრივ ერთ მოთამაშეს უფრო ძველი ვერსია აქვს, ან განახლებამ ფაილები დატოვა. გამოსავალია მოდის განახლება ან თავიდან გამოწერა; Core-ისა და DLC-ების განსხვავებისას ეკრანი გეუბნება, წაშალო მათი საქაღალდეები და Steam-ში თამაშის ფაილები გადაამოწმო.
• Configs: მოდების პარამეტრები, რომლებიც განსხვავდება.

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

configs ნაწილს host-ის Sync configs პარამეტრი აკონტროლებს, როცა თამაშს ჰოსტავ. მისი ჩართვისას შემოერთებული მოთამაშეები დროებით host-ის მოდების კონფიგურაციის ფაილებს იყენებენ: დისკზე არაფერი გადაიწერება და გადატვირთვა შენს საკუთარ configs-ს აბრუნებს. მოდის საკუთარი აღწერა სწორია: ის desync-ებს ამცირებს. ისიც გვაფრთხილებს, რომ ზოგი მოდი configs-ში მგრძნობიარე რამეს ინახავს, მაგალითად Twitch token-ებს, რომლებსაც სტრიმერების მოდები იყენებს, ამიტომ host-მა, რომელიც ასეთს იყენებს, გაზიარებამდე უნდა დაფიქრდეს.

Sync configs ჩართული დატოვე, თუ ასეთი მიზეზი არ გაქვს. მოდის განსხვავებული პარამეტრი - slider საცავის მოდში, გადამრთველი საბრძოლო მოდში - უხილავია იმ მომენტამდე, სანამ განსხვავებულ შედეგს არ გამოიღებს, და მაშინ ეს desync-ია აშკარა მიზეზის გარეშე.

საერთო მოდების სია, რომელიც საერთო რჩება#

Multiplayer მოდი სიამოვნებით გადააკოპირებს მოდების სიას host-იდან client-ზე. მაგრამ ის არ შეაჩერებს სიის შემდგომ კვირებში გაცალკევებას. ამას ეს ჩვევები აკეთებს.

1. სიას ერთი ადამიანი ფლობს. ჩვეულებრივ host. დანარჩენები გვთავაზობენ; ერთი ამატებს, აფასებს და ტესტავს.
2. დაიწყე თავსებადობის ფანჯრიდან და არა Workshop-ის კოლექციიდან, რომელიც სხვამ single player-ისთვის შეადგინა. გადაიარე აქტიურ სიაზე და ამოიღე ყველა 1, წაიკითხე შენიშვნები 2-სა და 3-ზე და უცნობები ტესტისთვის მონიშნე.
3. სია single player-ის სიაზე მცირე გქონდეს. ყოველი C# მოდი desync-ის კიდევ ერთი შანსია, ხოლო ყოველი desync მთელ ჯგუფს გადატვირთვად უჯდება. წმინდა XML კონტენტ მოდები იაფია; ახალი ღილაკებიანი კომფორტის მოდებში უნდა იყო შერჩევითი.
4. გამოაქვეყნე ის Steam-ის კოლექციად. ყველა გამოიწერს კოლექციას და სხვა არაფერს, ამიტომ განახლებები ყველასთან ერთად მოდის. შეერთების ეკრანის "Subscribe to missing"-ს მაშინ თითქმის არაფერი აქვს გასაკეთებელი.
5. რიგი ფაილად გაგზავნე. RimWorld-ის Mods ეკრანს შეუძლია აქტიური სია შეინახოს .rml ფაილში შენახვის მონაცემების ModLists საქაღალდეში და უკან ჩატვირთოს. გააგზავნე ეს ფაილი და არა ეკრანის ანაბეჭდი.
6. განახლებები გაყინე run-ის დროს. Steam Workshop-ის მოდებს განაახლებს, როცა უნდა. მოდი, რომელიც სამშაბათს ერთ მანქანაზე განახლდა, ოთხშაბათს Files შეუსაბამობაა, ან უარესი - ვერსია, რომელმაც multiplayer-ის მხარდაჭერა ჩუმად დაკარგა. თუ მოდის განახლება კოლონიის შუაში სიას არღვევს, აღდგენის ნაბიჯები რა ვქნათ, როცა მოდის განახლება აფუჭებს პოსტშია, ხოლო Workshop-ის სინქრონიზაციის ზოგადი მექანიკა - Steam Workshop-ის მოდები dedicated სერვერებზე პოსტში.

მოთამაშეებს, რომლებიც Steam-ზე არ არიან, ყველა მოდი ხელით უნდა დააყენონ, ზუსტად იმ ვერსიებით, რაც host-ს აქვს. ეს მუშაობს და Files შეუსაბამობების ყველაზე გავრცელებული წყაროცაა. თუ ერთი მოთამაშე სხვა მაღაზიაშია, მთელი სია ერთსა და იმავე დღეს zip-ში ჩადე და ისინი იქიდან დააყენებინე.

ტესტი გრძელ კოლონიამდე#

მოდების სია, რომელიც იტვირთება, არ ნიშნავს, რომ ის მუშაობს. desync-ები კოდის კონკრეტული გზის გაშვებისას ჩნდება, ზოგი გზა კი - რეიდი, caravan, რიტუალი - შეიძლება პირველი ათი თამაშისშიდა დღის განმავლობაში საერთოდ არ გაეშვას. ერთი საღამო ერთჯერად კოლონიას დაუთმე. ეს მთელი run-ის ყველაზე იაფი საათია.

ტესტი arbiter-ით ჩართულზე გაუშვი. arbiter თამაშის ფონური ასლია, რომელსაც host რეალურ ასლთან ერთად აწარმოებს და რომელიც მხოლოდ desync-ების აღმოსაჩენად და დასაზუსტებლად გამოიყენება; ის host-ის მანქანის რეალურ მეხსიერებასა და CPU-ს ხარჯავს, ამიტომ რეალური კოლონიისთვის ის ისევ გამორთე, თუ host-ის კომპიუტერი ძლიერი არ არის. "Desync traces" პარამეტრი დამატებით stack trace-ებს წერს, რაც desync-ის ანგარიშს გაცილებით სასარგებლოს ხდის, თუმცა ის 32-ბიტიან ან ARM პროცესორებზე, მაგალითად Apple Silicon-ზე, არ მუშაობს.

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

• dev mode-ით გამოიძახე რეიდი და ებრძოლე, ორივე მოთამაშის დრაფტავი pawn-ებით.
• შექმენი caravan, იმოგზაურე და დაბრუნდი. ეწვიე დასახლებას და ივაჭრე.
• გამოიყენე ყველა ახალი gizmo და ღილაკი, რომელსაც მოდები ამატებს, ორივე მოთამაშის მანქანიდან და არა მხოლოდ host-ისა.
• შეცვალე მოდის პარამეტრები თამაშის შუაში, თუ ვინმე ამას რეალური run-ის დროს გააკეთებს (ან შეთანხმდით, რომ არავინ გააკეთებს).
• ჩაატარე რიტუალი და, თუ იყენებთ, თქვენი უახლესი DLC-ის მთავარი მექანიკები - gravship-ები Odyssey-ზე, Anomaly-ის სპეციფიკური მოვლენები Anomaly-ზე.
• შეინახე, გამოდი, ხელახლა ჩატვირთე და ყველა თავიდან შეუერთე.
• ითამაშე ერთი საათი ყველაზე სწრაფი სიჩქარით, რომელსაც ჯგუფი გამოიყენებს, host კი თავის კადრების სიხშირეს უყურებდეს.

თუ რამე დესინქრონიზდა, თამაში ამას გეუბნება და ანგარიშს წერს შენახვის მონაცემების MpDesyncs საქაღალდეში. ამოიღე ყველაზე ბოლოს დამატებული C# მოდი, ან ის, რომლის ფუნქციასაც იყენებდი, როცა ეს მოხდა, და გაიმეორე ეს მოქმედება. როცა დამნაშავეს იპოვი, ხელახლა შეამოწმე მისი ქულა და შენიშვნები, და თუ ის თავსებადად იყო ჩამოთვლილი, Multiplayer-ის გუნდს სწორედ desync-ის ანგარიში სჭირდება.

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

როცა run-ის შუაში დესინქრონიზდება#

გრძელ კოლონიაში desync-ები იშვიათად არის შემთხვევითი. სავარაუდობის დაახლოებითი რიგით:

1. ვინმეს მოდები განახლდა. როცა ისინი ხელახლა შემოდიან, შეადარე Files ჩანართი; თავიდან გამოიწერე ან დააბრუნე.
2. პარამეტრი შეიცვალა. დარწმუნდი, რომ Sync configs ჩართულია და არავის აქვს ლოკალურად რედაქტირებული config.
3. მოდის ფუნქცია, რომელიც არასდროს გატესტილა. ჩაინიშნე, რას აკეთებდა მოთამაშე, როცა ეს გაეშვა.
4. host-ის მანქანა ჩამორჩა. host, რომლის კადრების სიხშირე თამაშის tick-ის სიხშირეზე დაბლა ეცემა, ყველას ბიჯიდან გამოსცემს. ეს მოდის პრობლემა არ არის, თუმცა მოდების მძიმე სია ამას იწვევს; CPU vs RAM თამაშის სერვერებისთვის განმარტავს, რატომ აქვს ერთ ნელ ბირთვს მთლიან მეხსიერებაზე მეტი მნიშვნელობა.
5. ცუდი კავშირი. გუნდის FAQ host-სა და მოთამაშეს შორის ცუდ ხაზს ყველაზე გავრცელებულ მიზეზად ასახელებს. Latency, jitter და packet loss გასწავლის, როგორ გაარჩიო ეს სამი ერთმანეთისგან.

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

რას შეუძლია და რას ვერ შეძლებს ჰოსტინგის გეგმა აქ#

Multiplayer მოდი თითოეული მოთამაშის თამაშის ასლში მუშაობს და სესია host-ის კომპიუტერზე ცოცხლობს. ბოლო რელიზებში დაიწყო მუშაობა standalone სერვერის რეჟიმზე, მაგრამ ის ახალია და ჯგუფების უმეტესობა ჯერ ასე არ თამაშობს; გეგმის შედგენამდე გადაამოწმე პროექტის release notes. ამ სახელმძღვანელოში აღწერილი თავსებადობის არც ერთი სამუშაო სერვერზე არ სრულდება - ის ოთხ კომპიუტერზე სრულდება, რომლებსაც ერთმანეთთან შეთანხმება უწევთ.

თუ შენს ჯგუფს ნამდვილად სურს სამყარო, რომელიც host-ის გამორთვისას განაგრძობს მუშაობას, ეს RimWorld Together-ია, რომელსაც მართლაც აქვს სრულფასოვანი სერვერის პროგრამა. RE:NODE-ის RimWorld-ის გეგმები იწყება 1 GB მეხსიერებით და ერთი port-ის განაწილებით, რაც მისი სერვერისთვის საკმარისია, მოდების სია და configs კი ბრაუზერის ფაილ მენეჯერში ან SFTP-ით რედაქტირდება. გაწყობა RimWorld-ის multiplayer სერვერის გზამკვლევშია.

FAQ#

არის თუ არა RimWorld-ის ყველა მოდი Multiplayer-თან თავსებადი?

არა, მაგრამ უფრო მეტი, ვიდრე უმეტესობა ფიქრობს. XML-ზე დაფუძნებული მოდები ყოველთვის მუშაობს. კოდიანი მოდები მუშაობს, თუ თავიანთ მოქმედებებს სინქრონიზებენ, ან ნატიურად, ან Multiplayer Compatibility მოდით. თითოეულის ქულა შეამოწმე Mods ეკრანის Multiplayer compatibility ფანჯარაში.

მჭირდება თუ არა Multiplayer Compatibility მოდი?

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

ყველას ერთი და იგივე DLC-ები სჭირდება?

დიახ. ყველა მოთამაშეს იგივე DLC-ები უნდა ჰქონდეს ჩართული, რაც host-ს. თუ ერთ მოთამაშეს რომელიმე DLC აკლია, ჯგუფი ან მის გარეშე თამაშობს, ან ეს მოთამაშე ყიდულობს.

სად დგას Multiplayer ჩატვირთვის რიგში?

Prepatcher სულ თავში, შემდეგ Harmony, შემდეგ Core და DLC-ები, შემდეგ Multiplayer უშუალოდ ბოლო DLC-ის ქვემოთ, შემდეგ Multiplayer Compatibility. framework-ები, კონტენტი და პაჩები მოსდევს.

შეიძლება თუ არა მოთამაშეებს განსხვავებული მოდის პარამეტრები ჰქონდეთ?

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

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

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