Arma 3-ის headless client-ები AI-ის გადასატანად

headless client (HC) არის Arma 3-ის სერვერის binary-ის მეორე ასლი, გაშვებული -client-ით, რომელიც შენს სერვერს უხილავ მოთამაშედ უერთდება და იმ AI-ს ამუშავებს, რომელსაც მისია მას გადასცემს. ის მხოლოდ მაშინ გეხმარება, როცა სამი რამ ერთდროულად სრულდება: სერვერის frame time-ს სწორედ AI ჭამს, მისია lobby-ში headless client-ის სლოტს სვამს, და რაღაც - მისიის კოდი, ACE-ის headless კომპონენტი ან სხვა სკრიპტი - AI ჯგუფებს მასზე რეალურად გადაიტანს. თუ ეს სამივე სწორადაა, მუდმივი მისია ასობით AI-ით სესიის სიღრმეშიც სათამაშო სერვერის FPS-ს ინარჩუნებს; თუ ერთი მათგანი მაინც არასწორადაა, მეხსიერება და CPU-ის წილი დახარჯე პროცესზე, რომელიც სლოტში ზის და არაფერს აკეთებს.

სერვერის მხარის გადამრთველები (headlessClients[], localClient[]) განხილულია Arma 3-ის server.cfg-ის გზამკვლევში. ეს სტატია ყველაფერზეა მათ გარშემო: რატომ არის locality მთელი ამბავი, როგორ ჩასვა სლოტი მისიაში, AI-ის გადატანის სამი გზა, ერთზე მეტი HC-ის გაშვება და როგორ დაამტკიცო, რომ იმუშავა.

Locality: რატომ შეუძლია headless client-ს საერთოდ დახმარება#

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

ნაგულისხმევად, რედაქტორში განთავსებული ან სერვერის სკრიპტებით შექმნილი AI სერვერისთვისაა local. ასე რომ, სერვერის მთავარი thread მისიის ყოველი AI ერთეულის მაგივრად ფიქრობს, ყველაფერ იმასთან ერთად, რასაც ისედაც აკეთებს, Arma-ს სიმულაცია კი ძირითადად ერთ thread-ზე მუშაობს. როცა AI-ის რაოდენობა იზრდება, სერვერის FPS ეცემა, და როცა სერვერის FPS ეცემა, ყველაფერი ერთბაშად უარესდება: AI გვიან რეაგირებს, ტექნიკა ჭედავს, მოთამაშეებს desync ემართებათ.

headless client უბრალოდ კიდევ ერთი მანქანაა, რომლისთვისაც AI შეიძლება იყოს local. ეს არის სრული Arma-ს კლიენტი რენდერინგისა და ხმის გარეშე, ამიტომ მისი მთელი frame time იმ ერთეულების სიმულაციას ხმარდება, რომლებსაც ფლობს. გადაიტანე მასზე ასი AI და ეს ასი ერთეული სერვერს ქსელური განახლებების გარდა აღარაფერი უჯდება.

ამ მოდელიდან სამი შედეგი გამომდინარეობს, რომლებიც HC-ის პრობლემების უმეტესობას ხსნის:

• AI თავისით არ გადადის. ერთეული იქ რჩება local, სადაც შეიქმნა, სანამ რაღაც მასზე setGroupOwner-ს არ გამოიძახებს. HC-ის მიერთება არსებულ AI-ში არაფერს ცვლის.
• Locality ჯგუფის დონეზეა. მთელ ჯგუფებს გადაიტან, და ჯგუფის ერთეულები, waypoint-ები და ტექნიკა, რომელსაც ისინი მართავენ, მასთან ერთად გადადის.
• სკრიპტები იქ მუშაობს, სადაც მუშაობს. სერვერზე არსებული კოდი, რომელიც HC-ზე გადატანილ ერთეულს მართავს, შეიძლება გაჩერდეს, რადგან ბევრი ბრძანება მხოლოდ იქ მოქმედებს, სადაც ერთეული local-ია.

ღირს თუ არა? ჯერ გაზომე, მერე ააწყვე#

headless client უფასო არ არის. ეს არის Arma-ს მეორე პროცესი იმავე მოდების სიით, ამიტომ საკუთარი მეხსიერება სჭირდება - ზომიერი მოდების ნაკრებით ჩვეულებრივ 2-დან 4 GB-მდე - და საკუთარი CPU-ის დრო. თუ შენი სერვერის პრობლემა AI არ არის, ის არაფერს გაძლევს.

ჯერ გაზომე. შედი ადმინად და გაუშვი #monitor 5, რომელიც ჩატში ყოველ ხუთ წამში სერვერის FPS-ს და მასთან დაკავშირებულ რიცხვებს ბეჭდავს. შემდეგ შეადარე:

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

სერვერის მხარე, მოკლედ#

server.cfg-ში ორი მასივი აიძულებს სერვერს, HC-ს სწორად მოეპყრას:

headlessClients[] = {"127.0.0.1"};localClient[] = {"127.0.0.1"};

headlessClients[] ჩამოთვლის მისამართებს, რომლებსაც headless client-ის სლოტების დაკავების უფლება აქვთ. localClient[] მისამართებს local-ად მონიშნავს, რაც სახლის კავშირზე მყოფი მოთამაშეებისთვის განკუთვნილ გამტარუნარიანობის ლიმიტებს ხსნის - მის გარეშე HC მოთამაშესავით იზღუდება და AI-ის განახლებები რიგში დგება. თუ HC სხვა მანქანაზე მუშაობს, ორივე მასივს loopback-ის ნაცვლად იმ მანქანის მისამართი სჭირდება.

HC იმავე binary-ით ეშვება:

$ ./arma3server_x64 -client -connect=127.0.0.1 -port=2302 \    -password="joinpassword" -profiles=hc1 -name=hc1 \    -mod="@cba_a3;@ace" -world=empty -nosound

რას აკეთებს თითოეული ნაწილი:

• -connect და -port სერვერის სათამაშო პორტზე მიუთითებს.
• -password არის შესვლის პაროლი, თუ სერვერს აქვს. არა ადმინის პაროლი.
• -mod ზუსტად უნდა ემთხვეოდეს სერვერის კლიენტური მოდების სიას. -serverMod-ის ელემენტები საჭირო არ არის.
• -profiles და -name HC-ს საკუთარ პროფილის საქაღალდეს და ლოგს აძლევს, რომ მისი .rpt ფაილი სერვერისას არ აერიოს.

HC უერთდება, lobby-ში ჩნდება და headless client-ის სლოტს იკავებს, თუ მისიას აქვს. თუ არ აქვს, სლოტების ეკრანზე ზის.

სლოტის ჩასმა მისიაში#

"ჩემი HC არაფერს აკეთებს" ტიპის შეტყობინებების უმეტესობა სწორედ ამ ნაბიჯზე დადის. მისია უნდა შეიცავდეს headless client-ის ერთეულს, და ეს ერთეული playable უნდა იყოს.

Eden-ის რედაქტორში headless client არის ლოგიკური ერთეული სახელად Headless Client. განათავსე თითო ყოველ HC-ზე, რომლის გაშვებასაც აპირებ, და თითოეულისთვის:

1. მიეცი ცვლადის სახელი - HC1, HC2, HC3. სკრიპტები HC-ს ამ სახელით პოულობენ.
2. მონიშნე Playable. არა-playable HC ერთეული სლოტად არასოდეს შემოთავაზდება.
3. შეინახე და მისია multiplayer-ში გაიტანე, რომ mpmissions-ში მდებარე .pbo მას შეიცავდეს.

HC სლოტს მიერთებისას ავტომატურად იკავებს; მისი მინიჭება არავის სჭირდება. სკრიპტებში ცვლადის სახელი შემდეგ HC-ის ობიექტზე მიუთითებს, ხოლო owner HC1 (სერვერზე შეფასებული) მის client ID-ს აბრუნებს - რიცხვს, რომელიც setGroupOwner-ს სჭირდება.

დიდ საზოგადოებრივ მისიებს, როგორიცაა Antistasi და Liberation, headless client-ის სლოტები უკვე განთავსებული მოყვება. Workshop-ის მისიას, რომელიც აღწერაში headless client-ებს არ ახსენებს, თითქმის დანამდვილებით არ აქვს.

AI-ის headless client-ზე გადატანის სამი გზა#

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

1. შექმენი AI თავიდანვე HC-ზე

ყველაზე სუფთა მიდგომა მისიებისთვის, რომლებსაც თავად წერ: შექმნის კოდი თავად HC-ზე გაუშვი, რომ AI დაბადებიდან იქ იყოს local და არასოდეს გადავიდეს.

// true only on a headless clientif (!hasInterface && !isServer) then {    [] execVM "scripts\spawnPatrols.sqf";};// fall back to the server if no HC is connectedif (isServer && {isNil "HC1" || {isNull HC1}}) then {    [] execVM "scripts\spawnPatrols.sqf";};

hasInterface გამოყოფილ სერვერებსა და headless client-ებზე false-ია; isServer მხოლოდ სერვერზეა true. ეს კომბინაცია HC-ს ამოიცნობს. სარეზერვო ვარიანტს მნიშვნელობა აქვს: მისიას, რომელიც AI-ს მხოლოდ HC-ზე ქმნის, იმ საღამოს, როცა HC ვერ მიუერთდება, მტრები საერთოდ არ ეყოლება.

2. გადაიტანე ჯგუფები სერვერიდან setGroupOwner-ით

რედაქტორში განთავსებული ან არსებული სერვერის სკრიპტებით შექმნილი AI გადაიტანე. setGroupOwner მხოლოდ სერვერზე მუშაობს, იღებს ჯგუფს და client ID-ს და ჯგუფს მის ერთეულებთან ერთად გადააქვს.

[] spawn {    // wait until the HC has connected and has a client ID    waitUntil { sleep 5; !isNil "HC1" && {!isNull HC1} && {owner HC1 > 2} };    sleep 30; // let mission init finish first    private _hc = owner HC1;    {        private _grp = _x;        if (local _grp            && {({isPlayer _x} count units _grp) == 0}            && {!(_grp getVariable ["keepOnServer", false])}) then {            _grp setGroupOwner _hc;        };    } forEach allGroups;};

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

3. მიანდე მოდს

ACE3 შეიცავს headless კომპონენტს, რომელიც AI ჯგუფებს მიერთებულ headless client-ებზე ავტომატურად გადაიტანს და ხელახლა აბალანსებს, როცა HC-ები უერთდებიან ან გადიან. ის CBA-ს addon-ის პარამეტრებიდან კონფიგურირდება: ჩართე, დააყენე გადატანის დაყოვნება და გადაწყვიტე, რა მოხდეს HC-ის გათიშვისას. მას აქვს ჯგუფისა და ერთეულის დონის გამორიცხვის ცვლადი იმისთვის, რაც სერვერზე უნდა დარჩეს; მისი ზუსტი სახელი შენს ვერსიაში ACE-ის დოკუმენტაციაში შეამოწმე. მოდიანი ჯგუფისთვის, რომელიც უკვე ACE-ს იყენებს, ეს ყველაზე ნაკლებად შრომატევადი გზაა და რედაქტორში განთავსებულ და Zeus-ით შექმნილ AI-თანაც მუშაობს.

ძველი მისიები Werthles' Headless Module-ს იყენებენ - რედაქტორის მოდულს, რომელიც იმავე საქმეს აკეთებს. თითო მისიაზე ერთი ავტომატური მექანიზმი აირჩიე; ორი სისტემა, რომელიც ერთსა და იმავე ჯგუფებს გადააადგილებს, ერთმანეთს ებრძვის.

რა ფუჭდება, როცა AI მფლობელს იცვლის#

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

• ლოკალური ეფექტის ბრძანებები. ზოგიერთი ბრძანება მხოლოდ იქ მუშაობს, სადაც ერთეული local-ია. სერვერის ციკლმა, რომელიც doMove-ს, disableAI-ს ან setBehaviour-ს იძახებს HC-ზე გადატანილ ჯგუფზე, შეიძლება ჩუმად არაფერი გააკეთოს. ასეთი კოდი იქ გაუშვი, სადაც ჯგუფი ცხოვრობს, მაგალითად remoteExec-ით, რომელიც groupOwner-ზეა მიმართული, ან ქცევის მთელი სკრიპტი HC-ზე გაუშვი.
• Event handler-ები. addEventHandler-ით დამატებული handler-ები იმ მანქანისთვისაა local, რომელმაც ისინი დაამატა, და რამდენიმე მათგანი მხოლოდ იქ ირთვება, სადაც ერთეული local-ია. სერვერის მხარის Killed ან Hit handler გადატანილ ერთეულზე შეიძლება აღარ ამოქმედდეს. გამოიყენე multiplayer ვარიანტები (addMPEventHandler MPKilled-ით, MPHit-ით) ან handler-ები მფლობელ მანქანაზე დაამატე.
• გადატანამდე გამოყენებული პარამეტრები. AI-ის ზოგიერთი მდგომარეობა, რომელიც სერვერზე გადატანამდე დაყენდა, გადატანას ვერ უძლებს. skill, disableAI და ქცევა გადატანის შემდეგ, ახალ მფლობელზე დააყენე.
• გვამები და გასუფთავება. Garbage collection კვლავ სერვერზე მუშაობს. ეს ნორმალურია, მაგრამ გასუფთავების სკრიპტი, რომელიც წაშლამდე local-ს ამოწმებს, HC-ის კუთვნილ ერთეულებს გამოტოვებს.

როცა მისია მხოლოდ მიერთებული HC-ით იქცევა უცნაურად, ეს ოთხი პუნქტი შენი შემოწმების სიაა.

რამდენიმე headless client და დინამიკური სიმულაცია#

ერთი HC მეორე thread-ია. რამდენიმე HC რამდენიმე thread-ია, და AI-ის ძალიან დიდი რაოდენობის მისიები ჯგუფებს HC1-ზე, HC2-სა და HC3-ზე ანაწილებენ - არეალის, მხარის მიხედვით ან რიგრიგობით. თითოეულს სჭირდება საკუთარი playable სლოტი, საკუთარი პროცესი საკუთარი -profiles-ით და -name-ით, და მეხსიერებისა და CPU-ის საკუთარი წილი.

მეტი HC მხოლოდ მაშინ გეხმარება, თუ მათ გასაშვებად ბირთვები არსებობს. საკუთარ აპარატურაზე ეს ფიზიკური ბირთვების საკითხია. ჰოსტინგის სერვერზე CPU ჩვეულებრივ მკაცრი ლიმიტია - RE:NODE-ზე ყოველი სერვერი ერთი კონტეინერია, რომელიც შენ მიერ ნაყიდ წილამდეა შეზღუდული - ამიტომ იმავე ლიმიტში გაშვებული headless client მისთვის სერვერს ეჯიბრება. ის მაინც გეხმარება, როცა სერვერი ერთ thread-ზეა გაჭედილი და ლიმიტის ნაწილი გამოუყენებელია, რაც ყველაზე ხშირი შემთხვევაა, მაგრამ ვერ შექმნის CPU-ს, რომელიც გეგმაში არ არის. მეორე HC იმავე ლიმიტში იშვიათად ჯობს ერთს.

headless client-ების დამატებაა დინამიკური სიმულაცია, რომელიც თამაშში 1.74-დან არის ჩაშენებული. ის ყინავს AI ჯგუფებს, რომლებიც ნებისმიერი მოთამაშისგან შორს არიან, და აღვიძებს, როცა ვინმე უახლოვდება:

enableDynamicSimulationSystem true;"Group" setDynamicSimulationDistance 1500;{ _x enableDynamicSimulation true } forEach allGroups;

გაყინული ჯგუფი თითქმის არაფერი ჯდება, სადაც არ უნდა იყოს local. დიდ რუკაზე, სადაც AI-ის გარნიზონები ყველგანაა, დინამიკური სიმულაცია ხშირად უფრო მეტ დატვირთვას ხსნის, ვიდრე headless client, და ორივე ერთად დიდი მუდმივი მისიების სტანდარტული კონფიგურაციაა. ჩართე ის ჯგუფზე ნებისმიერი გადატანის შემდეგ.

როგორ დაამტკიცო, რომ იმუშავა#

ნუ ენდობი, რომ მუშაობს მხოლოდ იმიტომ, რომ HC lobby-შია. სამი რამ შეამოწმე.

1. ჯგუფები მართლა გადავიდა. debug კონსოლში, სერვერზე შესრულებით, დათვალე ჯგუფები მფლობელის მიხედვით: {groupOwner _x == owner HC1} count allGroups. ნული ნიშნავს, რომ არაფერი გადასულა.
2. HC უმკლავდება. აიძულე HC, საკუთარი frame rate და ჯგუფების რაოდენობა თავის .rpt-ში ჩაწეროს:

if (!hasInterface && !isServer) then {    [] spawn {        while {true} do {            diag_log format ["HC fps %1, local groups %2",                diag_fps, {local _x} count allGroups];            sleep 60;        };    };};

1. სერვერი გაუმჯობესდა. გაუშვი #monitor 5 მისიის ერთსა და იმავე მომენტში HC-ით და მის გარეშე. თუ სერვერის FPS არ შეცვლილა, ვიწრო ადგილი AI არ ყოფილა და HC შეგიძლია მოაშორო.

HC, რომლის საკუთარი FPS ჩამოიშალა, სერვერის ნაცვლად თავად ხდება ვიწრო ადგილი: მისი კუთვნილი AI ისევე ცუდად რეაგირებს, როგორც ადრე. სწორედ ამ დროს უნდა გაყო დატვირთვა ორ HC-ზე, შეამცირო AI-ის რაოდენობა ან დინამიკურ სიმულაციას მეტად დაეყრდნო. HC-ის .rpt ლოგები სერვერის ლოგებთან ერთად შეინახე; ლოგები, რომელთა შენახვაც ღირს ხსნის, რამდენ ხანს და რატომ.

პრობლემების მოგვარება#

HC lobby-ში არასოდეს ჩნდება. მისი მისამართი headlessClients[]-ში არ არის, მოდების სია არ ემთხვევა, ან არასწორ პორტზე მიუთითებს. წაიკითხე HC-ის საკუთარი .rpt - ის წერს, რატომ ვერ მოხერხდა მიერთება.

HC სლოტის არჩევაზე ზის. მისიას playable headless client-ის ერთეული არ აქვს, ან HC-ის ყველა სლოტი უკვე დაკავებულია.

HC უერთდება, მაგრამ არაფერს ფლობს. AI-ს არაფერი გადაიტანს. დაამატე setGroupOwner ციკლი, ჩართე ACE-ის headless კომპონენტი ან AI HC-ზე შექმენი.

HC-ზე მყოფი AI ადგილზე დგას. waypoint-ები ან ქცევის სკრიპტები სერვერზე მუშაობს და აღარ მოქმედებს. სკრიპტი მფლობელზე გადაიტანე.

სერვერის მხარის მკვლელობების აღრიცხვა გაფუჭდა. Event handler-ები local-ია. გამოიყენე MPKilled ან handler HC-ზე დაამატე.

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

HC ითიშება და მტრები ქრებიან. როცა HC გადის, მისი AI სერვერს უბრუნდება. თუ ამის შემდეგ სერვერს უჭირს, ეს მოსალოდნელია; თუ AI იშლება, რომელიღაც სკრიპტი HC-ის ჯგუფებს გათიშვისას ასუფთავებს.

FAQ#

მჭირდება თუ არა ცალკე Arma 3-ის ლიცენზია headless client-ისთვის?

არა. headless client არის უფასო გამოყოფილი სერვერის binary, გაშვებული კლიენტის რეჟიმში, და იმავე გზით იტვირთება, როგორც სერვერი. მას სერვერის იგივე მოდები სჭირდება და მეტი არაფერი.

რამდენი headless client უნდა გავუშვა?

ერთი, სანამ არ გაზომავ, რომ გადატვირთულია. მეორე მხოლოდ მაშინ დაამატე, როცა პირველი HC-ის საკუთარი FPS დატვირთვისას ეცემა და კიდევ ერთი პროცესის გასაშვებად CPU ხელმისაწვდომია. ჯგუფების უმეტესობას ერთზე მეტი არასოდეს სჭირდება.

გამოასწორებს headless client desync-ს?

მხოლოდ იმ შემთხვევაში, თუ desync-ს იწვევს ის, რომ სერვერს AI-ის გამო frame time აღარ ჰყოფნის. მოთამაშის კავშირით გამოწვეულ ქსელურ desync-ზე ან მეხსიერების ნაკლებობის მქონე სერვერზე ის გავლენას არ ახდენს.

უნდა იყოს მისია headless client-ისთვის დაწერილი?

მას playable headless client-ის სლოტი სჭირდება. AI-ის გადატანა შეუძლია მისიას, ACE-ის headless კომპონენტს ან სხვა სკრიპტს, ამიტომ HC-ის კოდის არმქონე მისიაც შეიძლება მოიგოს, თუ სლოტს და ავტომატურ ბალანსერს დაამატებ.

შეიძლება headless client სხვა მანქანაზე მუშაობდეს?

კი. ჩაწერე იმ მანქანის მისამართი headlessClients[]-სა და localClient[]-ში, გახსენი მათ შორის გზა და AI-ის განახლებებზე დამატებით დაყოვნებას ელოდე. იმავე მანქანაზე უფრო მარტივია და ჩვეულებრივ უფრო სწრაფიც.

რა ემართება AI-ს, როცა headless client ვარდება?

მისი ჯგუფები ავტომატურად სერვერს უბრუნდება. მისია გრძელდება, და სერვერი იმ დატვირთვას ატარებს, რასაც ადრე ატარებდა. კარგი მისია ან ბალანსერი მათ ხელახლა გადაიტანს, როცა HC ხელახლა მიუერთდება.