SteamCMD app ID-ები და beta ბრენჩები

SteamCMD-ით გამოყოფილი სერვერის დასაყენებლად ან გასაახლებლად ორი რამ გჭირდება: სერვერის app ID, რომელიც ჩვეულებრივ თამაშისას არ ემთხვევა, და ბრენჩი, რომელიც გინდა - ის public-ია, თუ სხვას არ მიუთითებ. ბრძანება ყოველთვის ასეთია: +app_update <server id> -beta <branch> validate, გაშვებული +login anonymous-ის შემდეგ ან იმ ანგარიშით შესვლის შემდეგ, რომელსაც თამაში ეკუთვნის. გაფუჭებული ინსტალაციების უმეტესობა სამიდან ერთ-ერთი შეცდომით იწყება: სერვერის ადგილას თამაშის ID გადაეცა, არჩეულია ბრენჩი, რომელზეც კლიენტები არ არიან, ან ანონიმური login სცადე იმ რამდენიმე სერვერისთვის, რომელიც მას არ იღებს. ეს სტატია სამივეს ცნობარია: ID-ების ცხრილი, როგორ წაიკითხო ბრენჩები, რომლებსაც სერვერი რეალურად აქვეყნებს, და რას უშვრება ბრენჩებს შორის გადართვა შენს ფაილებს.

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

სერვერის app ID-ები და თამაშის app ID-ები#

Steam გამოყოფილ სერვერს ცალკე აპლიკაციად აღიქვამს. მას საკუთარი ID, საკუთარი depot-ები და საკუთარი ბრენჩები აქვს და, როგორც წესი, უფასოა. თამაშს, რომელსაც თამაშობ, სხვა ID აქვს. ორივე გჭირდება, სხვადასხვა საქმისთვის:

• სერვერის app ID გადაეცემა app_update-ს. სწორედ ის წყვეტს, რომელი ფაილები აღმოჩნდება ინსტალაციის საქაღალდეში.
• თამაშის app ID გადაეცემა workshop_download_item-ს, და სწორედ ამ ID-ს ირჩევ, როცა Steam game server login token-ს ქმნი, რადგან Workshop-ის კონტენტიც და token-ებიც თამაშს ეკუთვნის.

თუ app_update-ს თამაშის ID-ს გადასცემ, ორიდან ერთი მოხდება. ანონიმური login-ით მიიღებ No subscription-ს, რადგან ანონიმურ სესიაზე თამაში შენ არ გეკუთვნის. რეალური ანგარიშით, რომელსაც თამაში აქვს, ყველაფერი იმუშავებს და სერვერის საქაღალდეში სრულ კლიენტს ჩამოტვირთავ - ტექსტურებით, ხმით და ყველაფრით. ეს მეორე შედეგი უარესია, რადგან წარმატებას ჰგავს, დისკზე ათჯერ მეტ ადგილს იკავებს და მასში არაფერი ეშვება სერვერად.

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

სიაში რამდენიმე თამაშს სერვერისთვის SteamCMD საერთოდ არ სჭირდება. Terraria-ს გამოყოფილი სერვერი ოფიციალური საიტიდან zip-ად მოდის, Factorio-ს headless სერვერი - tarball-ად factorio.com-იდან, Minecraft-ის სერვერის jar-ს კი Steam-თან შეხება არასდროს ჰქონია. მათი app ID-ის ძებნა ჩიხია; საიდან მოდის ისინი, ამას Terraria-სა და tModLoader-ის სერვერის გზამკვლევი და Factorio-ს headless სერვერის გზამკვლევი აღწერს.

Counter-Strike 1.6 და app 90

HLDS ყველაზე ძველი რამაა, რაც ჯერ კიდევ SteamCMD-ით ვრცელდება, და შესაბამისადაც იქცევა. App 90 რამდენიმე Half-Life მოდს შეიცავს და Counter-Strike-ს განახლებამდე კონფიგურაციის ხაზით ირჩევ:

$ ./steamcmd.sh +force_install_dir /srv/cs16 +login anonymous \    +app_set_config 90 mod cstrike \    +app_update 90 validate +quit

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

როგორ იპოვო app ID და მისი ბრენჩები თავად#

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

Steam> login anonymousSteam> app_info_update 1Steam> app_info_print 896660

app_info_update 1 აახლებს SteamCMD-ის აპლიკაციების მეტამონაცემების ლოკალურ cache-ს; მის გარეშე შეიძლება მოძველებული ან ცარიელი შედეგი მიიღო. ამის შემდეგ app_info_print დიდ, ჩადგმულ ბლოკს გამოიტანს. მნიშვნელოვანი ნაწილი depots-ის ქვეშ, branches-შია:

"branches"{    "public"    {        "buildid"        "19455410"        "timeupdated"    "1758000000"    }    "public-test"    {        "buildid"        "19512002"        "description"    "Public test"        "pwdrequired"    "1"        "timeupdated"    "1758600000"    }}

თითოეული ჩანაწერი ბრენჩის სახელია, რომელიც შეგიძლია -beta-ს გადასცე. buildid ამ ბრენჩზე ამჟამად გამოქვეყნებული build-ია, timeupdated - Unix timestamp, ხოლო pwdrequired, თუ 1-ის ტოლია, ნიშნავს, რომ -betapassword-იც გჭირდება. პაროლი არასდროს იბეჭდება; დეველოპერი მას patch notes-ში, თავის Discord-ზე ან თამაშის wiki-ზე აქვეყნებს. ზემოთ მოცემული build ID-ები საილუსტრაციოა - რეალური რიცხვები ყოველ განახლებაზე იცვლება.

SteamDB იგივე მონაცემებს ბრაუზერში აჩვენებს, ყოველი build-ის ისტორიით, და ეს ყველაზე მარტივი გზაა კითხვებზე პასუხის გასაცემად: "ბოლოს როდის შეიცვალა ეს ბრენჩი" და "რა იყო build ID იმ patch-მდე, რომელმაც ყველაფერი გაგვიფუჭა". სერვერის საკუთარი ID-ის საპოვნელად ჩვეულებრივ ყველაზე სწრაფია SteamDB-ზე თამაშის სახელს "Dedicated Server" მიუწერო და მოძებნო; შენთვის საჭირო ის შედეგია, რომლის ტიპი "Tool"-ია.

როგორ მუშაობს ბრენჩები#

ბრენჩი სახელიანი მიმთითებელია build-ზე. ნაგულისხმევი public-ია და ყველა მას იღებს, თუ სხვა რამეს არ აირჩევს. დეველოპერები ბრენჩებს სამი მიზეზით ამატებენ:

1. სატესტო build-ები - latest_experimental, experimental, public-test, unstable, staging. public-ზე წინ არიან, ნაკლებად შემოწმებულია და ზოგჯერ save-ებთან შეუთავსებელიც.
2. ძველი ვერსიები - ბრენჩი, რომელიც წინა რელიზზეა გაჩერებული, რათა თემებმა მასზე დარჩენა შეძლონ, სანამ მოდები დაეწევა.
3. პლატფორმული ან ტექნიკური ვარიანტები - 64-ბიტიანი build, profiling build დამატებითი დიაგნოსტიკით, build, რომელიც სერვერებისთვის ფასიანი DLC-ის კონტენტს შეიცავს.

ბრძანება ყველასთვის ერთნაირია:

$ ./steamcmd.sh +force_install_dir /srv/valheim +login anonymous \    +app_update 896660 -beta public-test -betapassword yesimadebackups \    validate +quit

ეს მაგალითი რეალურია: Valheim-ის public test ბრენჩი წლების განმავლობაში პაროლად yesimadebackups-ს იყენებს - ხუმრობა, რომელსაც აზრი აქვს. Iron Gate სატესტო build-ებს ისე ცვლის, რომ სამყაროები შეიძლება გაფუჭდეს, და უნდათ, რომ შენი ჯერ დააკოპირო.

ბრენჩები, რომლებსაც სახელით შეხვდები

ბრენჩების სახელები იცვლება. განსაკუთრებით Project Zomboid-ის წყობა შეიცვალა, რაც Build 42 სტაბილურისკენ მიიწევდა, ხოლო 7 Days to Die თავის ძველი ვერსიების ბრენჩებს სხვადასხვა ეპოქაში სხვადასხვანაირად არქმევდა (ჯერ alpha-ს ნომრებით, 1.0-ის შემდეგ კი ვერსიის ნომრებით). მიმდინარე სიის სანახავად გამოიყენე app_info_print, ნაცვლად იმისა, რომ სახელი ორი წლის წინანდელი ფორუმის პოსტიდან დააკოპირო.

DayZ თავის სატესტო build-ებს სხვაგვარად მართავს: ექსპერიმენტული სერვერი ცალკე აპლიკაციაა, 1042420, და არა 223350-ის ბრენჩი. ექსპერიმენტული კლიენტები მხოლოდ ექსპერიმენტულ სერვერებს უკავშირდებიან, ამიტომ ეს მთლიანად პარალელური ინსტალაციაა და არა უბრალოდ flag.

კლიენტების სერვერთან შესაბამისობა#

ბრენჩზე მყოფი სერვერი მხოლოდ იმავე build-ზე მყოფ კლიენტებს იღებს. მოთამაშეები ამას თავიანთი Steam-ის ბიბლიოთეკიდან ირჩევენ: თამაშზე მარჯვენა ღილაკი, Properties, Betas, ჩამოსაშლელი სიიდან ბრენჩის არჩევა და, თუ აქვს, პაროლის შეყვანა. შემდეგ Steam ამ ბრენჩის კლიენტის build-ს ჩამოტვირთავს.

ბრენჩებთან დაკავშირებული პრობლემების უმეტესობა სწორედ აქ ხდება და იშვიათად ჩანს, როგორც ბრენჩის პრობლემა. კლიენტი წერს "incompatible version", "version mismatch" ან უბრალოდ timeout-ში გადის, მოთამაშე კი იფიცება, რომ განაახლა. მართლაც განაახლა - public-მდე. სამი ჩვევა გადაგარჩენს ამაზე დახარჯულ საღამოს:

• ბრენჩის სახელი სერვერის სახელში ან MOTD-ში მიუთითე, სანამ მასზე ხარ, რომ გამოცნობა არავის მოუწიოს.
• დაამაგრე შეტყობინება ზუსტი ნაბიჯებით და პაროლით, სანამ გადართავ.
• უკან გადართე გააზრებულად. როცა სატესტო ბრენჩი public-ში შეერწყმება, ორივე მხარეს უკან დაბრუნება სჭირდება, და მოთამაშეები, რომლებსაც ავიწყდებათ, რჩებიან ბრენჩზე, რომელიც უკვე შემდეგ სატესტო build-ზე გადავიდა.

სატესტო ბრენჩები გაფრთხილების გარეშეც ახლდება, დატვირთულ კვირაში ზოგჯერ დღეში რამდენჯერმე. სერვერი, რომელიც ყოველ restart-ზე ახლდება, მათ მიჰყვება; კლიენტები მიჰყვებიან, როგორც კი Steam შეამჩნევს. რაღაც მომენტში ორივე მხარე ცოტა ხნით სხვადასხვა build-ზე იქნება, ამიტომ სატესტო ბრენჩებზე ხანდახან "version mismatch" მოსალოდნელია და ნუ ჩათვლი ხარვეზად.

რას უშვრება გადართვა შენს ფაილებს#

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

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

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

ძველი ბრენჩის ფაილები შეიძლება დარჩეს. ფაილები, რომლებიც მხოლოდ ძველ build-ში არსებობდა, ჩვეულებრივ იშლება, მაგრამ ყოველთვის არა, და ექსპერიმენტული build-იდან დარჩენილმა მოძველებულმა DLL-მა ან asset-მა public-ზე უცნაური crash-ები შეიძლება გამოიწვიოს. თუ სერვერი უკან დაბრუნების შემდეგ უცნაურად იქცევა, პირველი გამოსავალი validate-ით გაშვებაა. თუ არ უშველა, წაშალე ინსტალაცია (save-ები არა) და ბრენჩი სუფთად თავიდან დააყენე.

SteamCMD ბრენჩს იმახსოვრებს. ინსტალაციის steamapps/appmanifest_<id>.acf ინახავს დაყენებულ build ID-ს და, როცა beta-ზე ხარ, ბრენჩის სახელს თავის user config ნაწილში. მისი წაკითხვა ყველაზე სწრაფი გზაა იმის დასადასტურებლად, რეალურად რაზეა სერვერი. ნუ დაეყრდნობი იმას, რომ SteamCMD ბრენჩს მომავალი განახლებებისთვის დაიმახსოვრებს: მისი ქცევა აქ ვერსიიდან ვერსიამდე იცვლებოდა და -beta-ს გარეშე განახლების ხაზი ხან სერვერს ბრენჩზე ტოვებდა, ხან კი უკან აბრუნებდა. -beta ყოველთვის ცხადად გადაეცი, მათ შორის -beta public, როცა ნაგულისხმევი გინდა.

ვერსიის დაფიქსირება და უკან დაბრუნება#

SteamCMD-ს არ აქვს არგუმენტი "დააყენე build 18000000". ძველ რელიზებამდე სამი გზით მიხვალ, უპირატესობის მიხედვით:

1. ვერსიის ბრენჩი, რომელსაც დეველოპერი აქვეყნებს. თუ 7 Days to Die ან Arma 3 წინა რელიზზე ბრენჩს ინახავს, -beta <that name> უკან დაბრუნების ოფიციალური გზაა და კლიენტებსაც შეუძლიათ შენ გამოგყვნენ.
2. შენი საკუთარი ასლი. ყოველი განახლების წინ ინსტალაციის საქაღალდე დაარქივე (ან backup-ს გააკეთებინე). უკან დაბრუნება ამ არქივის აღდგენაა და app_update-ის არგაშვება, სანამ მზად არ იქნები. ეს ნებისმიერ თამაშზე მუშაობს და ერთადერთი ვარიანტია, როცა ვერსიის ბრენჩი არ არსებობს.
3. Depot-ების ჩამოტვირთვა. SteamCMD-ს აქვს ბრძანება download_depot, რომელიც კონკრეტული depot-ის კონკრეტულ manifest-ს იღებს, იმ ID-ებით, რომლებსაც SteamDB-ზე ნახულობ. მუშაობს, მაგრამ მოუხერხებელია, მხოლოდ ფაილებს გაძლევს და არა მართულ ინსტალაციას, და ფასიანი კონტენტისთვის ანონიმურ login-ზე ჩვეულებრივ დაბლოკილია. ბოლო საშუალებად ჩათვალე.

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

ანონიმური login და სერვერები, რომლებიც მას არ იღებენ#

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

• DayZ (223350) და Arma 3 (233780) საჭიროებენ ანგარიშს, რომელსაც თამაში ეკუთვნის, როგორც სერვერისთვის, ისე Workshop-ის ჩამოტვირთვებისთვის. ანონიმური login No subscription-ს იძლევა.
• Workshop-ის კონტენტს ბევრ თამაშში თამაშის მფლობელი ანგარიში სჭირდება, მაშინაც კი, როცა თავად სერვერი ანონიმურია. წესი თითოეულ თამაშზე განსხვავდება და დროთა განმავლობაში იცვლებოდა, ასე რომ, თუ ანონიმური workshop_download_item წვდომის შეცდომით ვარდება, მიზეზი ესაა.
• Depot-ის ჩამოტვირთვის მოთხოვნებს ფასიანი აპლიკაციებისთვის თამაშის მფლობელი ანგარიში სჭირდება.

ზოგიერთი ჰოსტინგი Steam-ის login-ს იმ თამაშებისთვისაც ითხოვს, რომლებიც ქაღალდზე ანონიმურია, რადგან მათი ინსტალაცია Workshop-ის ელემენტებსაც ან დახურულ ბრენჩსაც იღებს. RE:NODE-ზე Arma 3, DayZ, Project Zomboid და 7 Days to Die შენს Steam login-ს ითხოვენ: სერვერი მაშინვე იქმნება, ინსტალაცია კი Setup ჩანართზე ელოდება, სანამ მას არ მიუთითებ. მონაცემები ისე ინახება, როგორც აკრიფე, ამიტომ გამოიყენე სათადარიგო ანგარიში, რომელსაც მხოლოდ ეს თამაში აქვს - არასდროს ის ანგარიში, რომლითაც ყიდვებს აკეთებ.

Steam Guard-ის დადასტურება ერთხელ, ინტერაქტიულად სჭირდება იმ მანქანაზე, რომელიც ინსტალაციას აკეთებს. ამის შემდეგ SteamCMD login token-ს თავის კონფიგურაციის საქაღალდეში ინახავს და შემდგომი გაშვებები ადამიანის ჩარევის გარეშე მიდის. სწორედ ეს შენახული token აამუშავებს უყურადღებო განახლებას და სწორედ ამიტომ უნდა იყოს ანგარიში ისეთი, რომლის დაკარგვაც არ გეწყინება.

ID-ებისა და ბრენჩების პრობლემების მოგვარება#

`No subscription` ანონიმური login-ით. ან ID თამაშისაა და არა სერვერის, ან სერვერს თამაშის მფლობელი ანგარიში სჭირდება. ჯერ ID შეამოწმე app_info_print-ით; ეს უფრო იაფი შეცდომაა.

`Invalid Password` ან ბრენჩი ჩუმად არ ერთვება. -betapassword არასწორია ან მოძველებული. დეველოპერები მათ ცვლიან. მიმდინარე პაროლი მათ განცხადებებში შეამოწმე.

განახლება დასრულდა, მაგრამ სერვერი ისევ ძველ build-ზეა. შეადარე build ID appmanifest_<id>.acf-ში ბრენჩის buildid-ს app_info_print-იდან. თუ ემთხვევა, Steam-ს სერვერისთვის patch ჯერ არ გამოუქვეყნებია; კლიენტისა და სერვერის განახლებები ყოველთვის ერთსა და იმავე წუთში არ გამოდის და ზოგი გამომცემელი სერვერს საათით ან მეტით გვიან აწვდის.

`Invalid Platform`. ბრენჩს ან აპლიკაციას შენი ოპერაციული სისტემისთვის build არ აქვს. რამდენიმე სერვერი მხოლოდ Windows-ზეა; მათ სტატია Linux თუ Windows თამაშის სერვერებისთვის ჩამოთვლის, ხოლო გამოსავალს Wine და Proton მხოლოდ Windows-ის სერვერებისთვის აღწერს.

ბრენჩის გადართვის შემდეგ კლიენტები ვერ უერთდებიან. თითქმის ყოველთვის კლიენტი ისევ public-ზეა. შეადარე build, რომელსაც კლიენტი მთავარ მენიუში ან კონსოლში აჩვენებს, სერვერისას.

სუფთა `public` ინსტალაცია ექსპერიმენტულზე ყოფნის შემდეგ crash-ს იძლევა. მოძველებული ფაილები. გაუშვი validate-ით, და თუ არ უშველა, ცარიელ საქაღალდეში თავიდან დააყენე და save-ები უკან დააკოპირე.

FAQ#

ემთხვევა ოდესმე სერვერის app ID თამაშისას?

ხანდახან. მთავარი მაგალითი Counter-Strike 2-ია: სერვერი 730-იდან, თამაშის საკუთარი ID-იდან, ყენდება. თითქმის ყველა დანარჩენ შემთხვევაში გამოყოფილი სერვერი ცალკე ხელსაწყოა საკუთარი ნომრით და თამაშის ID-ის გამოყენება ან ვერ მუშაობს, ან სრულ კლიენტს ჩამოტვირთავს.

beta პაროლი კლიენტზეც მჭირდება?

კი. მოთამაშე იმავე პაროლს Steam-ში თამაშის Betas პარამეტრებში შეიყვანს ბრენჩის გასახსნელად. მის გარეშე მისი კლიენტი public-ზე რჩება და სატესტო build-ზე მყოფ სერვერს ვერ შეუერთდება.

ექსპერიმენტულ ბრენჩზე გადართვა ჩემს სამყაროს გააფუჭებს?

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

როგორ დავბრუნდე beta ბრენჩიდან ჩვეულებრივ რელიზზე?

განახლება ხელახლა გაუშვი -beta public-ით და validate-ით. public ცხადად მიუთითე და flag ნუ გამოტოვე, შემდეგ კი app manifest-ში build ID შეამოწმე, რომ დარწმუნდე, გადართვა მოხდა.

რატომ რჩება ჩემი სკრიპტით განახლება ძველ ვერსიაზე patch-ის შემდეგ?

ან გამომცემელს სერვერის build ჯერ არ გამოუშვია, ან სკრიპტი დამაგრებულია ბრენჩზე, რომელიც დაგავიწყდა. ბრენჩები app_info_print-ით დაბეჭდე და მათი build ID-ები შენს manifest-შიც არსებულს შეადარე.

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

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