RE:NODE

სახელმძღვანელოები11 წუთის საკითხავი

Rust server.cfg და convar-ები: decay და upkeep

სად ინახავს Rust server.cfg-ს და users.cfg-ს, როგორ იტვირთება convar-ები და რომელი პარამეტრებია მნიშვნელოვანი - სია, PvE, AFK kick, decay, upkeep - და რას აკეთებს თითოეული.

0 მკითხველი

Rust-ის სერვერი convar-ებით კონფიგურირდება - კონსოლის ცვლადებით, როგორიცაა server.hostname ან decay.scale - ხოლო ფაილი, რომელიც მათ ყოველ გაშვებაზე აყენებს, არის server/<identity>/cfg/server.cfg. ყოველი ხაზი convar-ი და მნიშვნელობაა, ზუსტად ისე, როგორც კონსოლში აკრეფდი, წინ +-ის გარეშე. მხოლოდ გაშვებისას წაკითხული მნიშვნელობები (პორტები, identity, რუკის seed და ზომა) ამის ნაცვლად გაშვების ხაზზე უნდა იყოს. ადმინებისა და ბანების სიები გვერდით, users.cfg-სა და bans.cfg-ში ცხოვრობს და მათ server.writecfg წერს. ასობით convar-იდან ტიპური სერვერისთვის ოციოდეა მნიშვნელოვანი, ხოლო ისინი, რომლებიც სერვერის თამაშის წესს ცვლის - უპირველეს ყოვლისა decay და upkeep - იმაზე მეტ ფიქრს იმსახურებს, ვიდრე ჩვეულებრივ ეთმობა. ეს სტატია მათ ჩამოთვლის და ხსნის, რას აკეთებს თითოეული.

სად ინახავს Rust კონფიგურაციას#

ყველაფერი იმ identity საქაღალდეში ცხოვრობს, რომელსაც გაშვების ხაზზე +server.identity ასახელებს. identity-ით main:

ფაილივინ წერსრას შეიცავს
server/main/cfg/server.cfgშენconvar-ებს, რომლებიც ყოველ გაშვებაზე სრულდება
server/main/cfg/users.cfgserver.writecfgownerid და moderatorid ხაზებს
server/main/cfg/bans.cfgserver.writecfgbanid ხაზებს
გაშვების ხაზი ან პანელის Startup ჩანართიშენპორტებს, identity-ს, level-ს, seed-ს, სამყაროს ზომას

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

identity საქაღალდეში ცხოვრობს რუკა, save და მოთამაშეების მონაცემთა ბაზებიც, და სწორედ ამიტომ გადაურჩება კონფიგი wipe-ებს: wipe შლის .map, .sav და შერჩეულ .db ფაილებს და არა cfg/-ს. ფაილების სრული სია მოცემულია სტატიაში Rust-ის wipe-ები მოთამაშეების დაკარგვის გარეშე.

როგორ იტვირთება convar-ები და როგორ შეამოწმო მნიშვნელობა#

convar-ის დასაყენებლად სამი ადგილია და ისინი სხვადასხვანაირად იქცევიან:

  1. გაშვების ხაზი, როგორც +convar value. იკითხება სამყაროს ჩატვირთვამდე. ერთადერთი სწორი ადგილი server.port-ის, server.queryport-ის, server.identity-ის, server.level-ის, server.seed-ის, server.worldsize-ისა და RCON-ის პარამეტრებისთვის.
  2. `server.cfg`, როგორც convar value. სრულდება ყოველ გაშვებაზე. სწორი ადგილი ყველაფერი დანარჩენისთვის, რისი შენარჩუნებაც გინდა.
  3. კონსოლი ან RCON, როგორც convar value. მაშინვე მოქმედებს და შემდეგ რესტარტზე ავიწყდება, თუ იგივე ხაზი server.cfg-შიც არ არის.

ყოველი convar პირველი ორი ადგილიდან ზუსტად ერთში დააყენე. მნიშვნელობა, რომელიც გაშვების ხაზზეა დაყენებული და შემდეგ, სხვაგვარად, server.cfg-შიც, ჩატვირთვის თანმიმდევრობით გადაწყდება, ხოლო ადამიანმა, რომელიც ამას მოგვიანებით გამართავს, არ ეცოდინება, რომელ ფაილს ენდოს.

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

code
> decay.scaledecay.scale: "1"> find upkeep

მნიშვნელობების შეცვლა ჩართულ სერვერზე

გეიმპლეისა და სიის convar-ების უმეტესობა კონსოლში დაყენებისთანავე მოქმედებს: hostname სიაში შემდეგ query-ზე ახლდება, decay.scale შემდეგ decay tick-ს ცვლის, server.idlekick შემდეგ უმოქმედობის შემოწმებაზე გამოიყენება. ეს კონსოლს მნიშვნელობის საცდელად სწორ ადგილად აქცევს, სანამ ფაილში ჩაწერ. რამდენიმე რამ ცოცხლად სასარგებლოდ არ იცვლება. პორტები, identity, seed, სამყაროს ზომა და level გაშვებისას ერთხელ იკითხება; კონსოლში მათი დაყენება ან არაფერს აკეთებს, ან არაფერს აკეთებს შემდეგ wipe-მდე. RCON-ის პარამეტრებიც ასეა.

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

სრული server.cfg#

გონივრული საწყისი ფაილი სათემო სერვერისთვის. მნიშვნელობები ბრჭყალებშია, როცა ჰარებს შეიცავს; კომენტარები //-ით დაწყებული ხაზებია.

server/main/cfg/server.cfg
// listingserver.hostname "Longship | EU | Biweekly | Next wipe Thu 15 Oct"server.description "Vanilla rates, 2-week wipes, no zergs over 4.\nDiscord: example.com/discord"server.url "https://example.com"server.headerimage "https://example.com/rust-header.png"server.tags "biweekly,vanilla,eu"// population and savingserver.maxplayers 75server.saveinterval 300// playersserver.idlekick 30server.globalchat true// performancefps.limit 60// decay and upkeep (vanilla)decay.scale 1decay.upkeep true

\n აღწერაში სერვერის ინფორმაციის პანელში ახალ ხაზს იწყებს. header სურათს თითოეული კლიენტი შენი URL-იდან იღებს, ამიტომ ის სადმე სწრაფ და სტაბილურ ადგილას განათავსე; ხშირად დოკუმენტირებული ზომა 512 x 256 პიქსელია.

სიისა და იდენტობის convar-ები#

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

convarრას აკეთებს
server.hostnameსახელი სიაში. მნიშვნელოვანი სიტყვები წინ დასვი
server.descriptionტექსტი სერვერის ინფორმაციის პანელში; მხარს უჭერს \n-ს
server.urlინფორმაციის პანელზე ნაჩვენები ბმული - ჩვეულებრივ შენი Discord ან საიტი
server.headerimageსურათის URL, რომელიც აღწერის ზემოთ ჩანს
server.tagsსიის ტეგების მძიმით გამოყოფილი ჩამონათვალი: wipe-ის რიტმი, სტილი, რეგიონი
server.maxplayersსლოტები. დანარჩენი მოთამაშეები რიგში ელოდებიან

server.tags სიის ფილტრებს მართავს. დასაშვები მნიშვნელობები მოიცავს wipe-ის რიტმს (weekly, biweekly, monthly), სტილს (vanilla, pve, roleplay, creative და კიდევ რამდენიმე) და რეგიონის კოდს; უცნობი ტეგები იგნორირდება. სიას თამაში განსაზღვრავს და ის დროთა განმავლობაში შეიცვალა, ამიტომ ტეგების მოგონების ნაცვლად მიმდინარე ნაკრები შეამოწმე. ტეგები პატიოსნად დასვი: vanilla ტეგიანი სერვერი 5x gather-ით სწორედ ისეთი რამაა, რაზეც მოთამაშეები საჩივარს წერენ.

გეიმპლეის convar-ები#

convarტიპურირას აკეთებს
server.pvefalseმოთამაშეები სხვა მოთამაშეებისგან დაზიანებას არ იღებენ; სანაცვლოდ დაზიანება უკან აირეკლება
server.radiationtrueრადიაცია monument-ებზე. გამორთვა monument-ებს უმნიშვნელოს ხდის
server.stabilitytrueნაგებობების მდგრადობის წესები. გამორთვისას ყველაფერს შეუძლია ჰაერში ეკიდოს
server.globalchattrueგლობალური ჩატი ჩართულია; გამორთვა ჩატს ახლომყოფ მოთამაშეებზე ზღუდავს
server.idlekick30წუთები, სანამ უმოქმედო მოთამაშე გაგდებული იქნება; 0 გამორთავს
server.idlekickmode-უმოქმედობის გამო გაგდება ყოველთვის მოქმედებს თუ მხოლოდ სავსე სერვერზე
fps.limitbuild-ის ნაგულისხმევიზღუდავს სერვერის frame rate-ს

ორი გაფრთხილება. server.pve true ვანილა Rust-ის PvE გადამრთველია და ის უხეშია: ის არ უშლის მოთამაშეებს ერთმანეთის ბაზების ძარცვას ან იმ ცხოველების მოკვლას, რომლებზეც სხვა ნადირობს. ნამდვილი PvE სერვერები მას აერთიანებენ ისეთ plugin-ებთან, როგორიცაა TruePVE, და ზონების წესებთან. და server.stability false build სერვერებზე პოპულარულია, მაგრამ ყოველი ნაგებობის ქცევას ცვლის; wipe-ის შუაში მისი ხელახლა ჩართვა შეიძლება ჩამოანგრიოს ბაზები, რომლებიც წუთის წინ კანონიერი იყო.

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

decay და upkeep, სწორად ახსნილი#

decay არის ის, როგორ ასუფთავებს Rust თავს. მის გარეშე რუკაზე ყოველი მიტოვებული ბაზა სამუდამოდ რჩება, entity-ების რაოდენობა მთელი wipe-ის განმავლობაში იზრდება, ახალი მოთამაშეები კი ნანგრევების ლანდშაფტში ჩნდებიან. upkeep გათავისუფლების ფასია: Tool Cupboard-ით დაცული ბაზა ამ cupboard-იდან რესურსებს იხდის, რომ კარგ მდგომარეობაში დარჩეს, და როცა cupboard ცარიელდება, ბაზა იწყებს დაშლას, როგორც ნებისმიერი სხვა ნაგებობა.

მექანიკა, იმ თანმიმდევრობით, რომლითაც ხდება:

  1. ყოველ სამშენებლო ბლოკსა და ბევრ deployable ობიექტს აქვს decay-ის ტაიმერი და მასალა. twig ყველაზე სწრაფად ეცემა, შემდეგ ხე, ქვა, ფურცლოვანი ლითონი და armoured.
  2. ნაგებობის დამფარავი Tool Cupboard upkeep-ს თავისი ინვენტარიდან იხდის. ღირებულება დამოკიდებულია იმაზე, რამდენი ბლოკია და რა მასალისაა, და ბაზის ზრდასთან ერთად არაპროპორციულად იზრდება - დიდი ბაზები ყოველ ბლოკზე დანამატს იხდიან.
  3. სანამ upkeep გადახდილია, ბაზა არ იშლება და ნელ-ნელა აღდგება.
  4. როცა cupboard ვეღარ იხდის, decay იწყება. entity-ები განრიგით კარგავენ სიცოცხლეს, სანამ არ დაიმსხვრევიან.
convarტიპურირას აკეთებს
decay.scale1მთელი decay-ის მამრავლი; 0 decay-ს მთლიანად თიშავს
decay.upkeeptrueიხდის თუ არა Tool Cupboard-ი upkeep-ს
decay.upkeep_period_minutes1440პერიოდი, რომელზეც upkeep-ის ღირებულება ითვლება
decay.upkeep_heal_scale1რამდენად სწრაფად აღდგება upkeep-იანი ნაგებობები
decay.upkeep_inside_decay_scale1-ზე ნაკლებიdecay-ის სიჩქარე შენობაში მყოფი ობიექტებისთვის upkeep-ის გარეშე

ზუსტ ტაიმერებსა და ღირებულების საფეხურებს Facepunch აყენებს და დროდადრო ასწორებს; კონსოლის find decay აჩვენებს convar-ებს, რომლებიც შენს build-ს აქვს.

decay-ის პარამეტრების არჩევა

  • ვანილა (`decay.scale 1`, upkeep ჩართული) - სწორი ნაგულისხმევი. მიტოვებული ბაზები დაახლოებით ერთ დღეში ქრება, entity-ების რაოდენობა მართვადი რჩება, მოთამაშეები კი სწავლობენ cupboard-ის შევსებას.
  • შემცირებული decay (`decay.scale 0.5`) - გონივრული არჩევანი პატარა სერვერებისთვის, სადაც ხალხი კვირაში ორ საღამოს თამაშობს. decay-ის განახევრება არმყოფ მოთამაშეებს მარაგს აძლევს და რუკას გავსების საშუალებას არ აძლევს.
  • decay-ის გარეშე (`decay.scale 0`) - მხოლოდ creative და build სერვერებისთვის, ან მოკლე wipe-ციკლებისთვის, სადაც დასუფთავებას wipe აკეთებს. თვიურ სერვერზე decay-ის გარეშე რუკა თვის ბოლოს ყველა ოდესმე დაწყებულ ბაზას ატარებს და წარმადობა ამის ფასს იხდის.
  • upkeep გამორთული - აშორებს ბაზის შენახვის ღირებულებას, რაც რესურსების ხარჯვის ძირითად წყაროს აქრობს. PvP სერვერებზე ჩვეულებრივ შეცდომაა, PvE ან roleplay სერვერებზე ზოგჯერ სწორი.

რაც არ უნდა აირჩიო, სერვერის აღწერაში თქვი. "Decay 50%" ან "No upkeep" ის ინფორმაციაა, რომლითაც მოთამაშეები წყვეტენ, შეესაბამება თუ არა შენი სერვერი იმას, რამდენად ხშირად შეუძლიათ თამაში, ხოლო მოთამაშე, რომლის ბაზაც დაიშალა სერვერზე, რომელიც მას ლმობიერი ეგონა, წესების წასაკითხად აღარ დაბრუნდება.

სამი საწყისი წერტილი

სერვერების უმეტესობა სამიდან ერთ ფორმას ერგება და convar-ები ფორმიდან გამომდინარეობს.

  • ვანილა სათემო PvP. decay, upkeep, რადიაცია და მდგრადობა ნაგულისხმევზე დატოვე. დააყენე უმოქმედობის გამო გაგდება დაახლოებით 30 წუთზე, გლობალური ჩატი ჩართული დატოვე, ძალისხმევა კი სიის convar-ებსა და გონივრულ სამყაროს ზომაზე დახარჯე. ეს ის კონფიგურაციაა, რომელსაც ოფიციალური სერვერებიდან მოსული მოთამაშეები ელიან, და მისგან გადახვევა ისე, რომ არ თქვა, უარყოფითი შეფასებების მიღების ყველაზე სწრაფი გზაა.
  • PvE ან მშვიდი. server.pve true პლუს PvE plugin ხარვეზებისთვის, decay.scale დაახლოებით 0.5, რომ შაბათ-კვირის მოთამაშეებმა ბაზები შეინარჩუნონ, და უმოქმედობის გამო გაგდება მხოლოდ სავსე სერვერზე. რადიაცია ჩართული რჩება, თორემ monument-ები აზრს კარგავს.
  • build ან creative. decay.scale 0, upkeep გამორთული, ხშირად server.stability false, უმოქმედობის გამო გაგდების გარეშე და wipe მხოლოდ მაშინ, როცა რუკა ივსება. ელოდე, რომ entity-ების რაოდენობა უსაზღვროდ გაიზრდება, და wipe-ის განრიგი ამის გათვალისწინებით დაგეგმე.

wipe-ის შუაში ფორმის შეცვლა ერთადერთი რამაა, რასაც უნდა მოერიდო. decay-ის ან მდგრადობის ხელახლა ჩართვა რუკაზე, რომელიც საპირისპირო წესებით აშენდა, ანგრევს ბაზებს, რომლებიც მოთამაშეებმა კეთილსინდისიერად ააშენეს.

decay წარმადობის ყველაზე იაფი ინსტრუმენტია. რატომ არის entity-ები მთავარი ხარჯი და რატომ სჯობს decay ნებისმიერ დასუფთავების plugin-ს, ხსნის სტატია სერვერის წარმადობა და entity-ების რაოდენობა.

ცვლილებების დისკზე ჩაწერა#

კონსოლში გაკეთებული ცვლილებები ცოცხალი და დროებითია. მათ შესანარჩუნებლად server.cfg-ში ჩაწერე. ადმინებისა და ბანების ცვლილებები სხვაა: ownerid, moderatorid და banid ცვლის სიებს, რომლებსაც სერვერი თავად ინახავს, და ისინი users.cfg-სა და bans.cfg-ში მხოლოდ მაშინ ხვდება, როცა server.writecfg-ს გაუშვებ.

code
ownerid 76561198012345678 "Alice" "owner"moderatorid 76561198087654321 "Bob" "mod"server.writecfg

გადატვირთე server.writecfg-ის გარეშე და ეს მინიჭებები გაქრება. ეს Rust-ის კონფიგურაციის შესახებ ყველაზე ხშირი კითხვაა მხარდაჭერაში. ადმინის დანარჩენი ბრძანებები მოცემულია სტატიაში Rust-ის ადმინისტრატორის ბრძანებები.

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

users.cfg-ის ან bans.cfg-ის ხელით რედაქტირება მუშაობს, სანამ სერვერი გაჩერებულია. ჩართულ სერვერზე თუ შეცვლი, შემდეგი server.writecfg შენს ცვლილებას გადააწერს იმით, რაც სერვერს მეხსიერებაში აქვს.

კონფიგის რედაქტირება პანელზე#

Pterodactyl პანელზე გაშვების ხაზის მნიშვნელობები Startup ჩანართზე ცვლადებად ჩანს და სერვერი ბრძანებას მათგან აწყობს, ასე რომ seed, სამყაროს ზომა და hostname შეიძლება პანელის ველები იყოს და არა შენ მიერ დაწერილი ხაზები. სანამ რამეს server.cfg-ში გააორმაგებ, შეამოწმე, რას აყენებს egg: თუ hostname Startup-ის ცვლადიცაა და server.cfg-შიც არის, ერთ-ერთი იგნორირდება.

RE:NODE-ზე ფაილების მენეჯერი server.cfg-ს ბრაუზერში სინტაქსის გამოკვეთით არედაქტირებს, კონსოლს აქვს ბრძანებების ისტორია და tab-ით შევსება მნიშვნელობების ცოცხლად საცდელად, backup-ის სლოტები კი ექსპერიმენტამდე identity საქაღალდის snapshot-ის გადაღების საშუალებას გაძლევს. Rust RE:NODE-ის თამაშების კატალოგში არ არის, ამიტომ ეს პანელის ზოგადი ფუნქციებია და არა Rust-ის გეგმა; როგორ ერწყმის ნაწილები ერთმანეთს, ხსნის სტატია Pterodactyl პანელის ახსნა.

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

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

hostname ან აღწერა რესტარტის შემდეგ ძველს უბრუნდება. ის მხოლოდ კონსოლში შეიცვალა. ჩაწერე server.cfg-ში.

ადმინები რესტარტზე უფლებებს კარგავენ. ownerid-ის შემდეგ server.writecfg არ გაშვებულა.

აღწერა ერთ ხაზზე ჩანს. გამოიყენე \n ბრჭყალებიან სტრიქონში და არა ნამდვილი ხაზის გადატანები.

სერვერი server.cfg-ს საერთოდ უგულებელყოფს. ის არასწორ identity საქაღალდეშია ან cfg/-ის შიგნით არ არის. შეადარე გაშვების ხაზის identity საქაღალდის სახელს ზუსტად, Linux-ზე რეგისტრის ჩათვლით.

პატარა სერვერზე ბაზები ღამით დაიშალა. ვანილა decay მოთამაშეებთან, რომლებიც კვირაში ორჯერ შემოდიან. შეამცირე decay.scale ან ასწავლე ხალხს cupboard-ის შევსება.

FAQ#

სად არის server.cfg Rust-ის სერვერზე?

server/<identity>/cfg/server.cfg-ში, სადაც <identity> გაშვების ხაზზე +server.identity-ის მნიშვნელობაა. შექმენი cfg საქაღალდე, თუ არ არსებობს.

როგორ გამოვრთო decay Rust-ის სერვერზე?

დააყენე decay.scale 0 server.cfg-ში. გამოიყენე build და creative სერვერებისთვის; ჩვეულებრივ PvP სერვერზე decay-ის შემცირება ჩვეულებრივ სჯობს მის მოხსნას, რადგან სწორედ decay ასუფთავებს მიტოვებულ ბაზებს.

მჭირდება პლუსის ნიშანი server.cfg-ში?

არა. + მხოლოდ გაშვების ხაზის სინტაქსია. server.cfg-ში ყოველი ხაზი convar-ი და მისი მნიშვნელობაა, როგორც კონსოლში აკრეფდი.

როგორ ვიპოვო ყველა convar-ი, რომელსაც Rust მხარს უჭერს?

გამოიყენე find კონსოლში პრეფიქსით, მაგალითად find server. ან find decay. ის ჩამოთვლის შესაბამის ბრძანებებსა და convar-ებს იმ build-იდან, რომელსაც რეალურად უშვებ.

wipe server.cfg-ს აბრუნებს თავდაპირველ მდგომარეობაში?

არა. wipe შლის რუკის, save-ისა და მოთამაშეების მონაცემთა ბაზის ფაილებს. cfg საქაღალდე ხელუხლებელი რჩება, თუ თავად არ წაშლი.


კომენტარები

სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.

0/2000