Extending Framework
ภาพรวมแนวทางขยาย NC Core ด้วย Player Class Functions, Modules และ Functions พร้อมลิงก์ไปยังหน้ารายละเอียด
Extending Framework
NC Core รองรับการขยายความสามารถแบบ “เพิ่มไฟล์ใหม่” โดยไม่แก้ไฟล์หลัก
แนวทางนี้ช่วยลดความเสี่ยงเวลาต้องอัปเดต Framework และทำให้ดูแลโค้ดง่ายขึ้น
หลีกเลี่ยงการแก้ไฟล์ core โดยตรง ให้เพิ่มความสามารถผ่าน Player Class Functions, Modules หรือ Functions แทน
เลือกแนวทางให้เหมาะกับงาน
Player Class Functions
เพิ่ม Method ให้ xPlayer เช่น xPlayer.addExperience()
ใช้ได้เฉพาะฝั่ง Server และ โหลดอัตโนมัติ (ไม่ต้องเปิดใน config)
Modules
ฟังก์ชันเสริมที่แยกตามฝั่ง client/server/shared
เปิด/ปิดได้ใน config/config.modules.lua
Functions
ฟังก์ชันส่วนกลางของ Framework (ESX.*)
เปิด/ปิดได้ใน config/config.functions.lua
โครงสร้างโฟลเดอร์
Player Class Functions:
server/classes/player/functions/Modules:
modules/client/,modules/server/,modules/shared/Functions:
functions/client/,functions/server/,functions/shared/
Quick start
เลือกประเภทการขยาย
ถ้าต้องการเรียกผ่าน
xPlayer.*ให้ใช้ Player Class Functionsถ้าต้องการเรียกผ่าน
ESX.*ให้ใช้ Modules หรือ Functions
สร้างไฟล์ และตั้งชื่อให้ตรงกับสิ่งที่จะเรียก
Player Class Functions: ชื่อไฟล์ = ชื่อ Method (เช่น
addExperience.lua)Modules/Functions: ชื่อไฟล์ PascalCase (เช่น
ShowCustomNotification.lua)
เปิดใช้งาน และทดสอบ
Player Class Functions: ทดสอบได้ทันทีหลัง restart resource
Modules: เพิ่มรายการใน
config/config.modules.luaFunctions: เพิ่มรายการใน
config/config.functions.lua
อ่านต่อ (หน้ารายละเอียด)
หัวข้อที่มักใช้ร่วมกัน
Transaction: ดูใน Shared Functions
Status API: ดูใน Player Class — Status
เนื้อหาเพิ่มเติม (ตัวอย่างและรายละเอียดแบบเต็ม)
เกี่ยวกับ Player Class Functions
Player Class Functions คือฟังก์ชันที่ทำงานกับ xPlayer object โดยตรง ใช้งานเฉพาะฝั่ง Server-side เท่านั้น
📁 ตำแหน่ง:
server/classes/player/functions/⚙️ Config: ไม่ต้องระบุใน config (โหลดอัตโนมัติ)
🎯 จุดประสงค์: เพิ่มฟังก์ชันใหม่ให้ xPlayer object
โครงสร้างพื้นฐาน
ตัวอย่างที่ 1: ฟังก์ชันเพิ่มแต้มประสบการณ์
ไฟล์: server/classes/player/functions/addExperience.lua
วิธีเรียกใช้งาน:
ตัวอย่างที่ 2: ฟังก์ชันตรวจสอบระยะห่าง
ไฟล์: server/classes/player/functions/isNearPlayer.lua
วิธีเรียกใช้งาน:
ตัวอย่างที่ 3: ฟังก์ชันจัดการสกิล
ไฟล์: server/classes/player/functions/addSkillExp.lua
ไฟล์: server/classes/player/functions/getSkillLevel.lua
วิธีเรียกใช้งาน:
2. Modules (โมดูลเสริม)
เกี่ยวกับ Modules
Modules คือฟังก์ชันเสริมที่ทำงานอิสระ สามารถสร้างได้ทั้งฝั่ง Client และ Server
📁 ตำแหน่ง:
modules/client/หรือmodules/server/หรือmodules/shared/⚙️ Config: ต้องระบุใน
config/config.modules.lua🎯 จุดประสงค์: เพิ่มฟังก์ชันเสริมที่ใช้งานทั่วไป
โครงสร้างพื้นฐาน
ขั้นตอนการเพิ่ม Module
ตัวอย่างที่อัปเดตและอ่านง่ายกว่าอยู่ในหน้า Extending Modules
ตัวอย่าง Server Module
ไฟล์: modules/server/BroadcastToJob.lua
เพิ่มใน Config:
วิธีใช้งาน:
ตัวอย่าง Shared Module
ไฟล์: modules/shared/CalculateDistance3D.lua
เพิ่มใน Config:
วิธีใช้งาน:
3. Functions (ฟังก์ชันหลัก)
เกี่ยวกับ Functions
Functions คือฟังก์ชันหลักของ NC Core ที่ใช้งานทั่วไป แยกตามฝั่ง Client, Server และ Shared
📁 ตำแหน่ง:
functions/client/หรือfunctions/server/หรือfunctions/shared/⚙️ Config: ต้องระบุใน
config/config.functions.lua🎯 จุดประสงค์: ฟังก์ชันหลักที่ใช้บ่อย
ความแตกต่างระหว่าง Modules และ Functions:
Modules = ฟังก์ชันเสริมเพิ่มเติม
Functions = ฟังก์ชันหลักของ Framework
ในทางปฏิบัติ ทั้งสองทำงานคล้ายกัน แต่แยกเพื่อความเป็นระเบียบ
ขั้นตอนการเพิ่ม Function
ตัวอย่าง Client Function
ไฟล์: functions/client/PlayAnimationSync.lua
เพิ่มใน Config:
วิธีใช้งาน:
ตัวอย่าง Server Function
ไฟล์: functions/server/GetPlayersInRadius.lua
เพิ่มใน Config:
วิธีใช้งาน:
สรุปและ Best Practices
ตารางเปรียบเทียบ
Player Class
server/classes/player/functions/
❌ ไม่ต้อง
player (xPlayer)
ฟังก์ชันเฉพาะผู้เล่น
Modules
modules/*/
✅ config.modules.lua
ไม่มี
ฟังก์ชันเสริมทั่วไป
Functions
functions/*/
✅ config.functions.lua
ไม่มี
ฟังก์ชันหลักของ Framework
คำแนะนำการเลือกใช้
ใช้ Player Class Functions เมื่อ:
✅ ต้องการเพิ่มฟังก์ชันให้
xPlayerobject✅ ทำงานเฉพาะผู้เล่นคนหนึ่ง
✅ ต้องการเรียกผ่าน
xPlayer.yourFunction()
ใช้ Modules เมื่อ:
✅ ฟังก์ชันเสริมที่ไม่เกี่ยวกับผู้เล่นโดยตรง
✅ เป็นเครื่องมือหรือ utility ทั่วไป
✅ ต้องการเปิด/ปิดได้ผ่าน config
ใช้ Functions เมื่อ:
✅ เป็นฟังก์ชันหลักที่สำคัญต่อ Framework
✅ ใช้งานบ่อยมากและทั่วทั้งระบบ
✅ เป็นส่วนขยายของ Framework หลัก
การตั้งชื่อ
การเขียน Comment
การ Return ค่า
การตรวจสอบ Parameters
4. Transaction System
เกี่ยวกับ Transaction
Transaction คือระบบที่ใช้ในการทำหลายๆ การเปลี่ยนแปลง (เงิน/Item/อาวุธ) พร้อมกันในครั้งเดียว แทนการเรียกฟังก์ชันทีละตัว
ข้อดีของ Transaction:
⚡ Performance ดีกว่า - ทำหลายอย่างในครั้งเดียว แทนการเรียก function ทีละตัว
🔒 ความปลอดภัย - ถ้าทำไม่สำเร็จ ทั้งหมดจะถูก rollback (ไม่มีการเปลี่ยนแปลง)
📝 Log ครบถ้วน - บันทึกทุกการเปลี่ยนแปลงในครั้งเดียว
💾 Save ครั้งเดียว - บันทึกฐานข้อมูลรอบเดียว ไม่ซ้ำซ้อน
เปรียบเทียบวิธีการ
❌ แบบเดิม (ไม่แนะนำ)
✅ แบบใหม่ (แนะนำ) - Transaction
xPlayer.transaction() - Player Transaction
ใช้สำหรับทำหลายๆ การเปลี่ยนแปลงกับผู้เล่น 1 คน พร้อมกัน
Syntax:
Parameters:
transactions(table): Array ของ transaction objectsname(string): ชื่อฟังก์ชัน (addMoney, removeMoney, addInventoryItem, etc.)values(table): Array ของ parameters
ฟังก์ชันที่รองรับ:
addMoney/removeMoneyaddAccountMoney/removeAccountMoneyaddInventoryItem/removeInventoryItemaddWeapon/removeWeaponsetJob/setJob2setMeta
ตัวอย่างที่ 1: ระบบให้รางวัลภารกิจ (แบบง่าย)
ESX.Transaction() - Multi-Player Transaction
ใช้สำหรับทำการเปลี่ยนแปลงกับ หลายคน พร้อมกัน
Syntax:
Parameters:
playerTransactions(table): Object ที่มี key เป็น source/identifier ของผู้เล่น
ตัวอย่างที่ 5: ระบบแลกเปลี่ยนระหว่างผู้เล่น
สรุปความแตกต่าง
ผู้เล่น
1 คน
หลายคน
Use Case
ให้รางวัล, ซื้อของ, คราฟ
แลกเปลี่ยน, แจกของหลายคน
Performance
⚡ เร็ว (save 1 คน)
⚡⚡ เร็วมาก (save หลายคนพร้อมกัน)
Rollback
✅ ถ้าล้มเหลว rollback
✅ ถ้าล้มเหลว rollback ทุกคน
ข้อควรระวัง:
⚠️ Transaction จะ rollback ทั้งหมด ถ้าทำไม่สำเร็จ
⚠️ ต้องตรวจสอบ เงิน, ช่องเก็บของ, น้ำหนัก ก่อนทำ transaction
⚠️ ESX.Transaction() จะล้มเหลว ทั้งหมด ถ้าผู้เล่นคนใดคนหนึ่งล้มเหลว
5. Performance Optimization - เรียกค่าโดยตรง
ปัญหา: เรียกฟังก์ชัน Reference ซ้ำซ้อน
ปัญหาที่พบบ่อย:
เรียก
xPlayer.getName()ทั้งที่มีค่าในxPlayer.nameอยู่แล้วเรียก
xPlayer.getJob()ทั้งที่มีค่าในxPlayer.jobอยู่แล้วเรียก
xPlayer.getInventoryItem('item').countทั้งที่เข้าถึงได้โดยตรงจากxPlayer.inventory['item']
ผลกระทบ:
🐌 ช้าลง (เรียก function ซ้ำเปล่าๆ)
💾 ใช้ memory มากขึ้น
🔄 โหลดของเดิมซ้ำๆ
Auto-Filter จาก imports.lua
เมื่อใช้งาน NC Core มี 2 รูปแบบ:
1. ใช้ imports.lua (แนะนำ) - มี Auto-Filter
ไฟล์: fxmanifest.lua
ผลลัพธ์: เมื่อใช้ imports.lua จะส่งข้อมูลพื้นฐานของ xPlayer และโหลดฟังก์ชันตามที่เรียกใช้จริง (Auto-Filter)
ข้อดีของ Auto-Filter:
✅ Performance ดีกว่า - ส่งข้อมูลเฉพาะที่ต้องใช้
✅ โหลดฟังก์ชันตามต้องการ - ถ้าไม่ได้เรียกใช้ ก็ไม่โหลด
✅ ลด Bandwidth - ส่งข้อมูลน้อยลง
✅ ใช้งานง่าย - เหมือนเดิมทุกประการ
2. ไม่ใช้ imports.lua - ไม่มี Auto-Filter
ถ้าไม่ใส่ @es_extended/imports.lua ใน fxmanifest จะได้ xPlayer ที่มี function references ทั้งหมด ส่งผลให้ข้อมูลใหญ่และช้าลง
ข้อเสียของการไม่ใช้ imports.lua:
⚠️ ส่งข้อมูลมากเกินจำเป็น (ทั้งข้อมูล + functions)
⚠️ Performance แย่กว่า
⚠️ ใช้ Bandwidth มากขึ้น
เปรียบเทียบการเข้าถึงข้อมูล
ชื่อ
xPlayer.getName()
xPlayer.name
อาชีพ
xPlayer.getJob()
xPlayer.job
เงิน
xPlayer.getAccount('bank').money
xPlayer.accounts.bank
Item
xPlayer.getInventoryItem('bread').count
xPlayer.inventory.bread
ตัวอย่างการ Optimize
❌ แบบเดิม (ช้า - เรียก function ซ้ำซ้อน)
✅ แบบใหม่ (เร็ว - เข้าถึงโดยตรง)
รายการ Properties ที่เข้าถึงได้โดยตรง
Best Practices
เข้าถึงโดยตรงเสมอ (ถ้าเป็นไปได้)
Cache ค่าที่ใช้ซ้ำๆ
ใช้
@es_extended/imports.luaเสมอถ้าไม่ใช้ imports.lua ให้สร้าง object ใหม่ที่มีเฉพาะข้อมูลที่ต้องการส่งไป client
สรุป:
✅ ใช้
@es_extended/imports.luaเสมอ (Auto-filter อัตโนมัติ)✅ เข้าถึงค่าโดยตรง (
xPlayer.name) แทนเรียก function (xPlayer.getName())✅ Cache ค่าที่ใช้ซ้ำๆ
✅ ประหยัด Performance ได้ 50-95%!
6. Status System (Client-Side)
เกี่ยวกับ Status System
Status System คือระบบจัดการสถานะต่างๆ ของผู้เล่น เช่น ความหิว (hunger) และ ความเครียด (stress) ที่มีการอัพเดตแบบ Real-time
Status System ทำงานเฉพาะฝั่ง Client เท่านั้น เพื่อประสิทธิภาพและความลื่นไหล
✅ อัพเดตทุกๆ วินาที (ตาม config.status.lua)
✅ Sync กับ Server เมื่อมีการเปลี่ยนแปลงสำคัญ
✅ รองรับการ Freeze/Unfreeze
รายละเอียดของ Status System, ฟังก์ชันหลัก, ตัวอย่างการใช้งาน (ดึงข้อมูล, HUD, Event, Freeze, ส่งข้อมูลไป Server) และ Config (config.status.lua) ถูกระบุไว้ในเนื้อหาเดิมด้านล่าง ซึ่งคุณสามารถคัดลอกไปใช้ได้ตามต้องการ (เนื้อหาเต็มประกอบด้วยตัวอย่างโค้ดและ Best Practices สำหรับการใช้งาน status system แบบ client-side)
สรุปหลัก:
ใช้ Event
nc:onChangeStatusแทน Loop (ประหยัด Performance)ใช้ Freeze/Unfreeze เมื่อเปิด Menu หรือ AFK
เช็คสถานะก่อนให้ผู้เล่นทำอะไร
7. Event System (Client-Side)
เกี่ยวกับ Event System
Event System คือระบบ Listener ที่ ฟังการเปลี่ยนแปลง ของค่าต่างๆ ใน NC Core โดยอัตโนมัติ โดยไม่ต้องใช้ Loop ตรวจสอบ
ข้อดีของ Event System:
⚡ ประหยัด Performance - ไม่ต้อง Loop ตรวจสอบทุกวินาที
🎯 ทำงานทันที - เมื่อมีการเปลี่ยนแปลงเท่านั้น
🔄 ทำงานเมื่อรีสคริปต์ - เหมาะสำหรับ Development
✅ เรียกครั้งแรกเสมอ - ไม่ต้องกังวลว่าพลาด
เนื้อหาเกี่ยวกับการใช้งาน ESX.on, ตัวอย่างการใช้ ESX.on('PlayerLoaded') และ ESX.on('PlayerReady'), ตัวอย่าง Initialize HUD/Blips/Markers, Resource Start/Restart, Debug & Logging, เปรียบเทียบ PlayerLoaded vs PlayerReady และ Best Practices ถูกจัดวางเป็นตัวอย่างโค้ดและคำอธิบายในเนื้อหาต้นฉบับที่ส่งมา คุณสามารถนำโค้ดตัวอย่างเหล่านั้นไปใช้หรือปรับแต่งตามความต้องการได้
สรุปสั้นๆ:
ใช้
ESX.on('PlayerLoaded')สำหรับ Init พื้นฐานใช้
ESX.on('PlayerReady')สำหรับเริ่มระบบหนักเพิ่ม
['PlayerReady'] = trueในconfig/config.functions.luaหากต้องการใช้งาน
Checklist การเพิ่มฟังก์ชัน (ซ้ำ)
Player Class Functions
Modules
Functions
พร้อมใช้งานแล้ว
เลือกหัวข้อที่ต้องใช้ และทดสอบใน resource ของคุณ
Last updated