Unity-ის გამოყოფილი სერვერი: batchmode და ლოგები

გამოყოფილი სერვერების დიდი ნაწილი, რომლებსაც ხალხი ქირაობს - Valheim, Rust, 7 Days to Die, Unturned, SCP: Secret Laboratory, The Forest, Sons of the Forest, V Rising, Core Keeper - არის Unity-ის პროგრამა, რომელიც ფანჯრის გარეშე ეშვება. ყველას ერთი და იგივე ჩონჩხი აქვს: ბინარული ფაილი <Name>_Data საქაღალდის გვერდით, ორი გადამრთველი (-batchmode -nographics), რომელიც თამაშს უეკრანო პროცესად აქცევს, ლოგ-ფაილი, რომელსაც Unity პროგნოზირებად ადგილას წერს, თუ სხვა რამ არ უთხარი, და სკრიპტინგის backend-ი (Mono ან IL2CPP), რომელიც წყვეტს, როგორ იმუშავებს მოდინგი. ერთხელ ისწავლე ეს ჩონჩხი და ნებისმიერი Unity-ის სერვერის წაკითხვა, გაშვება და დებაგი გაგიადვილდება, რომელ სტუდიასაც არ უნდა ჰქონდეს გაკეთებული.

რომელი სერვერებია Unity და რატომ აქვს ამას მნიშვნელობა#

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

Unity-ის სერვერს, როგორც წესი, ფაილებით ამოიცნობ. მოძებნე საქაღალდე სახელით <something>_Data, ბინარული ფაილის გვერდით UnityPlayer.so (Linux) ან UnityPlayer.dll (Windows), ხოლო მონაცემების საქაღალდეში ფაილები globalgamemanagers და resources.assets. თუ ეს ყველაფერი ადგილზეა, ამ სტატიაში დაწერილი ყველაფერი შენს სერვერსაც ეხება.

ზოგი თამაში, რომელიც ხალხს Unity-ზე ჰგონია, სინამდვილეში სხვა ძრავაზეა. Palworld, ARK, Satisfactory, Abiotic Factor და Squad არის Unreal Engine (იხილე Unreal Engine-ის გამოყოფილი სერვერის საფუძვლები); Terraria არის XNA/FNA; Don't Starve Together და Factorio საკუთარ ძრავებზე მუშაობს; Space Engineers არის VRage. განსხვავება პრაქტიკულია - სხვაა ლოგის ადგილი, ნაკადების მოდელი და მოდების ჩამტვირთავები.

Batchmode, nographics და გაშვების ხაზი#

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

• -batchmode - გაშვება ინტერაქტიული ციკლის გარეშე, რომელიც მომხმარებელს ელოდება: არც ფანჯარა, არც შეყვანა, არც დიალოგები. შეცდომის ფანჯრები, რომლებიც დესკტოპის ვერსიას გააჩერებდა, ჩახშობილია.
• -nographics - გრაფიკული მოწყობილობა საერთოდ არ ინიციალიზდება. მის გარეშე batchmode GPU-ს არმქონე მანქანაზე შეიძლება მაინც შეეცადოს მის შექმნას და ჩავარდეს, ან მეხსიერება გამოყოს რენდერინგისთვის, რომელიც არასდროს მოხდება.

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

# Valheim: plain dash arguments read by the game$ ./valheim_server.x86_64 -nographics -batchmode -name "Crew" -port 2456 \    -world "Midgard" -password "longship-42"# Rust: Unity flags, then +convar pairs$ ./RustDedicated -batchmode -nographics +server.port 28015 \    +server.identity "main" +server.hostname "My Rust server"# 7 Days to Die: a config file does most of the work$ ./7DaysToDieServer.x86_64 -batchmode -nographics -dedicated \    -configfile=serverconfig.xml -logfile output_log.txt

Unity 2021.2-დან არსებობს ცალკე "Dedicated Server" build target-იც. ასე აწყობილ თამაშს ბინარული ფაილიდან რენდერინგის კოდი ამოღებული აქვს და ნაგულისხმევად უეკრანოდ ეშვება, ამიტომ გადამრთველები აუცილებლობის ნაცვლად დამატებით დაზღვევად იქცევა. ძველი და ბევრი ახლანდელი თამაშიც კვლავ ჩვეულებრივ player build-ს აწვდის და გადამრთველებზეა დამოკიდებული, ამიტომ გაშვების ხაზიდან ისინი არასდროს ამოიღო, მაშინაც კი, თუ სერვერი მათ გარეშეც თითქოს მუშაობს.

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

კადრების სიხშირე იგივე tick rate-ია

Unity-ის სერვერი სათამაშო ციკლია. ყოველ კადრში ის ფიზიკას, AI-ს და ქსელს ამუშავებს, შემდეგ თავიდან იწყებს. Batchmode-ში vsync არ არის, რომ შეაჩეროს, ამიტომ სერვერი, რომლის დეველოპერსაც კადრების სიხშირის შეზღუდვა დაავიწყდა, იმდენ კადრს გაუშვებს წამში, რამდენსაც ერთი ბირთვი შეძლებს, და ისე, რომ არავინაა შემოსული, CPU-ს 100%-ზე იქნება. თამაშების უმეტესობა მას Application.targetFrameRate-ით ზღუდავს და ლიმიტს პარამეტრად აჩენს - Rust-ს, მაგალითად, აქვს fps.limit. თუ ცარიელი Unity-ის სერვერი ერთ ბირთვს მთლიანად იკავებს, ჯერ ეს პარამეტრი მოძებნე და მერე ივარაუდე, რომ რამე გაფუჭდა. რას ნიშნავს სინამდვილეში tick rate ხსნის ბალანსს კადრებსა და რეაგირების სისწრაფეს შორის.

სად წერენ Unity-ის სერვერები ლოგებს#

Unity საკუთარ ლოგს - ძრავის შეტყობინებებს და ყველაფერს, რასაც თამაში Debug.Log-ით ბეჭდავს - წერს ფაილში სახელით Player.log. სად აღმოჩნდება ეს ფაილი, დამოკიდებულია პლატფორმაზე და ერთ არგუმენტზე:

<Company> და <Product> ის სტრიქონებია, რომლებიც სტუდიამ პროექტში დააყენა, მაგალითად IronGate/Valheim. წინა გაშვების ლოგი, როგორც წესი, იმავე საქაღალდეში Player-prev.log-ად ინახება.

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

ზოგი თამაში Unity-ის ლოგის გარდა საკუთარ ლოგებსაც ინახავს. 7 Days to Die წერს output_log ფაილებს დროის ნიშნულებით, თუ ამას უბრძანებ; Rust თითოეული identity-სთვის ცალკე ლოგს წერს, თუ -logfile-ს გადასცემ; SCP: SL-ის LocalAdmin საკუთარ logs საქაღალდეს ინახავს. როცა რამე ჩავარდება, ორივე შეამოწმე: თამაშის ლოგი თამაშის შეცდომებისთვის, Unity-ისა - ძრავის და ნატიური ბიბლიოთეკების შეცდომებისთვის. სათამაშო სერვერის ლოგები-ში თითოეული თამაშის რუკაა.

ხაზები, რომლებიც საშიშად გამოიყურება, მაგრამ არ არის

Unity-ის სერვერის ლოგი ძრავის ხმაურის ბლოკით იწყება, რომელიც ხალხს ყოველ ჯერზე აშინებს. უეკრანო მანქანაზე მისი უმეტესი ნაწილი უვნებელია:

Initialize engine version: 2022.3.xForcing GfxDevice: NullNullGfxDevice:    Version:  NULL 1.0 [1.0]Desktop is 0 x 0 @ 0 HzFallback handler could not load library .../Mono/libc

რას ნიშნავს თითოეული:

• Initialize engine version გეუბნება, Unity-ის რომელ რელიზს იყენებს თამაში. ღირს ჩანიშვნა, როცა მოდების ჩამტვირთავი ამას გკითხავს.
• Forcing GfxDevice: Null და NullGfxDevice ბლოკი ნიშნავს, რომ -nographics ისე მუშაობს, როგორც უნდა.
• Desktop is 0 x 0 @ 0 Hz ეკრანის არარსებობაა, რაც სწორია.
• Fallback handler could not load library ხაზები Mono-ა, რომელიც ნატიურ ბიბლიოთეკებს ალტერნატიული სახელებით ეძებს. ისინი თითქმის ყველა Linux-ის Unity-ის სერვერზე ჩნდება და თითქმის არასდროს აქვს მნიშვნელობა.
• The referenced script on this Behaviour is missing კონტენტის გაფრთხილებაა, რომლითაც სტუდიამ თამაში გამოუშვა. გამაღიზიანებელია, მაგრამ არა ფატალური.

მნიშვნელოვანი ხაზები მოგვიანებით მოდის: NullReferenceException, რომელიც ყოველ კადრში მეორდება, DllNotFoundException, ყველაფერი, სადაც ნახსენებია SteamAPI_Init-ის ჩავარდნა, და ბოლო ხაზები პროცესის დასრულებამდე. როგორ წავიკითხოთ სერვერის კონსოლი აჩვენებს, როგორ იკითხო ჩავარდნიდან ზემოთ.

ფაილები: რა ინახება _Data საქაღალდეში#

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

server/  valheim_server.x86_64      the player binary  UnityPlayer.so             the engine  valheim_server_Data/    Managed/                 C# assemblies (Mono builds only)      Assembly-CSharp.dll    the game's own code    MonoBleedingEdge/        the Mono runtime    Plugins/                 native libraries (Steamworks and others)    globalgamemanagers       engine settings baked at build time    *.assets, *.resS         game content  linux64/steamclient.so     Steam client library for the server  steam_appid.txt            which Steam app this is

_Data-ში არაფერია ისეთი კონფიგურაცია, რომელიც უნდა დაარედაქტირო. ეს თავად თამაშია და SteamCMD მას შემდეგი განახლებისას გადააწერს (validate-ით გაშვებისას ყველაფერს, რაც შეცვალე, "შეაკეთებს"). პარამეტრები, save-ები, ბანების სიები და მოდების კონფიგები სხვაგან ინახება - გაშვების არგუმენტებში, კონფიგ-ფაილში, რომელსაც თამაში სერვერის ძირიდან კითხულობს, ან save-ების საქაღალდეში. Save-ის ადგილი თამაშზეა დამოკიდებული და ხშირად ნაგულისხმევად იმავე დამალულ .config/unity3d ან AppData\LocalLow გზაზეა, სადაც ლოგი, ამიტომაც ბევრი თამაში გთავაზობს არგუმენტს მის გადასატანად (-savedir Valheim-ში, +server.identity Rust-ში, UserDataFolder 7 Days to Die-ს კონფიგში). სათამაშო სერვერის save ფაილები მათ ჩამოთვლის.

steam_appid.txt ცალკე ხსენებას იმსახურებს. Steamworks მას კითხულობს, რომ გაიგოს, რომელი აპლიკაციის სახელით მუშაობს. თუ ის აკლია ან არასწორ id-ს შეიცავს, SteamAPI_Init() ჩავარდება და სერვერი ან საერთოდ არ გაეშვება, ან Steam-ის ფუნქციების გარეშე გაეშვება, ასე რომ მოთამაშეები ვერც იპოვიან და ვერც შემოვლენ. გაშვების სკრიპტები ხშირად წერს მას ან გაშვებამდე SteamAppId-ს აექსპორტებს; Valheim-ის start_server.sh სწორედ ამას აკეთებს, ამასთან ერთად LD_LIBRARY_PATH=./linux64-ს აყენებს, რომ თანდართული steamclient.so მოიძებნოს.

Mono თუ IL2CPP: რატომ წყვეტს ეს, როგორ იმუშავებს მოდები#

Unity თამაშის C# კოდს ორიდან ერთ-ერთი გზით აკომპილირებს და სერვერის მფლობელისთვის ეს ყველაზე მნიშვნელოვანი დეტალია.

• Mono: თამაშის კოდი .NET ასამბლეების სახით მოდის _Data/Managed-ში და Mono მათ ჩატვირთვისას უშვებს. ეს DLL-ები შეიძლება ჩაიტვირთოს, დათვალიერდეს და დაიპაჩოს. Unity-ის ყველა მომწიფებული მოდინგის ეკოსისტემა - BepInEx 5 Valheim-ისთვის და ბევრი სხვისთვის, Oxide/uMod და Carbon Rust-ისთვის, RocketMod და OpenMod Unturned-ისთვის, EXILED SCP: SL-ისთვის - ამაზეა დამოკიდებული.
• IL2CPP: C# კოდი build-ის დროს C++-ად გარდაიქმნება და ნატიურ კოდად კომპილირდება. Managed საქაღალდე არ არის, მხოლოდ დიდი GameAssembly.so ან GameAssembly.dll და il2cpp_data საქაღალდე. მოდებს უფრო მძიმე ინსტრუმენტები სჭირდება (BepInEx 6, MelonLoader), რომლებიც proxy ასამბლეებს აგენერირებს, და განახლებებისას უფრო ხშირად ფუჭდება.

რომელი გაქვს, შეხედვითაც გაიგებ: DLL-ებით სავსე Managed საქაღალდე ნიშნავს Mono-ს, GameAssembly - IL2CPP-ს. შეამოწმე, სანამ მოდებიან სერვერს დაგეგმავ. თამაშს, რომელიც სერვერზე Mono-ა, კლიენტზე კი IL2CPP (ესეც ხდება), სერვერის მხარის plugin-ები მაინც შეიძლება დაუყენო, მაგრამ კლიენტის მოდები სხვა წესებით მუშაობს.

Mono-ს ჩვეულებრივი მოდების ჩამტვირთავები თავს Doorstop-ით ინექცირებენ - ეს პატარა ნატიური ბიბლიოთეკაა, რომელიც თამაშის კოდამდე ეშვება. ამიტომაა, რომ BepInEx Valheim-ისთვის სხვა გაშვების სკრიპტით და doorstop_libs საქაღალდით მოდის: სკრიპტი გარემოს ცვლადებს აყენებს (Linux-ზე LD_PRELOAD), რომ ჩამტვირთავი პირველი გაეშვას. თუ მოდებიანი სერვერი ეშვება, მაგრამ არც ერთ მოდს არ ტვირთავს, გაშვების ბრძანება თითქმის ყოველთვის ისევ vanilla-ა. Valheim-ის დეტალები Valheim-ის მოდები BepInEx-ით სერვერზე-შია, ხოლო მოდების ჩატვირთვის რიგი დამოკიდებულებებს განიხილავს, როცა ჩამტვირთავი უკვე მუშაობს.

მეხსიერება, CPU და ნაკადები#

Unity-ის სერვერებს ცნობადი რესურსების პროფილი აქვს და მისი ცოდნა არასწორი განახლების ყიდვისგან დაგიცავს.

ერთი დატვირთული ნაკადი. Unity თამაშის ლოგიკას მთავარ ნაკადზე უშვებს. ფიზიკას, job-ებს და ქსელის ნაწილს შეუძლია დამხმარე ნაკადები გამოიყენოს და რამდენიმე სტუდიამ მძიმე სამუშაო მთავარი ნაკადიდან გაიტანა, მაგრამ პრაქტიკაში Unity-ის სერვერის კადრის დროს ერთი ბირთვი განსაზღვრავს. ტაქტური სიხშირე ბირთვების რაოდენობაზე მნიშვნელოვანია. თუ პანელის გრაფიკი 2-ბირთვიან გეგმას 50%-ზე აჩვენებს და მოთამაშეები ლაგს უჩივიან, ეს ნიშნავს ერთ ბირთვს 100%-ზე და ერთს - უქმად. სათამაშო სერვერის CPU-ს დატვირთვის წაკითხვა ამ არითმეტიკას ხსნის.

მეხსიერება, რომელიც იზრდება. Mono იყენებს garbage collector-ს, რომელიც მეხსიერებას ოპერაციულ სისტემას იშვიათად უბრუნებს, თამაშები კი კონტენტს მაშინ ტვირთავს, როცა მოთამაშეები სამყაროს იკვლევენ. Unity-ის სერვერი, რომელიც 2 GB-ით დაიწყო და სამი დღის შემდეგ 4 GB-ზეა, როგორც წესი, ნორმალურად იქცევა - თუმცა თამაშის კოდში გაჟონვებიც ხშირია. ორივე შემთხვევაში სტანდარტული პასუხი დაგეგმილი რესტარტია მშვიდ საათში. სათამაშო სერვერის მეხსიერების გაჟონვა ხსნის, როგორ განასხვაო ეს ორი.

Garbage collection-ის პაუზები. როცა collector მუშაობს, დიდ heap-ზე მას შეუძლია მთავარი ნაკადი ათეულობით მილიწამით გააჩეროს, რასაც მოთამაშეები რეგულარულ შეფერხებად გრძნობენ. Unity-ის ინკრემენტული collector-ი (2019-დან ხელმისაწვდომი) სამუშაოს ანაწილებს, მაგრამ ჩართავს თუ არა მას თამაში, სტუდიის არჩევანია და არა შენი.

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

Linux, Steam-ის ბიბლიოთეკები და შეცდომები, რომლებსაც შეხვდები#

Unity-ის სერვერების უმეტესობა ნატიური Linux build-ით მოდის, რაც კარგი ამბავია - Wine არ გჭირდება. The Forest და Sons of the Forest ცნობილი გამონაკლისებია: მათი სერვერები მხოლოდ Windows-ისაა და Linux-ზე Wine-ით ეშვება. ნატიური build-ები რამდენიმე ნატიურ ბიბლიოთეკაზეა დამოკიდებული და რომელიმეს არარსებობა იწვევს იმ შეცდომებს, რომლებიც მხარდაჭერის თემებს ავსებს.

dlopen failed trying to load: steamclient.so[S_API FAIL] SteamAPI_Init() failed; SteamAPI_IsSteamRunning() failed.

სერვერი ვერ პოულობს Steam-ის კლიენტის ბიბლიოთეკას. Steamworks მას ეძებს ~/.steam/sdk64/steamclient.so-ში (და sdk32-ში 32-ბიტიანი build-ებისთვის). ჩვეულებრივი გამოსავალია, დააკოპირო ის, რაც SteamCMD-მ დააყენა:

$ mkdir -p ~/.steam/sdk64$ cp ~/steamcmd/linux64/steamclient.so ~/.steam/sdk64/

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

სხვა შეცდომები, რომლებიც თამაშზე კი არა, პლატფორმაზე მიუთითებს:

• `DllNotFoundException` კონკრეტული ბიბლიოთეკისთვის: ნატიური დამოკიდებულება აკლია. მინიმალურ დისტრიბუტივზე ეს ხშირად 32-ბიტიანი ბიბლიოთეკაა, ან libatomic, libpulse და მსგავსი, რომელზეც თამაში ლინკდება, აუდიოს გარეშეც კი. რაც უნდა დააყენო, შეტყობინებაში მითითებული სახელია.
• `Segmentation fault` გაშვებისას: ხშირად Unity-ის არასწორი ვერსიისთვის აწყობილი მოდების ჩამტვირთავი ან დაზიანებული ინსტალაცია. გაუშვი SteamCMD validate-ით და სცადე ხელახლა მოდების გარეშე.
• პროცესი მყისიერად ითიშება ლოგის გარეშე: ლოგი სადღაც იქ წავიდა, სადაც არ იყურები. დაამატე -logFile ცხადი გზით, ისევ გაუშვი და წაიკითხე ეს ფაილი.

ჰოსტინგის პანელზე ეს ბიბლიოთეკები image-ის ნაწილია, ამიტომ პირველი ორი იშვიათია; მესამე ის არის, რასაც, სავარაუდოდ, შეხვდები. თუ საკუთარ მანქანას უვლი, Linux თუ Windows სათამაშო სერვერებისთვის განიხილავს, როდის აკლია Linux build-ი და როდის გჭირდება Wine.

განახლებები და ვერსიები#

Unity-ის სერვერები SteamCMD-ით მოდის, როგორც ნებისმიერი სხვა Steam-ის სერვერი, ამიტომ განახლება არის app_update <appid> validate. ამის თავზე Unity-ისთვის სპეციფიკური ორი საკითხია.

პირველი, ძრავის ვერსია შეიძლება თამაშის განახლებასთან ერთად შეიცვალოს. როცა სტუდია Unity-ის ერთი რელიზიდან მეორეზე გადადის, ყველა ნატიურ მოდების ჩამტვირთავს და ყველა IL2CPP proxy-ს განახლება სჭირდება, და ყველაფერი ერთდროულად ფუჭდება და არა თითო plugin-ი. Patch notes ამას იშვიათად ახსენებს; ლოგში Initialize engine version ხაზი ახსენებს. ჩაინიშნე განახლებამდე და შეადარე შემდეგ.

მეორე, თითქმის ყველა Unity-ის თამაშში კლიენტი და სერვერი ზუსტად უნდა ემთხვეოდეს, რადგან ქსელის პროტოკოლი თამაშის საკუთარი კოდიდან გენერირდება. ერთი build-ის სხვაობაც კი საკმარისია, რომ კავშირი უარყოფილი იყოს. როცა პაჩი გამოდის, სერვერი უნდა განახლდეს, სანამ ახალი კლიენტით ვინმე შემოვა - მოდებიანი სერვერი კი თავის ჩამტვირთავს უნდა დაელოდოს. ოპერაციების რიგი განახლების დღის ჩამონათვალშია, ხოლო SteamCMD-ის app id-ები და beta branch-ები აღწერს, როგორ დატოვო სერვერი ძველ build-ზე, როცა თამაში ამის საშუალებას იძლევა.

FAQ#

მჭირდება GPU Unity-ის სათამაშო სერვერის გასაშვებად?

არა. -batchmode -nographics-ით Unity ნულოვან გრაფიკულ მოწყობილობას ქმნის და რენდერინგს არ აკეთებს. სერვერები ჩვეულებრივ, მხოლოდ CPU-იან მანქანებზე მუშაობს და ყველა ჰოსტინგი მათ სწორედ ასე უშვებს. თუ სერვერი გრაფიკას უჩივის, ორი გადამრთველიდან ერთ-ერთი აკლია.

რატომ იკავებს ჩემი Unity-ის სერვერი მთელ ბირთვს, როცა არავინაა ონლაინ?

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

შემიძლია BepInEx ნებისმიერ Unity-ის სერვერზე გამოვიყენო?

BepInEx 5 Mono build-ებზე მუშაობს. IL2CPP build-ებს BepInEx 6 ან სხვა ჩამტვირთავი სჭირდება და მხარდაჭერა უფრო არასტაბილურია. სანამ ამაზე დაგეგმავ, შეამოწმე, არის თუ არა DLL-ებით სავსე Managed საქაღალდე. ზოგ თამაშს საკუთარი სასურველი ფრეიმვორკი აქვს (Oxide ან Carbon Rust-ისთვის, RocketMod ან OpenMod Unturned-ისთვის), რომელიც ზოგად ჩამტვირთავზე უკეთესია.

სად ვიპოვო ლოგი, თუ კონსოლი არაფერს აჩვენებს?

მოძებნე Player.log Linux-ზე ~/.config/unity3d/<Company>/<Product>/-ში ან Windows-ზე AppData\LocalLow\<Company>\<Product>\-ში, ან დაამატე -logFile შენ მიერ არჩეული გზით. პანელზე egg-ი გამოსავალს, როგორც წესი, უკვე კონსოლში აგზავნის.

Unity-ის სერვერი Unreal-ისაზე ნელია?

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