Skip to content

MrTytek/es_extended

 
 

Repository files navigation

ESX 2

Table of Contents

  1. Installation
  2. Modules
  3. Changelog
  4. Module Examples
    1. Menu
    2. Command

Installation

Requirements:

How to Install:

  • Grab the resource, install it as usual (place it in the /resource subfolder of your FxServer).
  • Open a cmd in the es_extended resource.
  • Type npm i or yarn in-order-to install dependents packages.
  • Copy the part of the server.cfg sample and paste it to yours.

Server.cfg sample

# minimum resources and config to get it working

set mysql_connection_string "mysql://john:smith@localhost/es_extended?charset=utf8mb4"

stop webadmin

ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure hardcap
ensure rconlog
ensure baseevents

ensure yarn

ensure mysql-async
ensure cron

ensure es_extended # Will now auto-generate fxmanifest.lua to prevent platform-dependant behavior, will prompt you to type ensure es_extended in console when fxmanifest has changed. To save some typing, uncomment below lines

# stop es_extended
# start es_extended

Modules

There is no more esx_ resource on this version. This had been deprecated in favor of modules

How to install a module ?

Grab the module you'd like to install. Paste it in the es_extended/modules/__user__/ directory and add the module name to the list of the es_extended/modules/__user__/modules.json file. modules.json file should looks like this :

[
  "module-name-here"
]

WARNING: The file may not already exists if it's your first installation, just create a file named modules.json in the es_extended/modules/__user__/ directory.

What's a module ?

A module is an isolated bloc that work independently from any resources or other module (except the core modules provided by esx)

How does modules work ?

Modules are composed of three parts (not mandatory, you can only use of of these) :

  • client - handle all client logic (as usual)
  • server - handle all server logic (as usual)
  • shared - handle both logic

Each part are again divided in three parts in-order-to make things clearer :

  • main.lua : responsible of importing needed core modules and managing the module state. (control flow)
  • events.lua : responsible of handling events (the code to execute when an event is received)
  • module.lua : see this one as all the functions that would be useful to your module.

Why is it better ?

For a better and cleaner architecture it's obviously better to have a pattern already set. You'll end up with organized files and modules.

Another thing is the performance, so far, it's more optimized to work this way.

Changelog

- Switched to a module-based single resource for ease of use and performance
- Performance improvements
- Split all base functionnalities into their own module
- Module can either encapsulate its own functionality or declare global stuff
- Loading modules via method M('themodule') ensure correct loading order of modules
- Automated database schema generation (RIP SQL files everywhere)
- Database schema can also be expanded by other modules
- Custom event system to avoid serialization of event data and cross-resource communication, that make it possible to pass metatables through these events (You can still use TriggerEvent and such to escape that thing)
- xPlayer fully customizable without rewriting core resources (Hello second job, faction system and such...)
- Added some modules to optimize common things like input, marker and static npc management
- Extend base lua functionnality when appropriate via module. example: table.indexOf
- OOP System based on http://lua-users.org/wiki/InheritanceTutorial and improved
- Neat menu API
- Open as many pages as you want in single NUI frame with Frame API
- EventEmitter class
- WIP rewrite of well-known datastore / inventory / account stuff

Module Examples

Menu

More to come...

Packages

No packages published

Languages

  • Lua 92.1%
  • JavaScript 4.3%
  • HTML 2.3%
  • CSS 1.2%
  • TSQL 0.1%