SteamCMD Windows-ზე: ინსტალაცია, სკრიპტები და განახლებები

SteamCMD Windows-ზე ერთი zip ფაილია: ჩამოტვირთე Valve-ისგან steamcmd.zip, გახსენი მოკლე მისამართის მქონე საქაღალდეში, მაგალითად C:\steamcmd, და ერთხელ გაუშვი steamcmd.exe პარამეტრით +quit, რომ თავი განაახლოს. ამის შემდეგ ყოველი სერვერის ინსტალაცია ერთი და იგივე ხაზია - +force_install_dir აბსოლუტური მისამართით, +login anonymous, +app_update <id> validate, +quit - რომელსაც სკრიპტის ფაილში გადაიტან, batch ფაილიდან გამოიძახებ და უყურადღებოდ განახლებისთვის Task Scheduler-ს გადასცემ. Windows-ზე პრობლემები სწორედ სპეციფიკურ ადგილებში ჩნდება: მისამართები ინტერვალებით, საქაღალდეები Program Files-ში ან შენს პროფილში, დაგეგმილი ამოცანა, რომელიც სხვა მომხმარებლით სრულდება, ვიდრე ის, რომლითაც ტესტირება ჩაატარე, და Defender, რომელიც ყოველი განახლებისას ათასობით პატარა ფაილს ამოწმებს. ეს სტატია სწორედ ამ ადგილებს ეხება. თავად არგუმენტები, შეცდომების ცხრილი და app id-ების მუშაობა აღწერილია სტატიაში SteamCMD explained, ხოლო ბრანჩების გადართვა - სტატიაში SteamCMD app IDs and beta branches.

SteamCMD-ის ჩამოტვირთვა და პირველი გაშვება#

ინსტალატორი არ არსებობს და Start მენიუში არაფრის დამატებაა საჭირო. Valve აქვეყნებს zip-ს ერთი პატარა გამშვები ფაილით, ეს ფაილი კი დანარჩენს თავად ჩამოტვირთავს.

1. შექმენი მისთვის საქაღალდე. ჩვეულებრივ ეს C:\steamcmd-ია და მოკლე მისამართი მოგვიანებით მნიშვნელოვანი აღმოჩნდება.
2. ჩამოტვირთე https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip და steamcmd.exe ამ საქაღალდეში ამოალაგე.
3. გახსენი Command Prompt ან PowerShell, გადადი საქაღალდეში და გაუშვი steamcmd.exe +quit.

იგივე სამი ნაბიჯი ჩვეულებრივი (არა ადმინისტრატორის) PowerShell-ის ფანჯრიდან:

PS> New-Item -ItemType Directory -Path C:\steamcmdPS> Invoke-WebRequest -Uri https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip `      -OutFile C:\steamcmd\steamcmd.zipPS> Expand-Archive C:\steamcmd\steamcmd.zip -DestinationPath C:\steamcmdPS> C:\steamcmd\steamcmd.exe +quit

პირველი გაშვება თვითგანახლებაა. SteamCMD აცხადებს, რომ განახლებებს ამოწმებს, ჩამოტვირთავს თავის პაკეტებს, ამოალაგებს მათ და თავად თავს თავიდან უშვებს, სანამ Loading Steam API...OK-მდე და ბრძანების შეტანის ველამდე მივა. ჩვეულებრივი კავშირის დროს ამას ერთი-ორი წუთი სჭირდება. ზუსტი სტრიქონები ვერსიიდან ვერსიამდე იცვლება, მაგრამ დაახლოებით ასე გამოიყურება:

[  0%] Checking for available updates...[----] Downloading update (...)[----] Extracting package...[----] Installing update...[----] Cleaning up...[----] Update complete, launching Steamcmd...Loading Steam API...OK

დაამთავრებინე. პირველი გაშვების შეწყვეტა - ფანჯრის დახურვა ან დაგეგმილი ამოცანა, რომელსაც დრო გაუვიდა - ტოვებს ნახევრად ამოლაგებულ კლიენტს, რომელიც შემდეგ გაშვებაზე გაუგებარი სახით ფუჭდება. თუ ასე მოხდა, წაშალე საქაღალდეში ყველაფერი steamcmd.exe-ის გარდა და ისევ გაუშვი +quit. ეს არის სტანდარტული გამოსწორება იმ SteamCMD-ისთვისაც, რომელიც თვეების მუშაობის შემდეგ გაშვებისთანავე ვარდება: გამშვები ფაილი, რაც სჭირდება, თავიდან აღადგენს, ამ ფაილებში კი შენთვის მნიშვნელოვანი არაფერი ინახება, თუ სერვერებს ნაგულისხმევ ადგილას არ აყენებდი (იხილე შემდეგი თავი).

SteamCMD საკუთარ განახლებებს ყოველ გაშვებაზე ამოწმებს და არა მხოლოდ პირველზე. როცა Valve-მა ახალი კლიენტი გამოუშვა, შენი შემდეგი სკრიპტული განახლება პირველ წუთს თავად SteamCMD-ის განახლებაში გაატარებს და მხოლოდ შემდეგ შეეხება თამაშს. timeout-ები ამის გათვალისწინებით დაგეგმე.

Runtime-ები, რომლებიც სერვერს დასჭირდება

თავად SteamCMD-ს დამატებითი არაფერი სჭირდება. სერვერებს, რომლებსაც მასთან ჩამოტვირთავ, ხშირად სჭირდება. ბევრი Windows სერვერი Microsoft Visual C++ Redistributable-ზეა აგებული და მისი არარსებობა ისე ჩანს, რომ სერვერი არ ირთვება და შეტყობინებაში რომელიმე DLL, მაგალითად VCRUNTIME140.dll ან MSVCP140.dll სახელდება. ზოგიერთ ძველ ან Unreal-ზე დაფუძნებულ სერვერს DirectX runtime-ის ნაწილებიც სჭირდება. ეს თამაშის მოთხოვნებია და არა SteamCMD-ის, ამიტომ გადაამოწმე თამაშის სერვერის დოკუმენტაცია. პირველ სერვერამდე Microsoft-ისგან Visual C++ Redistributable-ის მიმდინარე x64 ვერსიის დაყენება გონივრული ნაგულისხმევია სუფთა Windows Server მანქანაზე, რომელსაც არ მოჰყვება ის, რაც სამუშაო კომპიუტერმა წლების განმავლობაში თამაშებისგან დააგროვა.

სად რა ხვდება: საქაღალდეების სტრუქტურა#

პირველი გაშვების შემდეგ C:\steamcmd-ში რამდენიმე ათეული ფაილი და საქაღალდეა. ცოდნის ღირსი ნაწილი:

ამ ორ ფაილზე ცალკე უნდა ვთქვათ. config\config.vdf არის ადგილი, სადაც SteamCMD ინახავს შენახულ ავტორიზაციას მას შემდეგ, რაც რეალური ანგარიშით შესვლამ Steam Guard გაიარა. ანონიმური ინსტალაციებისთვის ეს არ აქვს მნიშვნელობა; Arma 3-სა და DayZ-ისთვის კი სწორედ ეს ფაილი ხდის შესაძლებელს უყურადღებო განახლებებს და პაროლივით უნდა მოექცე. logs\content_log.txt ჩანიშნავს ყოველ ჩამოტვირთვას, მდგომარეობის ცვლილებასა და შეცდომას დროის ნიშნულით. როცა განახლება ღამით ჩავარდა და batch ფაილის საკუთარ ლოგში სასარგებლო არაფერია, წასაკითხი სწორედ ეს ფაილია.

თუ +force_install_dir არასდროს დაგიყენებია, სერვერები C:\steamcmd\steamapps\common\<AppName>-ში ხვდება. ერთი სერვერისთვის ეს მუშაობს, რამდენიმესთვის კი მოუხერხებელი ხდება: თამაშის ფაილები ხელსაწყოს საქაღალდეშია, SteamCMD-ის გამოსწორებისას მათ გვერდის ავლა უწევს, "სერვერის" backup-ში კი შემთხვევით კლიენტიც მოხვდება. ის სტრუქტურა, რომელსაც მართვა არ უჭირს, SteamCMD-ს, სერვერებსა და სკრიპტებს ერთმანეთისგან ცალკე ინახავს:

C:\steamcmd\                 SteamCMD onlyC:\servers\valheim\          one folder per server installC:\servers\satisfactory\C:\servers\scripts\          .txt runscripts, .cmd files, logs

ძირითადი საქაღალდე მოკლე და ინტერვალების გარეშე იყოს. Windows-ს ბევრი პროგრამისთვის ისევ აქვს 260 სიმბოლოს ლიმიტი მისამართზე, თუ გრძელი მისამართები პოლიტიკით არ ჩაირთო და პროგრამამ ამაზე თანხმობა არ განაცხადა, თამაშის სერვერები კი ამ პროგრამებს შორის სანდოდ არ არიან. Workshop-ის ელემენტი, რომელიც C:\Users\Administrator\Documents\Game Servers\...-ში რამდენიმე საქაღალდის სიღრმეშია, ამ ლიმიტს გასაკვირად უახლოვდება.

განსაკუთრებით ეს სამი ადგილი აარიდე:

• `C:\Program Files` და `C:\Program Files (x86)`. იქ ჩაწერას ელევაცია სჭირდება, ამიტომ ან ყოველი განახლება ადმინისტრატორის სახელით უნდა გაეშვას, ან განახლება გზაში უფლებების შეცდომით ჩავარდება.
• შენი მომხმარებლის პროფილი, მათ შორის Desktop, Documents და Downloads. სხვა ანგარიშით გაშვებული დაგეგმილი ამოცანა მას ვერ ხედავს, Defender-ის Controlled folder access კი, თუ ჩართულია, უცნობ პროგრამებს ამ საქაღალდეებში ჩაწერას უკრძალავს.
• OneDrive-ით სინქრონიზებული საქაღალდე. სინქრონიზაციის კლიენტები ფაილებს ბლოკავენ და ტვირთავენ მაშინ, როცა SteamCMD მათ ცვლის, თამაშის სერვერი კი, რომელიც სამყაროს რამდენიმე წუთში ერთხელ წერს, მუდმივ სინქრონიზაციის ტრაფიკად იქცევა.

ყოველ სერვერის ინსტალაციას თავისი steamapps\appmanifest_<appid>.acf აქვს, სადაც დაყენებული build id წერია. ამ ფაილით ხვდები, რომელ ვერსიაზეა სერვერი; SteamCMD explained მას დაწვრილებით განიხილავს.

force_install_dir Windows-ზე#

+force_install_dir აბსოლუტურ მისამართს იღებს და Windows-ზე დეტალები მისამართებსა და ბრჭყალებშია.

C:\steamcmd\steamcmd.exe +force_install_dir C:\servers\valheim +login anonymous ^    +app_update 896660 validate +quit

^ არის ხაზის გაგრძელების სიმბოლო Command Prompt-სა და batch ფაილებში. PowerShell-ში გაგრძელების სიმბოლო backtick-ია და ორივე შემთხვევაში უფრო უსაფრთხოა მთელი ბრძანება ერთ ხაზზე შეინახო, სანამ არ იმუშავებს.

რიგითობას მნიშვნელობა აქვს. SteamCMD-ის ახალი build-ები ბეჭდავენ გაფრთხილებას, დაახლოებით "Please use force_install_dir before logon!", თუ +login პირველია, და ვერსიიდან გამომდინარე, საქაღალდე უგულებელყოფილია და ფაილები ნაგულისხმევ ადგილას მიდის. პირველი დააყენე +force_install_dir, შემდეგ +login, შემდეგ +app_update. იგივე რიგითობა მოქმედებს სკრიპტის ფაილებშიც.

თუ მისამართში ინტერვალია, ჩასვი ბრჭყალებში: +force_install_dir "C:\Game Servers\valheim". ბრჭყალები მუშაობს, მაგრამ batch ფაილებში კიდევ ერთი ადგილია შეცდომისთვის, სადაც ბრჭყალებიანი მისამართის მქონე ცვლადი გამოყენებისას ბრჭყალების მეორე წყვილს იღებს. უფრო მარტივი გამოსავალია მისამართი ინტერვალების გარეშე.

ფარდობითი მისამართები არ გამოიყენო. ფარდობითი საქაღალდე SteamCMD-ის საკუთარი საქაღალდის მიმართ განისაზღვრება და არა იმის მიმართ, სადაც შენი batch ფაილი ან shell არის, ამიტომ +force_install_dir ..\valheim სხვადასხვა ადგილას ხვდება იმის მიხედვით, სად დგას SteamCMD. ქსელური დისკიც ცუდი მიზანია: დისკის ასოები თითოეული შესვლის სესიისთვის ცალკეა, ამიტომ შენს სამუშაო სესიაში მიერთებული დისკი დაგეგმილი ამოცანისთვის არ არსებობს, SteamCMD SMB-ზე კი ნელი და მყიფეა, როცა არსებობს.

ერთ SteamCMD საქაღალდეს სერვერის ნებისმიერი რაოდენობის ინსტალაციის მართვა შეუძლია, რადგან თითოეული ცალკე force_install_dir-ია. რაც არ უნდა გააკეთოს, ისაა, რომ ერთდროულად ორჯერ არ უნდა გაეშვას. ორი ეგზემპლარი package\-ს, config\-სა და თვითგანახლებას იზიარებს, მეორე გაშვება კი მაშინ, როცა პირველი თავს აახლებს, კლიენტის დაზიანების საიმედო გზაა. თუ რამდენიმე სერვერი განრიგით ახლდება, განაახლე ისინი ერთმანეთის მიყოლებით ერთ სკრიპტში ან ამოცანები იმდენი ხნით დააშორე, რამდენიც თითოეულს დასასრულებლად სჭირდება.

სკრიპტის ფაილები და +runscript#

batch ფაილში გრძელი ბრძანება პრობლემად იქცევა პირველივე ჯერზე, როცა ერთი არგუმენტი ექვს ადგილას უნდა შეცვალო. SteamCMD ბრძანებებს ტექსტური ფაილიდანაც კითხულობს, თითო ხაზზე ერთს, + პრეფიქსის გარეშე:

// Valheim dedicated server, app 896660@ShutdownOnFailedCommand 1@NoPromptForPassword 1force_install_dir C:\servers\valheimlogin anonymousapp_update 896660quit

C:\steamcmd\steamcmd.exe +runscript C:\servers\scripts\update-valheim.txt

//-ით დაწყებული ხაზები კომენტარებია. ორი @ ხაზი პარამეტრებია: @ShutdownOnFailedCommand 1 პირველივე ჩავარდნილ ბრძანებაზე ჩერდება და quit-მდე არ გრძელდება, @NoPromptForPassword 1 კი უყურადღებოდ გაშვებულ პროცესს უსასრულოდ არ ტოვებს პაროლის მოთხოვნაზე, რომელსაც არავინ უპასუხებს. ორივე უნდა იყოს ყველა სკრიპტში, რომელიც შენს თვალწინ არ სრულდება. სკრიპტი აბსოლუტური მისამართით გადაეცი, იმავე მიზეზით, რაც force_install_dir-ს.

შეამჩნიე, რა არ არის ამ სკრიპტში: validate. რუტინული განახლება მხოლოდ შეცვლილ ნაწილებს იღებს; validate მთელ ინსტალაციას კითხულობს და ჰეშავს და ნებისმიერ ფაილს, რომელიც შენ შეცვალე, ანაცვლებს. გაშვებული ფაილების შესაკეთებლად გქონდეს მეორე სკრიპტი validate-ით და ხელით გაუშვი, როცა დაგჭირდება. მსჯელობა აღწერილია სტატიაში automating game server updates safely.

სკრიპტის ფაილში ერთზე მეტი აპლიკაციის ჩასმაც შეიძლება. ერთ login-ს რამდენიმე force_install_dir და app_update წყვილი შეიძლება მოჰყვეს, რაც განახლებებს თანმიმდევრულად ასრულებს SteamCMD-ის ერთი გაშვებისას და ზემოთ აღწერილ ორი ეგზემპლარის პრობლემას გვერდს უვლის:

@ShutdownOnFailedCommand 1@NoPromptForPassword 1login anonymousforce_install_dir C:\servers\valheimapp_update 896660force_install_dir C:\servers\satisfactoryapp_update 1690800quit

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

batch ფაილი, რომელიც აჩერებს, ანახლებს და ამოწმებს#

SteamCMD ვერ ცვლის ფაილებს, რომლებსაც გაშვებული სერვერი ღიად ინახავს. გაშვებული სერვერის განახლება ან file-in-use შეცდომით სრულდება, ან, უარესი, ნახევრად გამოდის და ისეთ ინსტალაციას ტოვებს, რომელიც შემდეგ გაშვებაზე ვარდება. ამიტომ wrapper-ის დანიშნულებაა: სერვერის სუფთად გაჩერება, განახლება, შედეგის შემოწმება, სერვერის გაშვება.

ეს მაგალითი ვარაუდობს, რომ სერვერი Windows service-ად მუშაობს სახელით Valheim (ამისთვის ჩვეულებრივ NSSM გამოიყენება - Valheim on Windows guide მას სწორი Ctrl+C გაჩერებით აყენებს, რომ სამყარო შეინახოს). net stop დაბრუნებამდე ელოდება სერვისის გაჩერებას, რაც სწორედ გჭირდება.

@echo offsetlocalcd /d "%~dp0"set LOG=%~dp0update-valheim.logecho ==== %DATE% %TIME% ==== >> "%LOG%"net stop Valheim >> "%LOG%" 2>&1C:\steamcmd\steamcmd.exe +runscript "%~dp0update-valheim.txt" > "%~dp0last-run.log" 2>&1type "%~dp0last-run.log" >> "%LOG%"findstr /C:"Success! App '896660'" "%~dp0last-run.log" >nulif errorlevel 1 (    echo UPDATE FAILED - server left stopped >> "%LOG%"    exit /b 1)net start Valheim >> "%LOG%" 2>&1exit /b 0

რამდენიმე ხაზს ახსნა სჭირდება.

• cd /d "%~dp0" გადადის საქაღალდეში, სადაც batch ფაილია. %~dp0 ამ საქაღალდედ იშლება ბოლოში უკუსლეშით. Task Scheduler ამოცანებს C:\Windows\System32-ში იწყებს, თუ სხვაგვარად არ უთხარი, და ნებისმიერი ფარდობითი მისამართი სკრიპტში, რომელიც "ორმაგი დაწკაპუნებით მუშაობდა", იქ ირღვევა.
• წარმატების შემოწმება SteamCMD-ის გამოტანას კითხულობს და არა მის exit code-ს. exit code ვერსიების მიხედვით სანდო სიგნალი არ ყოფილა და ჩავარდნილი ჩამოტვირთვა შეიძლება ისეთი კოდით დასრულდეს, რომელიც ნორმალურად გამოიყურება. სტრიქონი, რომელსაც SteamCMD წარმატებული განახლების ან ინსტალაციის შემდეგ ბეჭდავს, არის Success! App '<id>' fully installed., ხოლო როცა უკვე განახლებულია, ბეჭდავს Success! App '<id>' already up to date. საერთო პრეფიქსით შედარება ორივეს იღებს.
• ჩავარდნისას სკრიპტი სერვერს გაჩერებულს ტოვებს. ეს არჩევანია. სერვერის გაშვება ნახევრად განახლებულ ინსტალაციაზე სამყაროს დაზიანების რისკს შეიცავს; გაჩერებული დატოვება კი ნიშნავს, რომ მოთამაშეები შეამჩნევენ და ვინმე შეამოწმებს. სერვერისთვის, რომლისთვისაც გაჩერება რისკზე უარესია, ეს ტოტი შეცვალე, რომ სერვისი მაინც გაეშვას, შეტყობინება კი სხვა გზით მიიღო.
• %DATE% და %TIME% სისტემის ლოკალით ფორმატდება, ამიტომ მათგან ფაილის სახელები არ ააგო; ფორმატი მანქანებს შორის იცვლება. თუ გინდა თითო გაშვებაზე ერთი ლოგის ფაილი, დროის ნიშნული PowerShell-იდან აიღე ბრძანებით Get-Date -Format yyyyMMdd-HHmm.

თუ სერვერი service კი არა, batch ფაილიდან გაშვებული კონსოლის ფანჯარაა, სკრიპტისთვის მისი სუფთად გაჩერების გზა არ არსებობს. ფანჯრის დახურვა ან taskkill /F პროცესს შენახვის საშუალების გარეშე წყვეტს. თამაშის სერვერები service-ებად გაუშვი, თუ უყურადღებოდ განახლებას აპირებ; ეს ერთადერთი სქემაა, სადაც "გაჩერება" სუფთა გაჩერებას ნიშნავს.

დაგეგმილი განახლებები Task Scheduler-ით#

Task Scheduler Windows-ის cron-ია. მისი მართვა შეიძლება GUI-დან (taskschd.msc) ან ბრძანების ხაზიდან schtasks-ით, რომლის აღწერა და გამეორება უფრო მარტივია.

schtasks /Create /TN "Servers\Update Valheim" ^    /TR "C:\servers\scripts\update-valheim.cmd" ^    /SC WEEKLY /D MON /ST 05:00 /RU SYSTEM /RL HIGHEST

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

schtasks /Run /TN "Servers\Update Valheim"schtasks /Query /TN "Servers\Update Valheim" /V /FO LIST

Last Result: 0 ნიშნავს, რომ batch ფაილი 0-ით დასრულდა, რაც ზემოთ მოცემულ სკრიპტში იმას ნიშნავს, რომ წარმატების სტრიქონი ნაპოვნია. 1 ნიშნავს, რომ სკრიპტის საკუთარი ჩავარდნის ტოტი შესრულდა. ნებისმიერი სხვა რამ - დიდი თექვსმეტობითი რიცხვი - ჩვეულებრივ ნიშნავს, რომ ამოცანა სკრიპტის გაშვებამდეც კი ვერ მივიდა: არასწორი მისამართი /TR-ში ან ანგარიში, რომელსაც საქაღალდის უფლება არ აქვს.

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

SYSTEM ყველაზე მარტივია: შეუძლია service-ების გაჩერება და გაშვება და ყველგან ჩაწერა. ის ასევე მანქანის ყველაზე ძლიერი ანგარიშია, ამიტომ სკრიპტი, რომელსაც ის უშვებს, საქაღალდეში უნდა იდოს, სადაც მხოლოდ ადმინისტრატორებს შეუძლიათ ჩაწერა. სერვერებისთვის, რომლებსაც რეალური Steam ანგარიში სჭირდება (Arma 3, DayZ), უფრო სუფთაა ცალკე ლოკალური მომხმარებელი. შედი ერთხელ ამ მომხმარებლით, გაუშვი SteamCMD ხელით Steam Guard-ის გასავლელად და config\config.vdf-ში შენახული ავტორიზაცია დაგეგმილ ამოცანას შემდგომში შეკითხვის გარეშე შესვლის საშუალებას მისცემს. ამ მომხმარებელს სჭირდება Modify უფლებები C:\steamcmd-სა და C:\servers-ზე, "Log on as a batch job" უფლება (ავტომატურად გაიცემა, როცა ამოცანას პაროლით ინახავ) და service-ის მართვის უფლება, თუ სკრიპტი მას აჩერებს და უშვებს.

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

• Run whether user is logged on or not. წინააღმდეგ შემთხვევაში ამოცანა მხოლოდ მაშინ სრულდება, როცა ვინმე კონსოლზეა შესული.
• Stop the task if it runs longer than გონივრული დრო, მაგალითად ორი საათი. ნაგულისხმევია სამი დღე, რაც გაჭედილ SteamCMD-ს დიდხანს მალავს.
• Do not start a new instance, თუ ამოცანა უკვე მუშაობს. ეს ნაგულისხმევია და SteamCMD-ის ორი გაშვების გადაფარვას ხელს უშლის.
• Run task as soon as possible after a scheduled start is missed. გამოსადეგია, თუ მანქანა 05:00-ზე Windows-ის განახლებისთვის თავიდან იტვირთებოდა - თუმცა კვირეული სერვერის განახლების Patch Tuesday-სთან დამთხვევა თავიდანვე ასარიდებელია.

რამდენად ხშირად გაუშვა, სერვერზეა დამოკიდებული. ვანილის სერვერი შეიძლება კვირაში ერთხელ ან ყოველ გადატვირთვაზე განახლდეს; მოდიფიცირებულმა სერვერმა კი თამაშის პატჩის დღეს საერთოდ არ უნდა განაახლოს თავი, რადგან განახლება მოდებს ამტვრევს, სანამ მათი ავტორები არ დაეწევიან. აღდგენა აღწერილია სტატიაში What to do when a mod update breaks, ხოლო რა კიდევ ეკუთვნის იმავე განრიგს - სტატიაში scheduled tasks worth having.

Windows Defender-ის გამონაკლისები#

Microsoft Defender-ის real-time protection ფაილებს ჩაწერისას ამოწმებს. განახლება ათასობით ფაილს წერს, validate კი ინსტალაციის ყველა ფაილს კითხულობს, რომელსაც Defender შეიძლება ხელახლა შეამოწმოს. დიდ ინსტალაციაზე ეს არის სხვაობა იმ validate-ს შორის, რომელიც რამდენიმე წუთში სრულდება, და იმას შორის, რომელსაც გაცილებით მეტი სჭირდება. Defender-ს ასევე შეუძლია ახლად ჩაწერილი ფაილი შემოწმებისას წამით ღიად დაიჭიროს, რაც ზოგჯერ SteamCMD-თან ეჯახება, როცა ის ფაილს ადგილზე ათავსებს.

SteamCMD-ის საქაღალდისა და სერვერის საქაღალდეების სკანირებიდან გამორიცხვა ორივე პრობლემას აგვარებს. ადმინისტრატორის PowerShell ფანჯრიდან:

PS> Add-MpPreference -ExclusionPath "C:\steamcmd"PS> Add-MpPreference -ExclusionPath "C:\servers"PS> Get-MpPreference | Select-Object -ExpandProperty ExclusionPath

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

გულწრფელად შეაფასე კომპრომისი. გამონაკლისი ნიშნავს, რომ Defender ამ საქაღალდეებში არაფერს შეხედავს, მათ შორის ბოროტ plugin-ს, რომელიც ვინმემ გამოგიგზავნა, ან მოდს, რომელიც საიტიდან ჩამოტვირთე, რომელსაც არ უნდა მიენდო. გამონაკლისები მხოლოდ იმ საქაღალდეებით შემოიფარგლე, რომლებსაც სჭირდებათ, არასდროს გამორიცხო Downloads საქაღალდე ან მთელი დისკი და მოდები და plugin-ები გამონაკლისის საქაღალდეში ჩასვლამდე დაასკანირე. Malicious plugins and mods განმარტავს, რატომ არ არის ეს ზედმეტი სიფრთხილე.

Defender-ის გამონაკლისები Windows Defender Firewall-ისგან განცალკევებულია. თავად SteamCMD-ს მხოლოდ გამავალი ინტერნეტ წვდომა სჭირდება, რასაც Windows ნაგულისხმევად უშვებს. თამაშის სერვერს თავისი პორტებისთვის შემომავალი წესები სჭირდება და პირველად გაშვებისას Windows იკითხავს, დაუშვას თუ არა იგი კერძო ან საჯარო ქსელებში. უპასუხე იმ ქსელისთვის, რომელშიც სერვერი რეალურად არის, ან წესები თავად შექმენი New-NetFirewallRule-ით - ზემოთ მითითებული Valheim-ის Windows-ის გზამკვლევი ორივეს გადის.

SteamCMD-ის პრობლემების მოგვარება Windows-ზე#

SteamCMD ორჯერ დაწკაპუნებისას მაშინვე იხურება ან ფანჯარა გაკრთება და ქრება. სავარაუდოდ, თავი განაახლა და თავიდან გაეშვა, ან შეცდომას წააწყდა და გამოვიდა. გაუშვი ღია Command Prompt-იდან, რომ გამოტანა ეკრანზე დარჩეს, და წაიკითხე logs\bootstrap_log.txt.

`Failed to install app 'X' (Disk write failure)`. სამიზნე საქაღალდეში SteamCMD-ის გამშვებ ანგარიშს ჩაწერა არ შეუძლია, ან დისკი სავსეა. თუ მხოლოდ Task Scheduler-იდან ვარდება, პირველ რიგში ანგარიში შეამოწმე. სავსე დისკის შემთხვევაში გახსოვდეს, რომ განახლებას არსებული ინსტალაციის გარდა თავისუფალი ადგილიც სჭირდება - what to do when the disk is full აღწერს, რამდენი.

`Failed to install app 'X' (Missing file permissions)` ან access denied. ინსტალაციაში რომელიმე ფაილი გამოიყენება (სერვერი ისევ მუშაობს), მხოლოდ წასაკითხია ან იმ ანგარიშის საკუთრებაშია, რომელსაც მიმდინარე ანგარიში ვერ ცვლის. გააჩერე სერვერი, შემდეგ შეადარე საქაღალდის უფლებები იმ ანგარიშს, რომლითაც ამოცანა სრულდება.

განახლება წარმატებულს აცხადებს, მაგრამ სერვერი არ შეცვლილა. ამოცანამ სხვა სკრიპტი გაუშვა, სკრიპტში ინსტალაციის საქაღალდე განსხვავდება იმისგან, საიდანაც service იწყება, ან force_install_dir login-ის შემდეგ მოვიდა და ფაილები C:\steamcmd\steamapps\common-ში მოხვდა. იქ სერვერის მეორე ასლი მოძებნე.

ამოცანის Last Result არანულოვანია, მაგრამ ლოგი ცარიელია. batch ფაილი საერთოდ არ გაშვებულა ან System32-ში გაეშვა და ლოგი იქ ჩაწერა. შეამოწმე მისამართი ამოცანის action-ში და cd /d "%~dp0" ხაზი.

SteamCMD დაგეგმილ ამოცანაში შესვლაზე ჩერდება. ელოდება პაროლს ან Steam Guard კოდს, რომელიც არასდროს მოვა. გაუშვი SteamCMD ერთხელ ხელით ამოცანის ანგარიშით, რომ ავტორიზაცია შეინახოს, და სკრიპტში დატოვე @NoPromptForPassword 1, რომ შემდეგი ჩავარდნა დასრულდეს და არ გაჭედოს.

ყველაფერმა Windows-ის განახლების შემდეგ შეწყვიტა მუშაობა. ჩვეულებრივ SteamCMD არ არის დამნაშავე. დარწმუნდი, რომ service ხელით ჯერ კიდევ იწყება და ამოცანა ისევ არსებობს; შემდეგ C:\steamcmd-ში წაშალე ყველაფერი steamcmd.exe-სა და config საქაღალდის გარდა (თუ რეალურ ანგარიშს იყენებ) და გაუშვი +quit კლიენტის აღსადგენად.

როცა Windows-ის გაშვება საერთოდ არ გინდა#

ამ სტატიის დიდი ნაწილი იმიტომ არსებობს, რომ Windows უყურადღებოდ მომუშავე ბრძანების ხაზის ხელსაწყოებისთვის არ შექმნილა, და ყოველი ზემოთ აღწერილი ნაბიჯი - service wrapper-ები, ამოცანის ანგარიშები, Defender-ის გამონაკლისები - იმისთვისაა, რომ ამგვარად იმუშაოს. ზოგ სერვერს მხოლოდ Windows build აქვს და მათთვის ეს ღირს, ან ღირს წაკითხვა Linux vs Windows for game servers და Wine and Proton route. დანარჩენისთვის კითხვა ისაა, გინდა თუ არა მანქანის მოვლა საერთოდ.

RE:NODE-ზე SteamCMD-ის ნაბიჯი სრულდება თამაშის სერვერის შექმნისას, ჩვეულებრივ გადახდის დადასტურებიდან ერთ წუთში, და ინსტალაციის გამოტანა კონსოლში სტრიქონ-სტრიქონ ჩნდება. თამაშის ცვლადები და გაშვების პარამეტრები Startup ტაბის ველებია, ამიტომ მოსავლელი სკრიპტი არ არსებობს. Schedules ტაბი cron-ის სტილის ამოცანებს ახორციელებს დალაგებული ნაბიჯებით - backup, შემდეგ restart, მათ შორის შეყოვნებებით - რაც ზემოთ აღწერილ Task Scheduler-ის საქმეს ფარავს; გზამკვლევები აჩვენებს, როგორ არის მოწყობილი. თამაშები, რომლებსაც შენი საკუთარი Steam ანგარიში სჭირდება, Setup ტაბზე ელოდებიან, სანამ არ დაამატებ.

FAQ#

SteamCMD ადმინისტრატორის სახელით უნდა გავუშვა?

არა, სანამ ის და სერვერის საქაღალდეები ისეთ ადგილასაა, სადაც ანგარიშს ჩაწერა შეუძლია, მაგალითად C:\steamcmd და C:\servers. ადმინისტრატორის უფლებების საჭიროება ჩვეულებრივ იმის ნიშანია, რომ ფაილები Program Files-შია. ამ მოწყობაში ელევაცია მხოლოდ Defender-ის გამონაკლისების დამატებისთვის და SYSTEM-ით გაშვებული ამოცანების შესაქმნელადაა საჭირო.

შეიძლება SteamCMD-ის ნაცვლად Steam კლიენტის Tools ბიბლიოთეკის გამოყენება?

ზოგი სერვერისთვის - დიახ: Steam-ის ბიბლიოთეკაში Tools-ში ჩამოთვლილი dedicated სერვერები ჩვეულებრივი თამაშივით ინსტალირდება. ამისთვის მანქანაზე სრული Steam კლიენტი უნდა იყოს შესული და განახლება მაშინ ხდება, როცა Steam გადაწყვეტს, რაც სახლის კომპიუტერს უხდება, რომელზეც თამაშებიც იმართება. მანქანას, რომელიც მხოლოდ სერვერებს უშვებს, უკეთ SteamCMD ერგება, რომელსაც სამუშაო სესია არ სჭირდება.

სად არის SteamCMD-ის ლოგები Windows-ზე?

SteamCMD-ის საქაღალდეში არსებულ logs საქაღალდეში, მაგალითად C:\steamcmd\logs. content_log.txt ჩამოტვირთვებსა და ინსტალაციის ჩავარდნებს ინახავს და პირველი ფაილია, რომელიც განახლების ჩავარდნისას უნდა წაიკითხო. შენი batch ფაილის ლოგი ცალკეა და მხოლოდ იმას შეიცავს, რაც მასში გადაამისამართე.

შეიძლება სერვერის Linux build Windows-იდან ჩამოვტვირთო?

დიახ. სკრიპტის თავში, login-მდე, დაამატე @sSteamCmdForcePlatformType linux. ფაილები ჩამოიტვირთება, მაგრამ Windows-ზე არ გაეშვება; ეს გამოსადეგია ინსტალაციის მოსამზადებლად, რომელიც Linux მანქანაზე ან ჰოსტის ფაილ მენეჯერში უნდა გადაიტანო.

როგორ წავშალო SteamCMD?

წაშალე მისი საქაღალდე და ყველა დაგეგმილი ამოცანა და Defender-ის გამონაკლისი, რომელიც მისთვის შექმენი. SteamCMD registry-ში არაფერს წერს და საკუთარ service-ებს არ აყენებს. სხვა საქაღალდეებში არსებული სერვერის ინსტალაციები ხელუხლებელი რჩება და მუშაობს; ისინი მხოლოდ თავის განმაახლებელს კარგავენ.

რატომ იზრდება განახლების დრო ყოველ ახალ SteamCMD გამოშვებაზე?

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