FiveM Enhanced OneSync Full Mode คืออะไร

August 26, 2026

FiveM Enhanced OneSync Full Mode คือโหมดของระบบ Synchronization ใน FiveM ที่ใช้ได้เฉพาะ FiveM for GTAV Enhanced โดยเอกสาร Cfx.re ระบุว่า full Mode จะ ปิดการสร้าง Dummy Objects และทำงานอยู่บนสถาปัตยกรรม OneSync รุ่นใหม่ของ Enhanced

OneSync คือระบบ Network Synchronization ของ FiveM ที่ทำหน้าที่ให้ Server และ Client เห็นสถานะของ

ผู้เล่น
รถ
Ped
Objects
State
Routing Buckets

ได้ตรงกัน และยังเป็นเทคโนโลยีสำคัญที่ทำให้ FiveM รองรับ Server ขนาดใหญ่ได้

สำหรับ Enhanced ทาง Cfx.re ได้ปรับ OneSync ครั้งใหญ่ ทั้งเรื่อง Bandwidth, CPU, RAM, Entity Culling และ Network Tick Rate โดยประกาศว่า Enhanced Server จะใช้ High-performance Synchronization Architecture เป็นพื้นฐาน และโหมดเก่าที่มี Capacity ต่ำกว่าจะไม่ถูกนำต่อมา

บทความนี้จาก comsiam จะอธิบายว่า OneSync Full Mode คืออะไร ต่างจาก Infinity และ OneSync แบบเดิมอย่างไร และ Server Developer ต้องปรับ Script ตรงไหนบ้าง

① OneSync คืออะไร?

OneSync คือ Custom Synchronization System ของ FiveM

หน้าที่คือ Sync ข้อมูลระหว่าง

Server
↕
Client A
↕
Client B
↕
Client C

เพื่อให้ผู้เล่นเห็น World State ใกล้เคียงกัน

ตัวอย่างข้อมูลที่ต้อง Sync ได้แก่

Player Position
Ped
Vehicles
Objects
Entity State
Game Events

ถ้าไม่มีระบบ Synchronization ที่ดี Server Multiplayer ขนาดใหญ่จะทำงานได้ยากมาก

② OneSync ช่วยให้ FiveM รองรับ Player เยอะขึ้นอย่างไร?

OneSync ใช้วิธีไม่ส่งข้อมูลทุก Entity ให้ทุกคนตลอดเวลา

ระบบพิจารณาว่า Player จำเป็นต้องรู้เรื่อง Entity ใดบ้าง

ตัวอย่าง:

ผู้เล่นอยู่ Los Santos ไม่จำเป็นต้องได้รับ Update ทุก Frame ของรถที่อยู่ไกลอีกฝั่งของ Map

แนวคิดนี้ช่วยลด

Bandwidth
CPU
Client Processing

อย่างมาก

③ OneSync Full Mode คืออะไร?

เอกสาร OneSync ปัจจุบันระบุ Mode

full

ว่า

Disables dummy object creation

และระบุว่า

ใช้ได้เฉพาะ FiveM for GTAV Enhanced

นี่เป็นความแตกต่างที่ชัดเจนจาก OneSync Modes อื่น

④ Dummy Object คืออะไร?

ใน Synchronization Architecture รุ่นเก่าอาจมีการสร้าง Object ตัวแทนบางประเภทเพื่อรองรับ Behavior ของ Network/Game

Full Mode บน Enhanced สามารถทำงานโดยไม่ต้องสร้าง Dummy Objects แบบดังกล่าว

สิ่งนี้เป็นส่วนหนึ่งของการ Simplify OneSync Architecture บน Enhanced

⑤ Full Mode ใช้กับ FiveM Legacy ได้ไหม?

ไม่ได้

เอกสาร Cfx.re ระบุชัดว่า full Mode

Only usable on FiveM for GTAV Enhanced

ดังนั้นถ้าใช้ GTA V Legacy/FiveM Legacy อย่านำ Setting ที่เป็น Enhanced-only ไปใส่โดยคาดหวังว่าจะทำงานเหมือนกัน

⑥ OneSync Full กับ OneSync Infinity เหมือนกันไหม?

เกี่ยวข้องกัน แต่ไม่ควรใช้สองคำนี้แทนกันทุกกรณี

OneSync Infinity เป็น Architecture/Mode ที่นำระบบ Culling และการรองรับ Player จำนวนมากเข้ามา

ขณะที่ full เป็น OneSync Mode ที่เอกสารปัจจุบันระบุเฉพาะสำหรับ Enhanced

ดังนั้นให้ยึด Documentation ปัจจุบันมากกว่าคู่มือ OneSync เก่าหลายปีก่อน

⑦ Enhanced ยังใช้แนวคิด OneSync Infinity หรือไม่?

เทคโนโลยีหลักหลายอย่างยังสืบต่อมา เช่น

Entity Culling
Player Culling
Server-side State Awareness
Large Player Counts

แต่ Cfx.re ได้ Overhaul Synchronization Architecture สำหรับ Enhanced เพิ่มเติม

จึงไม่ควรคิดว่า Enhanced เป็นแค่ Infinity เดิมที่เปลี่ยนชื่อ

⑧ Enhanced OneSync ถูกปรับใหม่มากแค่ไหน?

Cfx.re ระบุว่าได้ใช้โอกาสจากการทำ FiveM Enhanced เพื่อ Overhaul OneSync

เป้าหมายคือ

Simplify Synchronization
ลด Bandwidth
ลด CPU
ลด Memory
เพิ่ม Stability
รองรับ Scale ได้ดีขึ้น

นี่เป็นการปรับระดับ Core Platform

⑨ Enhanced Server ใช้ High-performance Synchronization Mode หรือไม่?

ใช่

Cfx.re ระบุว่า FiveM Enhanced Server จะทำงานบน High-performance Synchronization Mode และ Mode ความจุต่ำแบบเก่าจะไม่ถูกนำต่อ

จึงทำให้ Environment ของ Enhanced มี Baseline Synchronization ที่สม่ำเสมอกว่าเดิม

⑩ OneSync Full ทำให้รองรับ 2048 Player เลยไหม?

อย่าสับสน

การมี OneSync Full ไม่ได้หมายความว่าใส่

sv_maxclients 2048

แล้ว Production จะรองรับผู้เล่น 2048 คนทันที

จำนวน Player จริงยังขึ้นกับ

Cfx Tier
Server Hardware
Scripts
Database
Voice
Networking
Resource Optimization

OneSync เป็นเพียง Foundation สำคัญ

⑪ FiveM รองรับได้สูงสุดกี่ Player?

เอกสาร OneSync ระบุ Architecture ที่รองรับได้สูงสุดระดับ

2048 Players

ภายใต้เงื่อนไข Platform/Tier ที่เกี่ยวข้อง

แต่ Server ที่รองรับ 2048 Slot ทางเทคนิคไม่ได้หมายความว่า Gameplay Resources ถูกออกแบบรองรับจำนวนนี้แล้ว

⑫ Script 64 Player อาจพังเมื่อเป็น 500 Player ไหม?

ได้

ตัวอย่าง Script ทำ

for _, player in pairs(GetPlayers()) do
    -- ทำงานหนัก
end

ทุก Frame หรือถี่มาก

Player เพิ่มจาก 64 เป็น 500 สามารถทำให้ Workload เพิ่มมหาศาล

OneSync Scale ได้ แต่ Script ต้อง Scale ด้วย

⑬ Entity Culling คืออะไร?

Culling คือการจำกัดว่า Client ต้องรับ Entity ตัวไหน

Player ไม่จำเป็นต้องได้รับข้อมูล Entity ทุกตัวใน Server

ระบบจะให้ความสำคัญกับ Entity ที่อยู่ในพื้นที่เกี่ยวข้อง

ช่วยลด Network และ Client Load

⑭ Focus Zone มีขนาดเท่าไร?

เอกสาร OneSync ปัจจุบันระบุ Default Culling Radius ประมาณ

424 Units

รอบ Player/Entity ใน Behavior ที่เกี่ยวข้อง

Player ที่อยู่นอก Scope อาจไม่มี Entity ของอีกฝ่ายอยู่บน Client

นี่เป็นเรื่องสำคัญมากสำหรับ Script Developer

⑮ ทำไม Player Loop ฝั่ง Client อาจไม่เห็นทุกคน?

เพราะ OneSync มี Player Culling

Player ที่อยู่ไกลออกจาก Scope อาจไม่มี Player Entity บน Client นั้น

ดังนั้น Code ที่คิดว่า

Client ทุกคนสามารถ Loop Player ทุกคนใน Server

เป็นแนวคิดที่ไม่เหมาะกับ OneSync Architecture

⑯ ต้องทำ Player Iteration ที่ไหน?

ถ้าต้องการข้อมูล Player ทั้ง Server ควรพิจารณาทำ Logic ฝั่ง

Server

แล้วส่งเฉพาะข้อมูลที่ Client ต้องใช้

แทนการหวังว่า Client จะมองเห็น Player Entity ทุกคน

⑰ Scoreboard ได้รับผลไหม?

ได้รับผลได้

Scoreboard ที่ Loop Active Players บน Client แล้วคาดหวังว่าจะเห็นทุกคน อาจแสดงจำนวนไม่ครบ

แนวทางที่ดีกว่าคือ

Server
↓
เก็บ Player List
↓
ส่งข้อมูลที่จำเป็น
↓
Scoreboard Client

โดยไม่พึ่ง Local Player Scope

⑱ Police GPS ได้รับผลไหม?

มีโอกาส

Police Tracking ที่ต้องแสดงตำรวจทั่ว Map ไม่ควรพึ่ง Local Player Ped ของตำรวจทุกคน

ให้ Server จัดการตำแหน่งหรือ State ที่จำเป็น

แล้วส่งไปยังตำรวจที่ได้รับอนุญาต

⑲ Admin Player List ต้องตรวจไหม?

ต้อง

ระบบ Admin ที่ต้องเห็นผู้เล่นทั้งหมดควรใช้ Server-side Player Data

ไม่ควรสร้างรายชื่อจาก Player Entities ที่ Client มองเห็นใน Scope เท่านั้น

⑳ Spectate Script ต้องตรวจไหม?

ต้องอย่างมาก

Spectate เกี่ยวข้องกับ

Player Scope
Entity
Camera
Voice

และอาจต้องจัดการ Focus/Streaming เพิ่ม

Script Spectate Legacy เก่าควรถูก Multiplayer Test บน Enhanced ก่อน Production

㉑ Culling Radius ควรเพิ่มให้ใหญ่มากไหม?

ไม่แนะนำเป็นวิธีแก้ปัญหาทั่วไป

การเพิ่ม Culling Radius เพื่อแก้ Script ที่เขียนผิด Architecture อาจเพิ่ม

Network Traffic
Entity Count
Client Load

เอกสาร Cfx.re ยังระบุว่า Culling Radius Natives บางตัว Deprecated และมีปัญหาที่แก้ไม่ได้

วิธีที่ดีกว่าคือแก้ Script

㉒ playerEnteredScope คืออะไร?

เป็น Server Event ที่เกิดเมื่อ Player คนหนึ่งเข้าสู่ Scope ของอีก Player

ใช้ตรวจการเปลี่ยนแปลง Scope ได้

แต่มีข้อควรระวังด้าน Performance

㉓ playerLeftScope คืออะไร?

ทำงานตรงกันข้าม

เกิดเมื่อ Player ออกจาก Scope

สามารถใช้กับ Logic บางประเภทได้

แต่ไม่ควรใช้จำนวนมากโดยไม่มีเหตุผล

㉔ ทำไม Scope Events ถึงกิน Performance?

เอกสาร OneSync เตือนว่า Event เหล่านี้มี Scaling Cost

ถ้ามี Player จำนวนมากอยู่ใน Scope ของกันและกัน จำนวน Event สามารถเพิ่มขึ้นมาก

Cfx.re แนะนำให้ใช้ State Bags เมื่อเหมาะสมแทน Scoped Events หลายกรณี

㉕ State Bags คืออะไร?

State Bags คือระบบเก็บ State ที่สามารถผูกกับ

Player
Entity
Global State

และ Replicate ให้ Client ที่เกี่ยวข้อง

ตัวอย่าง

Vehicle
└── locked = true

Client ที่เกี่ยวข้องสามารถรับ State นี้ผ่าน Synchronization System

㉖ Enhanced เปลี่ยน State Bags หรือไม่?

มีการปรับ

Enhanced ปรับ State Bag Replication ให้มีประสิทธิภาพขึ้น

Cfx.re ระบุว่าค่าที่ถูก Mark ว่า Replicated จึงจะถูกส่ง และ Listener จะทำงานเมื่อ Entity มีอยู่จริง

Resource ที่ใช้ State Bags ควรได้รับ Multiplayer Test

㉗ State Bags ดีกว่าส่ง Event รัว ๆ ไหม?

ในหลาย Use Case ใช่

เช่น State ของ

Vehicle Lock
Duty
Door
Entity Metadata

ที่เป็น State จริง ๆ

การใช้ State Bag ช่วยให้ Architecture สอดคล้องกับ OneSync มากกว่าการ Broadcast Event ซ้ำ ๆ

㉘ Server-created Entity คืออะไร?

OneSync รองรับการสร้าง Entity จาก Server

เช่น

Vehicle
Ped
Object

ตัวอย่าง Concept:

local vehicle = CreateVehicleServerSetter(
    `blista`,
    'automobile',
    200.0,
    200.0,
    30.0,
    0.0
)

แนวทาง Server-created Entity เหมาะกับ Server-authoritative Design มากขึ้น

㉙ ทำไม Cfx.re แนะนำ Server-created Entities?

ช่วยให้ Server มี Authority เหนือ Entity มากกว่า

โดยเฉพาะระบบ

Persistent Vehicles
Mission Peds
World Objects

และลดการพึ่ง Client เพื่อสร้าง Entity สำคัญ

㉚ Client-created Entity ใช้ไม่ได้เลยไหม?

ไม่ใช่ทุก Mode จะห้ามทั้งหมด

OneSync Documentation มี Entity Lockdown Modes เช่น

full
strict
relaxed
inactive

แต่ต้องเข้าใจว่า full ใน Mode Table มีความหมายเฉพาะว่า Disable Dummy Object Creation และใช้ได้เฉพาะ Enhanced

อย่าสับสนกับ strict Entity Lockdown

㉛ Strict Mode คืออะไร?

ใน Entity Lockdown Mode

strict

หมายถึง Client ไม่สามารถสร้าง Entity ได้เลยใน Routing Bucket ที่กำหนด

เหมาะกับ Environment ที่ Server ต้องการควบคุม Entity อย่างเข้มงวด

㉜ Relaxed Mode คืออะไร?

relaxed

จะ Block เฉพาะ Script-owned Entities ที่ Client สร้าง

จึงผ่อนคลายกว่า Strict

ต้องเลือกตาม Gameplay Architecture

㉝ Inactive คืออะไร?

inactive

เปิดให้ Client สร้าง Entity ได้

เป็น Lockdown Mode ที่ผ่อนคลายที่สุดในตารางดังกล่าว

㉞ Full กับ Strict ต่างกันมากไหม?

ต่างกัน

full

ปิด Dummy Object Creation และใช้ได้เฉพาะ FiveM Enhanced

strict

ห้าม Client สร้าง Entity

ดังนั้นอย่าอ่านข้อความใน Config แล้วตีความว่าสองคำนี้หมายถึง “Security สูงสุด” เหมือนกัน

㉟ Routing Bucket คืออะไร?

Routing Bucket ช่วยแบ่ง Game State เป็น Instance

ตัวอย่าง

Bucket 0 = โลกหลัก
Bucket 1 = Character Creator
Bucket 2 = บ้านส่วนตัว
Bucket 3 = Mission

Player และ Entity ใน Bucket ต่างกันสามารถถูกแยกจากกัน

㊱ OneSync Full ใช้ Routing Bucket ได้ไหม?

ได้

Routing Buckets เป็นส่วนสำคัญของ OneSync Architecture

สามารถกำหนด Bucket ให้

Player
Entity

และตั้ง Entity Lockdown/Population Behavior แยกแต่ละ Bucketได้

㊲ Character Selection ควรใช้ Routing Bucket ไหม?

เหมาะมาก

สามารถแยกผู้เล่นที่กำลังเลือก Character ออกจาก World หลัก

เช่น

Character Select
→ Bucket 100

แล้วเมื่อเลือกเสร็จค่อยย้ายกลับ Bucket หลัก

ช่วยลด Player/Entity รบกวนกัน

㊳ Housing ใช้ Routing Bucket ได้ไหม?

ได้

Housing แบบ Instance สามารถใช้ Routing Bucket เพื่อแยกผู้เล่นแต่ละบ้าน

แต่ Developer ต้องจัดการ

Player
Entities
Voice
State

ให้เหมาะสม

㊴ Routing Bucket ใช้แทน Interior ทุกกรณีไหม?

ไม่

Routing Bucket เป็น Instance Mechanism ไม่ใช่เครื่องมือ Map Streaming หรือ MLO Loading

ถ้า Resource ต้องการ Interior จริงยังต้องจัด Asset/Interior ตามระบบนั้น

อย่าใช้ Bucket แก้ทุกปัญหา

㊵ Enhanced Networking เปลี่ยนจาก P2P หรือไม่?

เปลี่ยน

Enhanced ได้ปรับ Synchronization ให้พึ่ง Client-server Model มากขึ้น และลดการพึ่ง P2P Synchronization แบบ Legacy

ทำให้ Architecture มี Server Authority ชัดขึ้น

㊶ Script ที่ใช้ Network Ownership แบบเก่าต้องตรวจไหม?

ต้อง

โดยเฉพาะ Code ที่ใช้ Workaround เช่น

Request Control
Host Migration
Entity Owner
Repeated Network Ownership Request

บาง Pattern อาจไม่จำเป็นหรือ Behavior เปลี่ยนบน Enhanced

㊷ Network ID ยังสำคัญไหม?

สำคัญ

Network IDs ใช้ระบุ Networked Entities ระหว่าง Client/Server

แต่ Developer ต้องระวัง Entity สามารถอยู่/ออก Scope และ Owner สามารถเปลี่ยนได้

อย่าเก็บ Local Entity Handle แล้วคิดว่าจะใช้ได้ทั่ว Network

㊸ Local Entity ID กับ Network ID ต่างกันอย่างไร?

Local Entity ID

ใช้บน Client เครื่องหนึ่ง

Network ID

ใช้สำหรับอ้าง Entity ใน Network Context

เมื่อเขียน Multiplayer Script ต้องแยกสองอย่างนี้ให้ชัด

โดยเฉพาะ OneSync Server ขนาดใหญ่

㊹ Entity อยู่นอก Scope จะเกิดอะไร?

Client อาจไม่มี Entity นั้น Local อยู่เลย

ดังนั้นคำสั่ง Client ที่ต้องจับ Entity ไกล ๆ สามารถล้มเหลวได้

Solution ไม่ใช่ Force Streaming ทุก Entity

ควรย้าย Logic ที่เหมาะสมไป Server

㊺ Persistent Vehicle ควรสร้างอย่างไร?

OneSync Documentation แนะนำ Server-side Entity Creation และสามารถใช้ Orphan Mode เพื่อช่วยรักษา Entity

ตัวอย่าง Concept:

SetEntityOrphanMode(vehicle, 2)

สำหรับ Entity ที่ Server ต้องการให้ Persistent

แต่ Persistent Database Vehicle ยังต้องมี Logic Save/Restore แยก

㊻ OneSync เก็บรถใน Database อัตโนมัติไหม?

ไม่

OneSync จัดการ Network Entity

ไม่ได้แทน

Garage Database
Vehicle Ownership
Persistence Storage

หาก Server Restart แล้วต้อง Spawn รถคืน Developer ยังต้องสร้าง Persistence Logic

㊼ Full Mode ทำให้รถไม่หายเลยไหม?

ไม่ควรเข้าใจแบบนั้น

Entity Lifecycle ยังขึ้นกับ

Resource
Ownership
Orphan Mode
Cleanup
Server Restart

Full Mode ไม่ใช่คำสั่ง

Keep All Entities Forever

㊽ Enhanced เพิ่ม Sync Tick Rate หรือไม่?

เพิ่มได้มาก

Cfx.re ระบุว่า Enhanced สามารถตั้ง Network Synchronization Tick Rate ได้สูงสุด

120 Updates ต่อวินาที

เทียบกับ Legacy ที่ต่ำกว่านี้

ช่วยลดเวลาระหว่าง Action ของ Player กับสิ่งที่ Player อื่นเห็น

㊾ Tick Rate สูงสุดต้องตั้ง 120 เสมอไหม?

ไม่จำเป็น

ค่าเหมาะสมขึ้นกับ

Server Hardware
Player Count
Gameplay
Bandwidth
Performance

ควร Benchmark ก่อน

อย่าเพิ่มเพียงเพราะตัวเลขสูงกว่า

㊿ Tick Rate สูงช่วยอะไร?

สามารถช่วยลด Delay ของ Synchronization

มีประโยชน์กับ

PvP
Shooting
Vehicle Interaction
Movement

ที่ Timing สำคัญ

แต่ Server Script Lag ยังสามารถทำให้ Gameplay ช้าได้อยู่

51. Tick Rate สูงทำให้ Ping ต่ำลงไหม?

ไม่ใช่โดยตรง

Ping หลักมาจาก Network Round-trip Time

Tick Rate สูงขึ้นช่วยลดช่วงเวลารอ Synchronization Update

จึงอาจทำให้ Responsiveness ดีขึ้น แต่ไม่ได้ทำให้ระยะทาง Internet สั้นลง

52. Enhanced ใช้ Raw UDP เพิ่มขึ้นหรือไม่?

Cfx.re ระบุว่า Sync Data บน Enhanced ถูกส่งเป็น Raw UDP Packets หลังลดการพึ่ง Third-party Library สำหรับ Synchronization Frames

ส่วน Event Communication ยังใช้ ENet

ช่วยให้ Cfx.re ควบคุม Networking Stack ได้มากขึ้น

53. Raw UDP มีประโยชน์อะไร?

ให้ Platform ควบคุม

Packet Handling
Synchronization
Future I/O Optimization

ได้โดยตรงมากขึ้น

และเป็นส่วนหนึ่งของเหตุผลที่สามารถเพิ่ม Sync Tick Rate ได้

54. Enhanced ปรับ Entity Culling เพิ่มหรือไม่?

ปรับ

Cfx.re ระบุว่าการคำนวณ Entity Culling เดิมมีข้อจำกัดในการประมวลผล Player ต่อ Tick

Enhanced ปรับ Culling ให้ใช้หลาย CPU Cores ได้ดีขึ้น

ช่วยลด Entity Pop-in Delay บน Server ขนาดใหญ่มาก

55. OneSync Full ทำให้ Entity Pop-in หายทั้งหมดไหม?

ไม่ควรรับประกัน

Pop-in ยังสามารถเกิดจาก

Streaming
Asset
Network
Player Movement
Resource

แต่ Enhanced มีการปรับ Culling Architecture เพื่อช่วยลดปัญหาใน Scale ใหญ่

56. Server RAM ลดลงจริงไหม?

Cfx.re ระบุ Optimization ระดับ Cfx Server/OneSync ที่สามารถลด Server-side Allocation และ RAM Usage ได้มากในบาง Scenario

แต่คำว่า “ได้ถึง” ไม่ได้แปลว่า Server ทุกเครื่องจะลดเท่ากัน

ต้อง Benchmark Resource จริง

57. CPU จะลดลงทุก Server ไหม?

ไม่รับประกันเช่นกัน

Platform Layer สามารถมีประสิทธิภาพขึ้น

แต่ Script ที่มี

Infinite Loop
Heavy Query
Entity Scan
Event Spam

ยังสามารถกิน CPU สูงได้

OneSync ไม่สามารถแก้ Script ที่ออกแบบไม่ดีอัตโนมัติ

58. Script เก่าที่ใช้ GetActivePlayers ต้องตรวจไหม?

ควรตรวจ Intent ของ Script

GET_ACTIVE_PLAYERS ฝั่ง Clientเกี่ยวข้องกับ Player ที่ Active/Relevant ฝั่ง Client ไม่ใช่ Database ของผู้เล่นทั้ง Server

หากต้องการ Global Player List ให้ทำ Server-side

นี่เป็นหลักสำคัญเมื่อใช้ OneSync

59. Global Blip ควรทำอย่างไร?

สำหรับ Blip ที่ต้องติดตาม Player ทั่ว Map เช่น Police GPS

อย่าพึ่ง Player Entity อยู่ใน Client Scope

แนวคิดดีกว่าคือ

Server Position Data
↓
Authorized Clients
↓
สร้าง/Update Blip

ตาม Frequency ที่เหมาะสม

60. Entity Scan ทุก Frame ควรทำไหม?

ไม่ควร โดยเฉพาะ Server/Client ที่มี Entity จำนวนมาก

แทน

while true do
    Wait(0)
    -- scan entities ทั้งหมด
end

ควรใช้

Events
Zones
Cache
Longer Wait
Server State

ตาม Use Case

61. OneSync Full ต้องใช้กับ ESX ได้ไหม?

ได้ในระดับ Platform

ESX Resource ที่เขียนตาม FiveM API สามารถทำงานกับ Enhanced OneSync

แต่ Resource รอบ ESX เช่น

Scoreboard
Police GPS
Admin
Vehicle
Housing

ต้องตรวจ Scope/Entity Logic

62. QBCore ใช้ได้ไหม?

หลักเดียวกัน

qb-core ไม่ได้เป็นตัวกำหนด OneSync Mode

แต่ Resource QBCore ที่พึ่ง Client Player Loop หรือ Network Ownership แบบเก่าควรถูก Audit

63. Qbox ใช้ได้ไหม?

ได้

Qbox และ OX Ecosystem สามารถใช้ OneSync/State Bags/Server-side Entity Architecture ได้

แต่ Third-party Resource ยังต้อง Test เป็นรายตัว

64. Framework ใหม่ต้องเปิด OneSync เองไหม?

FiveM Server Setup ปัจจุบันยังใช้

set onesync on

เป็น Configuration สำหรับเปิด OneSync/Server-side State Awareness ใน Server Setup ทั่วไป

สำหรับ Enhanced ต้องใช้ Cfx Server และ Configuration ที่ตรงกับ Enhanced Documentation

อย่า Copy Parameter OneSync เก่าหลายยุคมาปะปนกัน

65. ต้องใส่ onesync_enabled 1 ไหม?

คู่มือหรือโพสต์ FiveM รุ่นเก่ามากอาจใช้

onesync_enabled

หรือ Parameter เก่ารูปแบบอื่น

ไม่ควรใช้ Tutorial เก่าเป็นมาตรฐาน

ให้ยึด set onesync on และ Documentation ปัจจุบันสำหรับ Server Setup

66. sv_useAccurateSends ยังควรใช้ไหม?

Enhanced มี Synchronization Configuration ใหม่ และ Cfx.re ระบุ Tick Rate รุ่นใหม่แทนข้อจำกัดแบบ Legacy ที่เคยเกี่ยวข้องกับ sv_useAccurateSends

จึงไม่ควร Copy Optimization ConVar Legacy มาใช้โดยไม่ตรวจ Enhanced Documentation

67. Server Owner ต้อง Rewrite Script ทั้งหมดไหม?

ไม่

Cfx.re ยังคงเน้น Backward Compatibility ของ Existing Lua, JavaScript และ C# Scripts

Resource จำนวนมากจะใช้ต่อได้

แต่ Resource ที่พึ่ง

Player Scope
P2P
Entity Ownership
OneSync Mode เก่า

ควรได้รับ QA

68. วิธีหา Script ที่เสี่ยงกับ OneSync

ค้นหา Code ที่เกี่ยวข้องกับ

GetActivePlayers
NetworkGetEntityOwner
NetworkRequestControlOfEntity
Scope Events
State Bags
Routing Buckets
Client-created Entities

จากนั้นจัดกลุ่ม Resource สำหรับ Test

69. Script Start ได้ถือว่าผ่านไหม?

ไม่

ตัวอย่าง Scoreboard Resource Start ได้ปกติ

แต่เมื่อ Player อยู่ไกลกันอาจแสดงรายชื่อผิด

ดังนั้น OneSync Compatibility ต้องทำ Scenario Test

ไม่ใช่ดู Console อย่างเดียว

70. วิธีทดสอบ OneSync Resource

ใช้ Player อย่างน้อยหลายคน

ทดลอง

ยืนใกล้กัน
อยู่คนละเมือง
ขับรถเร็ว
เข้า Routing Bucket
ออกจาก Bucket
Spawn Entity
Delete Entity
Reconnect

ตรวจว่าทุกระบบยัง Sync ถูกต้อง

71. Load Test สำคัญไหม?

สำคัญมาก

OneSync Problem บางอย่างไม่ปรากฏตอนมี 2 Player

แต่เกิดเมื่อ

50 Player
100 Player
Entity จำนวนมาก

Server Owner ควร Load Test ตาม Target Player Count จริง

72. Monitoring OneSync ทำได้ไหม?

Enhanced Cfx Server มี Prometheus-compatible Metrics จำนวนมาก

รวมข้อมูลเช่น

OneSync Entity Count
Sync Tree Count
State Bag Counts
Routing Bucket Data
NetID Usage
Thread Tick Times

มีประโยชน์มากสำหรับ Server ขนาดใหญ่

73. อย่าดู CPU อย่างเดียว

OneSync Performance ควรดูร่วมกันทั้ง

CPU
RAM
Network
Entity Count
Tick Time
State Bags
Player Count

Server CPU 30% ไม่ได้หมายความว่า Network Synchronization ไม่มี Bottleneck

74. OneSync Full Mode เหมาะกับ Server แบบไหน?

เป็นส่วนของ Enhanced OneSync Environment และมีประโยชน์กับ Server ทุกขนาดที่ใช้ Enhanced

โดยเฉพาะ Server ที่มี

Player จำนวนมาก
Vehicles จำนวนมาก
Persistent Entities
Routing Buckets
Server-side Gameplay

จะเห็นความสำคัญของ Architecture นี้มากขึ้น

75. สิ่งที่ไม่ควรทำ

หลีกเลี่ยง

คิดว่า Full = Strict
คิดว่า Full = 2048 Player อัตโนมัติ
Force Culling Radius ใหญ่เพื่อแก้ Script
Loop Player ทั้ง Serverจาก Client
Broadcast State ทุก Frame
สร้าง Critical Entity จาก Client โดยไม่จำเป็น
Copy OneSync Config เก่าหลายปี
ไม่ทดสอบ Player Scope
ไม่ Load Test

OneSync ที่เร็วขึ้นจะได้ประโยชน์เต็มที่เมื่อ Resource ถูกออกแบบให้เข้ากับ Architecture

76. คำถามที่พบบ่อย

FiveM Enhanced OneSync Full Mode คืออะไร?

เป็น OneSync Mode ที่ Cfx.re ระบุว่า Disable Dummy Object Creation และใช้ได้เฉพาะ FiveM for GTAV Enhanced

ใช้กับ FiveM Legacy ได้ไหม?

ไม่ได้

Full กับ Strict เหมือนกันไหม?

ไม่ Full เกี่ยวกับ Dummy Object Creation ส่วน Strict เป็น Entity Lockdown ที่ห้าม Client สร้าง Entity

Enhanced รองรับผู้เล่นสูงสุดเท่าไร?

OneSync Architecture รองรับได้สูงสุดระดับ 2048 Player ภายใต้ Tier และข้อจำกัดที่เกี่ยวข้อง

เปิด 2048 Slot แล้วใช้ได้เลยไหม?

ไม่ ต้องมี Hardware, Scripts, Database, Network และ Infrastructure ที่รองรับ

OneSync ใช้ Culling ไหม?

ใช้ เพื่อลดข้อมูล Entity ที่ Client ไม่จำเป็นต้องรับ

Client เห็น Player ทั้ง Serverไหม?

ไม่จำเป็น Player นอก Scope อาจไม่มี Local Entity บน Client

Scoreboard ควรทำ Player List ฝั่งไหน?

Global Player List ควรพึ่ง Server-side Data มากกว่าการ Loop Local Player Entities

State Bags ควรใช้ไหม?

เหมาะกับการ Sync State หลายประเภทและ Cfx.re แนะนำแทน Scope Events ในบางกรณี

Enhanced เพิ่ม Sync Tick Rate ได้ไหม?

ได้ สูงสุด 120 Updates ต่อวินาทีตามข้อมูล Cfx.re ปัจจุบัน

77. สรุป FiveM Enhanced OneSync Full Mode คืออะไร

FiveM Enhanced OneSync Full Mode คือ OneSync Mode ที่ใช้ได้เฉพาะ FiveM for GTAV Enhanced และปิดการสร้าง Dummy Objects ตามคำอธิบายใน Documentation ปัจจุบัน

แต่สิ่งสำคัญกว่าชื่อ full คือ Enhanced ได้รับการปรับ OneSync Architecture ครั้งใหญ่

Cfx.re ปรับ

Synchronization → Bandwidth → CPU → Memory → Culling → Tick Rate → Server Authority

เพื่อให้ Server สามารถ Scale ได้มีประสิทธิภาพขึ้น

OneSync ยังคงใช้หลักว่า Client ไม่จำเป็นต้องเห็น Player และ Entity ทุกตัวใน Server

ระบบ Culling จะส่งเฉพาะสิ่งที่เกี่ยวข้องกับ Player ทำให้ Developer ต้องเลิกคิดแบบ

“Client ทุกคนเห็น Player ทุกคนเสมอ”

Resource ประเภท

Scoreboard
Police GPS
Admin
Spectate
Vehicle System
Housing
Routing Bucket

จึงควรได้รับการตรวจเป็นพิเศษ

Cfx.re ยังแนะนำแนวทาง Server-created Entities และ State Bags สำหรับ Architecture ที่เหมาะกับ OneSync มากขึ้น และ Enhanced สามารถเพิ่ม Network Synchronization Tick Rate ได้สูงสุดถึง 120 Updates ต่อวินาที

อย่างไรก็ตาม อย่าสับสนว่า

OneSync Full = 2048 Player พร้อมใช้ทันที

จำนวนผู้เล่น Production จริงยังขึ้นกับ Hardware, Resource, Database, Voice, Network และ Cfx Tier

แนวทางที่ comsiam แนะนำคือ

เปิด Enhanced Test Server → ตรวจ Player Scope → ตรวจ Entity → ตรวจ State Bags → ตรวจ Routing Buckets → Multiplayer Test → Load Test → Monitor Metrics

ก่อนเพิ่ม Player Limit จำนวนมาก

สรุปสั้นที่สุด:

OneSync Full → Enhanced-only

Full → Disable Dummy Object Creation

Full ≠ Strict Entity Lockdown

Enhanced → ใช้ High-performance Synchronization Architecture

Culling → Clientไม่เห็นทุก Entity ทั้ง Server

Global Player Logic → ทำ Server-side

State → ใช้ State Bags เมื่อเหมาะสม

Entity สำคัญ → พิจารณา Server-created

Sync Tick → ตั้งได้สูงสุด 120 Updates/วินาที

ถ้า Developer ออกแบบ Resource ตาม Server-authoritative และ Scope-aware Architecture ของ OneSync ระบบ FiveM Enhanced จะสามารถใช้ข้อดีด้าน Networking และ Scalability ได้เต็มประสิทธิภาพมากกว่าการย้าย Script Legacy มาโดยไม่ปรับแนวคิดเลย