FiveM OneSync, მოთამაშის სლოტები და culling

OneSync-ის გარეშე FiveM სერვერი 32 მოთამაშით შემოიფარგლება, GTA V-ის საკუთარი peer-to-peer ქსელის გამო. set onesync on-ით სერვერი ობიექტების მთავარი ავტორიტეტი ხდება, ჭერი ბევრად მაღლა იწევს, ვიდრე ნებისმიერ roleplay სერვერს რეალურად შეუძლია გაუძლოს, ხოლო მოთამაშეები მხოლოდ იმას იღებენ, რაც მათ ახლოსაა. ორი რიცხვი, რომელიც შენს რეალურ სლოტების რაოდენობას წყვეტს, სხვაგანაა: შენს Cfx.re key-ზე მიბმული სლოტების დონე (უფასო დონე ისტორიულად 48-ზე ჩერდებოდა) და რამდენ დროს უტოვებს შენი resource-ები მთავარ და sync thread-ებს. ეს პოსტი ხსნის, რას ცვლის OneSync, რომელი convar-ები მართავს მას, culling-სა და routing bucket-ებს, entity lockdown-ს და როგორ აირჩიო სლოტების რაოდენობა, რომელსაც შეინარჩუნებ.

რას ცვლის OneSync სინამდვილეში#

GTA V-ის მულტიპლეერი რამდენიმე ათეული მოთამაშის სესიებისთვის შეიქმნა, სადაც თითოეულ კლიენტს ობიექტების ნაწილი ეკუთვნის და დანარჩენებს მათ შესახებ პირდაპირ ატყობინებს. FiveM OneSync-ის გარეშე ამ მოდელს ინარჩუნებს: სერვერი ტრაფიკს გადასცემს, მაგრამ ვინ რა იცის, თავად თამაშის სინქრონიზაცია წყვეტს, და 32 მოთამაშის ლიმიტი ამის ნაწილია.

OneSync მას სერვერის მხარის მდგომარეობით ცვლის. ყოველ ქსელურ ობიექტს - მოთამაშეებს, მანქანებს, ped-ებს, ობიექტებს - FXServer ადევნებს თვალს და იცის, სად არის თითოეული და რომელ კლიენტს ეკუთვნის ამჟამად. კლიენტები ისევ ასიმულირებენ თავიანთ ობიექტებს, მაგრამ ვინ რის შესახებ მიიღებს განახლებებს, სერვერი წყვეტს. აქედან ოთხი პრაქტიკული შედეგი გამომდინარეობს:

• 32-ზე მეტი სლოტი შესაძლებელი ხდება. ძრავის ჭერი OneSync-ით ოთხნიშნა რიცხვია. ის არავინ უნდა გამოიყენოს.
• სერვერი ყველაფერს ხედავს. სერვერის სკრიპტებს შეუძლიათ ნებისმიერი მოთამაშის ped-ისა და კოორდინატების წაკითხვა GetPlayerPed(source)-ით და GetEntityCoords-ით, რაც OneSync-ის გარეშე მხოლოდ კლიენტზე მუშაობდა.
• კლიენტები მხოლოდ იმას ხედავენ, რაც ახლოსაა. culling-ის რადიუსს მიღმა მყოფი მოთამაშეები და ობიექტები კლიენტს საერთოდ არ ეგზავნება.
• სერვერს შეუძლია ობიექტებზე უარის თქმა. რადგან სერვერი ავტორიტეტია, მას შეუძლია კლიენტებს ობიექტების შექმნა აუკრძალოს, და ეს FiveM-ის ყველაზე სასარგებლო anticheat პარამეტრია.

თანამედროვე სერვერისთვის OneSync არჩევითი არ არის. ამჟამინდელი framework-ები, ინვენტარები და ბოლო რამდენიმე წლის resource-ების უმეტესობა მას ვარაუდობს, და ბევრი მის გარეშე სწორად არ იმუშავებს.

convar-ები#

set onesync onset onesync_population trueset onesync_forceMigration truesv_maxclients 48

legacy არის OneSync-ის თავდაპირველი იმპლემენტაცია, თავსებადობისთვის შენარჩუნებული. მას უფრო დაბალი ჭერი აქვს და ყოველ კლიენტს მეტს უგზავნის; ახალი სერვერისთვის მისი არჩევის მიზეზი არ არსებობს. ძალიან ძველი გზამკვლევები იყენებს onesync_enabled 1-ს და onesync_enableInfinity 1-ს. ეს onesync on-ის მოძველებული ჩანაწერებია და თუ იპოვი, უნდა წაშალო.

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

sv_maxclients-საც სრული გადატვირთვა სჭირდება. ნაგულისხმევი სერვერის მონაცემებიდან hardcap resource არის ის, რაც მოთამაშეებს უკან აბრუნებს, როცა სერვერი სავსეა; დატოვე ის შენს ensure სიაში, თუ რიგის resource მას არ ანაცვლებს.

სლოტების ლიმიტები: ძრავი, ლიცენზია და რეალობა#

ერთმანეთზე სამი ლიმიტია დალაგებული, და ყველაზე დაბალი იმარჯვებს.

ლიცენზიის დონე ის არის, რაზეც ხალხი ბორძიკობს. წლების განმავლობაში უფასო key OneSync-ით 48 სლოტამდე იძლეოდა, ხოლო უფრო მეტ სლოტს Cfx.re-ის გამოწერის დონე სჭირდებოდა (Element Club-ის სახელით იყიდება), მიბმული იმ ანგარიშზე, რომელსაც key ეკუთვნის. Cfx.re-ს ამ დონეების სახელები და ზღვრები ადრეც შეუცვლია, ამიტომ მიმდინარე ციფრები Cfx.re-ის პორტალში შეამოწმე და ნუ ენდობი ფორუმის რიცხვს - მათ შორის ამასაც. თუ sv_maxclients-ს იმაზე მაღლა დააყენებ, რასაც შენი key უშვებს, სერვერი გაშვებისას გეტყვის.

რეალობის ლიმიტი ის არის, რაც მნიშვნელოვანია. სლოტი დაპირებაა, რომ კიდევ ერთი ადამიანი შეიძლება იყოს სერვერზე ისე, რომ დანარჩენებს არ გაუუარესოს. roleplay სერვერზე ორასი resource-ით ყოველი დამატებითი მოთამაშე სამუშაოს უმატებს ყოველ ციკლს, რომელიც მოთამაშეებზე გადის, ყოველ event-ს, რომელიც ყველას ეგზავნება, და ყოველ ობიექტს, რომელიც მას თან მოაქვს. სერვერი 128 კავშირს მიიღებს გაცილებით ადრე, ვიდრე მათ კარგად მომსახურებას შეძლებს.

დაიწყე იმაზე დაბლა, ვიდრე გგონია, პიკისას უყურე txAdmin-ის tick-ის გრაფიკს და კონსოლის hitch-ის გაფრთხილებებს, და რაოდენობა მაშინ გაზარდე, როცა რიცხვები ამბობს, რომ შეგიძლია. სლოტების შემცირება მას შემდეგ, რაც საზოგადოება რიცხვს შეეჩვია, გაცილებით რთულია, ვიდრე მათი გაზრდა. რამდენი მოთამაშე ეტევა სერვერზე ზოგად არგუმენტს შეიცავს, ხოლო FiveM სერვერის წარმადობა აჩვენებს, როგორ წაიკითხო tick-ის მონაცემები.

culling: რას ხედავს თითოეული მოთამაშე#

ჩართული OneSync-ით თითოეულ კლიენტს მხოლოდ ის მოთამაშეები და ობიექტები ეგზავნება, რომლებიც მისი პოზიციიდან culling-ის რადიუსშია - ნაგულისხმევად დაახლოებით 424 ერთეული. ამ რადიუსს მიღმა ობიექტი ამ კლიენტისთვის არ არსებობს.

ეს არის მიზეზი, რის გამოც OneSync საერთოდ მასშტაბირდება, და ეს არის მიზეზი, რის გამოც ბევრი ძველი კლიენტის სკრიპტი მასზე არასწორად იქცევა:

• კლიენტის მხარის მოთამაშეების სიები არასრულია. GetActivePlayers() კლიენტზე მხოლოდ რადიუსში მყოფ მოთამაშეებს აბრუნებს. მასზე აგებული scoreboard სამოცმოთამაშიან სერვერზე რამდენიმე სახელს აჩვენებს. ააგე მოთამაშეების სიები სერვერზე და გაუგზავნე ქვემოთ.
• შორეული მოთამაშეების blip-ებს სერვერი სჭირდება. კლიენტი ვერ დადებს blip-ს ped-ზე, რომელიც მას არ გაეგზავნა. პოლიციისა და EMS-ის blip-ის resource-ები, რომლებიც OneSync-ზე მუშაობს, კოორდინატებს სერვერიდან ტაიმერით აგზავნის.
• შორეული ობიექტების ძებნა კლიენტზე ვერ ხერხდება. NetworkGetEntityFromNetworkId კლიენტზე არაფერს აბრუნებს ობიექტისთვის, რომელიც მის რადიუსს მიღმაა. გააკეთე სამუშაო სერვერზე, ან დაელოდე, სანამ ობიექტი რადიუსში მოხვდება.

FXServer რადიუსის შესაცვლელად სერვერის მხარის native-ებს გთავაზობს - SetPlayerCullingRadius ერთი მოთამაშისთვის და SetEntityDistanceCullingRadius ერთი ობიექტისთვის. მათ თავისი გამოყენება აქვს (ადმინი, რომელიც თვალს ადევნებს, ვერტმფრენი, რომელიც უფრო შორიდან უნდა ჩანდეს), მაგრამ მათი ფართოდ გაზრდა ყოველ კლიენტს მეტ მონაცემს უგზავნის და სინქრონიზაციის დროს ხარჯავს, ამიტომ კონკრეტული შემთხვევებისთვის გამოიყენე და არა როგორც პარამეტრი.

routing bucket-ები: ცალკე სამყაროები ერთ სერვერზე#

routing bucket სამყაროს ცალკე ინსტანციაა. bucket 3-ში მყოფ მოთამაშეებსა და ობიექტებს არ შეუძლიათ დაინახონ ან ურთიერთქმედება ჰქონდეთ რამესთან bucket 0-ში, თუნდაც ერთსა და იმავე ადგილას იდგნენ. ყველა bucket 0-ში იწყებს.

-- server side: put a player and their vehicle into a private instanceSetPlayerRoutingBucket(source, 3)SetEntityRoutingBucket(vehicle, 3)-- an empty instance with no ambient traffic and no client-created entitiesSetRoutingBucketPopulationEnabled(3, false)SetRoutingBucketEntityLockdownMode(3, "strict")

roleplay სერვერები bucket-ებს იყენებს პერსონაჟის არჩევისთვის, ბინის ინტერიერებისთვის, რომლის საკუთარი ასლიც ყველა მოთამაშეს აქვს, ადმინის თვალთვალისთვის და ღონისძიებებისთვის, რომლებმაც მთავარ ქალაქს არ უნდა შეუშალოს. ისინი იაფია: ცარიელი bucket არაფერი ჯდება, ხოლო სხვადასხვა bucket-ში მყოფი მოთამაშეები ერთმანეთთან არ სინქრონიზდება. არ დაგავიწყდეს მოთამაშეების bucket 0-ში დაბრუნება, როცა ინსტანციას ტოვებენ - bucket-ში გაჭედილი მოთამაშე ცარიელ ქალაქს ხედავს და იტყობინება, რომ სერვერი გაფუჭებულია. GetPlayerRoutingBucket(source) გეუბნება, სად არის ვინმე.

მოსახლეობა და ობიექტების რაოდენობა#

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

• `onesync_population false` გარემოს მოსახლეობას მთლიანად აჩერებს. ქალაქი ცარიელია, და სერვერი მხოლოდ სკრიპტების მიერ შექმნილ ობიექტებს ატარებს. რამდენიმე სერიოზული roleplay სერვერი ასე მუშაობს და ტრაფიკს მხოლოდ იქ ქმნის, სადაც საჭიროა.
• სიმჭიდროვის native-ები კლიენტზე. SetVehicleDensityMultiplierThisFrame, SetPedDensityMultiplierThisFrame და მათი ნათესავები მოსახლეობას ამცირებს გამორთვის გარეშე. ისინი ყოველ კადრზე უნდა გამოიძახო, და ეს Wait(0) ციკლის ერთ-ერთი ლეგიტიმური გამოყენებაა.
• მოსახლეობა bucket-ის მიხედვით. SetRoutingBucketPopulationEnabled მოსახლეობას კონკრეტულ ინსტანციებში თიშავს.

სკრიპტების მიერ შექმნილი ობიექტები მეორე ნახევარია. გარაჟიდან გამოყვანილი და არასოდეს გაქრობილი მანქანები, სამუშაოების მიერ დაყრილი და დატოვებული prop-ები, დაუსრულებელი მისიების ped-ები - ყველა სერვერის მდგომარეობაში რჩება. სერვერის მიერ შექმნილ ობიექტებს შეგიძლია უთხრა, რა ქნან, როცა მათ ახლოს არავინაა, SetEntityOrphanMode-ით იმ build-ებზე, რომლებიც ამას უჭერს მხარს; სხვა შემთხვევაში თავად გაასუფთავე. თუ sync thread-ის hitch-ის გაფრთხილებები uptime-თან ერთად მატულობს, ობიექტების დაგროვება პირველი ეჭვმიტანილია, ხოლო დაგეგმილი გადატვირთვა უხეში გამოსწორებაა, სანამ პასუხისმგებელ resource-ს იპოვი. გადატვირთვის განრიგები, რომლებიც გეხმარება დროის შერჩევას ხსნის.

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

entity lockdown#

რადგან OneSync-ის ქვეშ სერვერი ავტორიტეტია, მას შეუძლია კლიენტებს ობიექტების შექმნაზე უარი უთხრას. ეს არის sv_entityLockdown:

set sv_entityLockdown "relaxed"

ნაგულისხმევი არის inactive, რომელიც cheat menu-ს უფლებას აძლევს, შექმნას ნებისმიერი მანქანა, ped ან prop, რაც მოესურვება. relaxed ბლოკავს კლიენტის სკრიპტების მიერ შექმნილ ობიექტებს და გარემოს ტრაფიკს მუშა მდგომარეობაში ტოვებს, და ის აჩერებს spawn-ების სპამის უმეტესობას, რაც cheater-ის ვიზიტის დამახასიათებელი ნიშანია. strict ყველაფერს ბლოკავს, ასე რომ გარემოს მოსახლეობაც ჩერდება, და ყოველი მანქანა, რომელსაც მოთამაშე იღებს, სერვერმა უნდა შექმნას.

lockdown ასევე შენი resource-ების ფილტრია. გარაჟი, სამუშაო ან ადმინის მენიუ, რომელიც მანქანებს კლიენტის მხარეს ქმნის, relaxed-ის ქვეშ ფუჭდება. გამოსწორება არის ობიექტის სერვერზე შექმნა და network ID-ის კლიენტისთვის გადაცემა:

-- server sidelocal veh = CreateVehicleServerSetter(model, "automobile", x, y, z, heading)local netId = NetworkGetNetworkIdFromEntity(veh)TriggerClientEvent("garage:vehicleReady", source, netId)

CreateVehicleServerSetter სერვერის მხარის შექმნის უფრო ახალი native-ია და მანქანებისთვის სერვერის მხარის ძველ CreateVehicle-ს ჯობია; შეამოწმე, უჭერს თუ არა მხარს შენი სერვერის build-ი. ამჟამინდელი framework-ებისა და გარაჟების უმეტესობა უკვე ასე მუშაობს. lockdown-ის ჩართვა სატესტო ინსტანციაში, ან bucket-ის მიხედვით SetRoutingBucketEntityLockdownMode-ით, იაფი გზაა იმის გასარკვევად, შენი resource-ებიდან რომლები ვერ მუშაობს ასე. დანარჩენი თავდაცვითი პარამეტრები აღწერილია FiveM-ის anticheat-ის ვარიანტებში.

state bag-ები#

OneSync ასევე რთავს state bag-ებს: key-value მონაცემებს, მიბმულს ობიექტზე, მოთამაშეზე ან მთლიანად სერვერზე, რომლებიც კლიენტებთან ავტომატურად სინქრონიზდება.

-- serverPlayer(source).state:set("job", "police", true)   -- true = replicated to clientsEntity(vehicle).state:set("fuel", 64.0, true)GlobalState.weather = "RAIN"-- clientlocal fuel = Entity(vehicle).state.fuel

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

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

32-ზე მეტი `sv_maxclients` იგნორირდება. OneSync გამორთულია, ან ისეთ ადგილასაა დაყენებული, რომელიც არ მოქმედებს. დაადასტურე onesync on გაშვების გამონატანში და გადატვირთე მთელი სერვერი.

სერვერი გაშვებისას სლოტების რაოდენობას არ იღებს. შენი key-ს დონე ამას არ უშვებს. შეამცირე sv_maxclients ან შეცვალე დონე იმ ანგარიშზე, რომელსაც key ეკუთვნის.

scoreboard მხოლოდ რამდენიმე მოთამაშეს აჩვენებს. ის კლიენტის მხარეს GetActivePlayers()-ით არის აგებული. გადაიტანე სერვერზე.

lockdown-ის ჩართვის შემდეგ გარაჟებმა მანქანების გამოყვანა შეწყვიტა. ისინი მანქანებს კლიენტზე ქმნის. განაახლე resource ან გადაიყვანე სერვერის მხარის შექმნაზე.

მანქანები ქრება, როცა მათი მძღოლი კავშირს წყვეტს. ჩართე onesync_forceMigration.

sync thread-ის hitch-ები ყოველ საათში უარესდება. ობიექტების დაგროვება. დათვალე, რას ქმნის სკრიპტები და არასოდეს შლის, განიხილე გარემოს მოსახლეობის შემცირება და გადატვირთე განრიგით, სანამ ამას ასწორებ.

FAQ#

OneSync Infinity ისევ ცალკე პარამეტრია?

არა. set onesync on არის ის, რასაც ადრე Infinity ერქვა. ძველი onesync_enableInfinity convar მოძველებულია, ხოლო legacy მხოლოდ ძველ resource-ებთან თავსებადობისთვის არსებობს.

რამდენი სლოტის გამოყენება შეუძლია უფასო FiveM key-ს?

ისტორიულად 48 ჩართული OneSync-ით. უფრო მეტ რაოდენობას Cfx.re-ის გამოწერის დონე სჭირდებოდა იმ ანგარიშზე, რომელსაც key ეკუთვნის. Cfx.re-ს ეს ზღვრები ადრეც შეუცვლია, ამიტომ მიმდინარე ციფრი პორტალში შეამოწმე.

რატომ ვერ ხედავენ მოთამაშეები ერთმანეთს რუკის გასწვრივ?

ეს OneSync-ის culling-ია, რომელიც ისე მუშაობს, როგორც ჩაფიქრებულია. თითოეული კლიენტი მხოლოდ დაახლოებით 424 ერთეულის ფარგლებში მყოფ ობიექტებს იღებს. ყველაფერი, რასაც შორეული მოთამაშეები სჭირდება - blip-ები, scoreboard-ები - სერვერზე უნდა აიგოს.

სლოტების მეტი რაოდენობა სერვერს ანელებს?

თავისთავად არა; ცარიელი სლოტი არაფერი ჯდება. ანელებს მოთამაშეები, რომლებიც ამ სლოტებს ავსებენ, რადგან მოთამაშეებზე გამავალი ციკლები, ყველასთვის გაგზავნილი event-ები და ობიექტები, რომლებიც თითოეულ მოთამაშეს მოაქვს, მთავარ და sync thread-ებს სამუშაოს უმატებს.

უნდა გამოვრთო გარემოს მოსახლეობა?

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