RimWorld multiplayer სერვერი: მოდები, desync-ები და ჰოსტინგი

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

RimWorld-ის სხვებთან თამაშის ორი გზა#

კითხვა, რომელიც შენს ჯგუფს უნდა დაუსვა, ის არ არის, რომელი მოდია უკეთესი. კითხვა ისაა, გინდათ თუ არა დაჯდეთ და სამი საათი ერთი და იმავე კოლონიით ითამაშოთ, თუ გინდათ სამყარო, რომელიც სამშაბათ შუადღეს ისევ იქაა, როცა ერთი ადამიანი შედის. ეს სხვადასხვა თამაშებია და სხვადასხვა პროგრამა სჭირდება.

თუ პირველი გინდა, Multiplayer მოდი შესანიშნავია და სერვერი საერთოდ არ გჭირდება. თუ მეორე გინდა - და ეს არის ის, რასაც ხალხის უმეტესობა RimWorld სერვერის ჰოსტინგის ძიებისას გულისხმობს - გჭირდება RimWorld Together.

Multiplayer: ერთი კოლონია, lockstep, სერვერის გარეშე#

Multiplayer მოდი, თავდაპირველად Zetrith-ის, ახლა კი rwmt გუნდის მიერ მხარდაჭერილი, თამაშის მდგომარეობას არავის უგზავნის. ყოველი მანქანა, ჰოსტი და კლიენტები ერთნაირად, ერთსა და იმავე RimWorld სიმულაციას უშვებს. ჰოსტი ბრძანებებს ავრცელებს - draft ბრძანება, bill-ის ცვლილება, designation - tick-ის ნომრით მონიშნულს, და ყველა მათ ერთსა და იმავე tick-ზე იყენებს და ერთსა და იმავე სამყაროს აღწევს.

ამ დიზაინს სამი შედეგი აქვს და სანამ დაიწყებ, სამივე უნდა იცოდე.

დედიკირებული სერვერი არ არსებობს. პროექტის საკუთარი პასუხი კითხვაზე, აქვს თუ არა დედიკირებული სერვერის მხარდაჭერა, პირდაპირი და მოკლეა: არა. ჰოსტინგი თამაშის შიგნიდან კეთდება: მთავარი მენიუ, Multiplayer, ახალი ან არსებული save-ის hosting. ჰოსტის RimWorld-ის ასლი ავტორიტეტია. როცა ის თამაშს დახურავს, სესია მთავრდება და არაფერი მიდის წინ, სანამ ის ხელახლა არ გახსნის.

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

Desync-ები არის მარცხის რეჟიმი. როცა ერთი მანქანის სიმულაცია განსხვავდება, მოდი ამას ამჩნევს და გეუბნება. გავრცელებული მიზეზებია: მოდის ფაილების ან პარამეტრების შეუსაბამობა, მოდი, რომელიც შემთხვევითობას იყენებს და მოდი მას ვერ იჭერს, თამაშის შუაში შეცვლილი კონფიგურაცია და - ხშირად უყურადღებოდ დარჩენილი - თავად ჰოსტის მანქანის გაჭირვება, რადგან ჰოსტი, რომლის კადრების სიხშირე სესიის tick rate-ზე დაბლა ეცემა, მთელ თამაშს ნაბიჯიდან გამოაგდებს. მოდი desync-ის ანგარიშს ავტომატურად წერს MpDesyncs საქაღალდეში და სწორედ ეს ფაილია, რაც მოდის ავტორს მიზეზის გასასწორებლად სჭირდება.

პირდაპირი კავშირებისთვის მოდი UDP 30502-ს უსმენს. Steam-ზე დაფუძნებული ჰოსტინგი Steam-ის ქსელის გავლით მიდის და საერთოდ არანაირი პორტის გახსნა არ სჭირდება, სწორედ ამიტომ პატარა ჯგუფები როუტერს არასოდეს ეხებიან.

შეიძლება თუ არა Multiplayer-ის სერვერზე გაშვება?#

არა ისე, როგორც Minecraft სერვერს უშვებ. არ არის headless build, არ არის კონსოლი, არ არის კონფიგურაციის ფაილი, არ არის RCON. RimWorld Unity თამაშია მომხმარებლის ინტერფეისით და Multiplayer მოდის host რეჟიმი მენიუა, რომელზეც აჭერ.

ორი გვერდის ავლით გზა არსებობს და ორივე უარესია, ვიდრე ჟღერს. შეგიძლია RimWorld-ის სრული ინსტალაცია VDS-ზე virtual framebuffer-ის ქვეშ გაუშვა და ეს მანქანა მუდმივ ჰოსტად გამოიყენო - მუშაობს, მაგრამ იმ მანქანაზე უსაქმოდ მდგარი თამაშის ლიცენზია სჭირდება, დესკტოპის ზომის მანქანა სჭირდება, რადგან ჰოსტი სრულ თამაშს რენდერინგით უშვებს, და ყოველი გადატვირთვა ხელით დაწკაპუნებაა. ან შეგიძლია შეეგუო, რომ ერთი ადამიანი ჰოსტია და ყველა მაშინ თამაშობს, როცა ონლაინაა, რასაც თითქმის ყველა აკეთებს. Choosing between a VDS and a game panel ამ კომპრომისის პატიოსანი ვერსიაა; ამ კონკრეტულ შემთხვევაში პანელი ვერაფერს გიშველის, რადგან გასაშვები სერვერის მსგავსი არაფერია.

მოდს ასევე მოჰყვება arbiter: თამაშის მეორე, თითქმის headless ეგზემპლარი, რომელიც ჰოსტთან ერთად ეშვება მხოლოდ სიმულაციის გადასამოწმებლად და იმის დასადგენად, ვინ დაშორდა. ეს გამართვის დამხმარეა და არა სერვერი. ის ჰოსტის მანქანას რეალურ CPU-სა და მეხსიერებას ართმევს და კოლონიას არ ინახავს ცოცხალს, როცა ისინი გავლენ.

RimWorld Together: ცალკე კოლონიები, ნამდვილი სერვერი#

RimWorld Together საპირისპირო მიდგომას იყენებს. სერვერი RimWorld-ს საერთოდ არ სიმულირებს. ის პატარა .NET კონსოლის პროგრამაა, რომელიც ინახავს პლანეტას, ყველას დასახლებებს, მათ save-ებს, ბაზარს და მოვლენების რიგს, და მოთამაშეებს შორის მოქმედებებს გადასცემს. ყოველი მოთამაშე საკუთარ კოლონიას საკუთარი ტემპით საკუთარ მანქანაზე უშვებს, და საერთო ფენა სამყაროს რუკაა: ქარავნები, ერთმანეთზე თავდასხმები, ვაჭრობა, საჩუქრები, გილდიები და საიტები.

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

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

სერვერის დაყენება და გაშვება#

ჩამოტვირთე სერვერის ფაილები პროექტის releases-იდან და გახსენი ისეთ ადგილას, სადაც ოპერაციული სისტემა უფლებებზე არ გეჩხუბება. შემდეგ გაუშვი შესრულებადი ფაილი. installer არ არის და build ნაბიჯი არ არის.

$ mkdir -p /opt/rwt && cd /opt/rwt$ unzip ~/Downloads/rimworld-together-server.zip$ ./RimworldTogether

ასევე არსებობს ოფიციალური container image, რომელიც საკუთარ Linux მანქანაზე გასაშვებად უფრო მოწესრიგებული გზაა:

$ mkdir -p RWTData$ docker run -it --rm -v './RWTData:/Data' -p 25555:25555 \    ghcr.io/rimworld-together/rimworld-together:latest

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

/opt/rwt/  Configs/        ServerConfig.json and the rest  Configs/Actions/  per-action tuning, one file each  Assets/         Maps, Users, Saves, Settlements, Sites, Guilds, WorldObjects  Backups/        Servers and Users  Logs/           System and Chat

ერთი პორტი, და ის ერთი და იგივეა კონფიგურაციაში, container-ის მიბმაში და კლიენტის დაკავშირების დიალოგში. თუ მოთამაშეებს connection refused ეწერებათ, შესამოწმებელი თანმიმდევრობაა: მუშაობს თუ არა პროცესი, გამოყოფილია თუ არა პორტი, სწორ მისამართზე არის თუ არა კლიენტი მიმართული. Game server ports explained ხსნის, რატომ არის „სერვერი ჩართულია" და „პორტი მისაწვდომია" ორი ცალკე მტკიცება.

RE:NODE-ის RimWorld ხაზი ზუსტად ამ ფორმის სერვერია - მუდმივი multiplayer კოლონია მოდებით - და ყოველ გეგმას ერთი პორტის გამოყოფა მოჰყვება, რაც ამას სჭირდება. კონფიგურაციები და მოდების სია ბრაუზერის ფაილ მენეჯერში ან SFTP-ით რედაქტირდება; SFTP and the file manager შეიცავს კავშირის დეტალებს.

ServerConfig.json და Configs საქაღალდე#

მთავარი ფაილია Configs/ServerConfig.json. ეს არის ნაგულისხმევი მნიშვნელობები, რომლებსაც სერვერი წერს:

{  "Name": "RimWorld Together Server",  "Description": "",  "DiscordURL": "",  "SteamWorkshopURL": "",  "IP": "0.0.0.0",  "Port": 25555,  "MaxPlayers": 100,  "Verbosity": 0,  "DisplayChatInConsole": false,  "UseUPnP": false,  "UseClientSave": true,  "EnableServerBrowser": true,  "EnableServerTelemetry": true}

საქაღალდის დანარჩენი ნაწილი დანიშნულებით იყოფა და ყოველი ფაილი ნაგულისხმევი მნიშვნელობებით იწერება, რომ ფორმა წაიკითხო, სანამ რამეს შეცვლი: ModConfig.json მოდების სიისთვის, DifficultyConfig.json, StorytellerConfig.json და ScenarioConfig.json იმისთვის, რითაც ახალი კოლონია იწყება, ChatConfig.json, PasswordConfig.json, WhitelistConfig.json, BackupConfig.json და Configs/Actions დირექტორია ყოველი ურთიერთქმედებისთვის ერთი ფაილით - თავდასხმები, ქარავნები, ვაჭრობა, საიტები, მოვლენები, ბაზარი, გილდიები - რომ თითოეულს ცალ-ცალკე შეაფასო ან გამორთო.

Backup-ებს საკუთარი ფაილი და გონივრული ნაგულისხმევი მნიშვნელობები აქვს:

{  "AutomaticBackups": true,  "IntervalHours": 1,  "AutomaticDeletion": true,  "Amount": 6}

საათობრივად, ექვსი ინახება, უძველესი იშლება. ეს კარგი როტაციაა და მაინც backup არ არის, რადგან ის იმავე დისკზეა, რასაც იცავს. გადააკოპირე სერვერის მთელი დირექტორია სადმე სხვაგან გრაფიკით - backups that actually restore ამ არგუმენტს აღწერს, ხოლო RE:NODE-ზე ყოველ გეგმაში შემავალი backup ადგილები მანქანის გარეთ ინახება და ღილაკით აღდგება.

მოდები: სია, რომელსაც ყველა იზიარებს#

Configs/ModConfig.json არის ადგილი, სადაც სერვერი თავის მოდების პოლიტიკას აცხადებს, სამ სიაში: სავალდებულო მოდები, არჩევითი მოდები და აკრძალული მოდები. შემომავალ კლიენტს მათ წინააღმდეგ ამოწმებენ. სავალდებულო მოდები უნდა იყოს, აკრძალული მოდები კავშირს კრძალავს, არჩევითები კი ორივე შემთხვევაში დასაშვებია - ეს მნიშვნელოვანი განსხვავებაა Multiplayer მოდისგან, სადაც არჩევითი მოდის ცნება არ არსებობს.

პრაქტიკული წესები საერთო მოდების სიისთვის, ნებისმიერ მოდზე:

1. შეთანხმდით სიაზე პირველ დღემდე. კონტენტ მოდის დამატება სამყაროში, სადაც კოლონიები უკვე არის, ნიშნავს, რომ ყველა მოთამაშე თავიდან სინქრონდება და ზოგიერთი რაღაცას კარგავს. ამოღება უარესია.
2. გამოიყენე Steam collection. გამოაქვეყნე ერთი კოლექცია, ჩასვი მისი ბმული SteamWorkshopURL-ში და უთხარი ხალხს, რომ გამოიწერონ ის და სხვა არაფერი. კოლექცია ერთადერთი მოდების სიაა, რომელიც თავისით რჩება სინქრონში.
3. დააფიქსირე ჩატვირთვის რიგი. RimWorld რიგის მიმართ არაჩვეულებრივად მგრძნობიარეა. თამაშიდან გამოიტანე მუშა მოდების სია და გააგზავნე ფაილი და არა ეკრანის სურათი.
4. მოერიდე მოდებს, რომლებიც სამყაროს სხვანაირად აგენერირებს, თუ ყველას არ აქვს, და შესრულების მოდები სიის ნაწილად მიიჩნიე და არა პირად არჩევანად.
5. კვირის შუაში ნუ განაახლებ. workshop მოდი, რომელიც ერთ მოთამაშეს განახლდა და მეორეს არა, ორშაბათი საღამოს გამართვაში გატარების ყველაზე ხშირი მიზეზია. What to do when a mod update breaks შეიცავს აღდგენის ვარჯიშს.

სერვერის ბრძანებები, ადმინები და backup-ები#

სერვერი ბრძანებებს თავისი კონსოლიდან კითხულობს, რაც პანელზე კონსოლის ყუთია. ცალკე დისტანციური პროტოკოლი არ არის; კონსოლი admin ინტერფეისია.

რადგან admin ინტერფეისი კონსოლია, კონსოლზე წვდომა ვის აქვს, ფორმალობა კი არა, რეალური უსაფრთხოების საკითხია. RE:NODE-ზე ამისთვის არსებობს subuser-ები და როლები: როლი შეიძლება იყოს მხოლოდ კონსოლი ან მხოლოდ ფაილები, ბილინგის გარეშე, და ყოველი მოქმედება ჩაიწერება თითო სერვერის activity ლოგში. Subusers and least privilege გვიჩვენებს, როგორ გაანაწილო ეს გონივრულად.

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

შეამჩნიე მესამე რიგი. თუ ვინმე „RimWorld Multiplayer დედიკირებულ სერვერს" Zetrith-ის მოდით გთავაზობს ფასად, ჰკითხე, რას უშვებს სინამდვილეში, რადგან მანქანა, რომელსაც ამ სესიის ჰოსტინგი შეუძლია, გრაფიკული გარემოს მქონე დესკტოპის კლასის მანქანაა და არა $5 გეგმა.

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

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

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

სამყარო დისკზე უზარმაზარია. მოთამაშეების save-ები და საათობრივი backup-ები გროვდება. შეამცირე Amount BackupConfig.json-ში, ან ძველი backup-ები სერვერიდან გადაიტანე.

სერვერი ჩერდება, როცა ტერმინალს ხურავ. გაუშვი ის სერვისად, ან პანელში, სადაც პროცესების ზედამხედველობა სხვისი პრობლემაა. crash loop, რომელიც სინამდვილეში მეხსიერების ლიმიტია და არა კონფიგურაციის შეცდომა, განხილულია აქ: why your game server keeps restarting.

FAQ#

აქვს RimWorld-ს ოფიციალური multiplayer?

არა. Ludeon-ს multiplayer არასოდეს გამოუშვია, და ორივე ვარიანტი სხვადასხვა დიზაინის საზოგადოებრივი მოდებია. ყველაფერი, რაც ოფიციალურ RimWorld multiplayer-ს რეკლამირებს, ერთ-ერთ ამ მოდს აღწერს.

შემიძლია Multiplayer მოდი ჰოსტინგ გეგმაზე გავუშვა?

არა. მას არ აქვს დედიკირებული სერვერის build, არ აქვს headless რეჟიმი და არ აქვს კონსოლი; ჰოსტინგი თამაშის შიგნით ღილაკია. მისი უყურადღებოდ გაშვების ერთადერთი გზა RimWorld-ის სრული ინსტალაციაა შენ მიერ კონტროლირებად მანქანაზე, გრაფიკული გარემოთი, რაც სულ სხვა შენაძენია.

რამდენი ადამიანი შეიძლება ითამაშოს ერთ RimWorld Together სერვერზე?

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

ყველა მოთამაშეს ერთი და იგივე მოდები სჭირდება?

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

რატომ ვდესინქრონდებით ყოველ თავდასხმაზე?

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

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

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