Cómo vender scripts de FiveM: Tebex, escrow de Cfx.re, empaquetado y soporte

Escribiste un script que funciona en tu servidor, y otros propietarios de servidores pagarían por él. Entre «funciona» y «la gente puede comprarlo» hay una tienda, un método de entrega, empaquetado, y soporte. Esta guía va a través de cada paso en el orden que los encontrarás.

#Elige dónde vender

La mayoría de los scripts de FiveM se venden a través de una tienda de Tebex. Tebex maneja pagos, impuestos, reembolsos, códigos de descuento y entrega. Para entrega protegida, vinculas tu tienda de Tebex con tu cuenta de Cfx.re, y el script se entrega como un recurso activo escrow: a la cuenta de Cfx.re del comprador se le otorga acceso, y los archivos encriptados solo se ejecutan para esa cuenta.

La tienda necesita ser presentable. Un tema le da páginas de productos, categorías y un checkout limpio; la plantilla de Tebex en la tienda de Mic Scripts es una opción:

Tebex TemplateUn tema premium para tu tienda Tebex, sin código y editable desde el panel.desde 30,25 €Ver el script →

Sigue la documentación actual de Tebex y Cfx.re para cómo vincular las cuentas, ya que los menús y requisitos cambian.

#Prepara el recurso

Un recurso vendible es más que archivos Lua. Comprueba cada punto antes de cargar:

• fxmanifest.lua con fx_version 'cerulean', game 'gta5', una línea lua54 'yes' si la usas, líneas dependency para ox_lib, oxmysql o un framework, y una version.
• Un config.lua con cada valor que un comprador necesita cambiar: precios, ubicaciones, keybinds, idioma, elección de framework.
• Locales, para que servidores que no hablan inglés puedan usarlo. Consulta scripts traducibles.
• SQL en un archivo, como install.sql, si el script necesita tablas. Idealmente el script crea sus propias tablas en el primer inicio, así que los compradores no olvidan.
• Un README con pasos de instalación, dependencias, las líneas de server.cfg para añadir, y la prueba de primer inicio.
• Elementos y trabajos para ESX, QBCore y QBox si el script los usa. Proporciona fragmentos para cada uno, como en añadir elementos de ox_inventory y añadir un trabajo en ESX.

Decide qué archivos permanecen abiertos. Config, locales y puentes de framework son los habituales; consulta escrow_ignore.

#Carga y prueba la compilación escrow

Carga el recurso al portal de Cfx.re como un activo escrow, vinculalo al paquete de Tebex, luego descárgalo de nuevo como lo haría un comprador y ejecútalo en un servidor limpio. Esto atrapa archivos abiertos faltantes y problemas de encriptación antes de que un cliente lo haga. escrow lack entitlement es el error que los compradores verán si la clave y la cuenta no coinciden, así que responderás esa pregunta a menudo.

Consejo: compra tu propio producto una vez con una cuenta diferente. Es la única forma de probar todo el camino desde checkout hasta un recurso en ejecución.

#Versionado y changelogs

Usa versiones semánticas: 1.0.0, 1.1.0 para características, 1.1.1 para correcciones. Pon la versión en el manifiesto:

version '1.2.0'

Mantén un CHANGELOG.md en el recurso y en la descripción de la tienda:

## 1.2.0
- Added: config option for a cooldown
- Fixed: error when the player has no job
- Changed: locale files use the new key names (see README)

Di en el changelog cuándo un cambio necesita que los compradores editen su configuración o base de datos. Las sorpresas en la actualización son la razón más común para críticas negativas.

#Documentación

Una buena página de documentación previene cien mensajes de soporte. No necesita ser elegante:

• Instalación en pasos numerados, con las líneas ensure exactas y el orden de inicio.
• Configuración explicada, clave por clave.
• Exportaciones y eventos que otros scripts pueden usar, con ejemplos.
• Solución de problemas: los tres errores que la gente hará y sus soluciones.

Las capturas de pantalla y un video corto del script en uso ayudan a los compradores a decidir antes de pagar.

#Soporte

Decide cómo proporcionas soporte y dilo en la página del producto. Un servidor de Discord funciona bien: un canal por producto, un rol para compradores, y mensajes de FAQ fijados. Establece expectativas sobre tiempos de respuesta, y escribe cuáles son los problemas que cubres (errores en tu script) y cuáles no (un conflicto con un recurso modificado sin relación).

Responde la misma pregunta dos veces, y pertenece a la documentación.

#Conceptos básicos de licencias

Establece los términos donde los compradores puedan verlos, en la descripción de la tienda o un archivo LICENSE:

• Una licencia, un servidor es el modelo común: el comprador puede ejecutar el script en su propio servidor.
• Sin redistribución o reventa de los archivos, incluidos los abiertos.
• Lo que los compradores pueden cambiar: pueden editar archivos abiertos para su propio uso.
• Reembolsos y actualizaciones: di si las actualizaciones están incluidas y por cuánto tiempo.

Escrow refuerza el acceso a los archivos encriptados, pero los términos cubren el resto. Si tus términos necesitan ser legalmente impermeables, pide a un profesional; esta guía no es asesoramiento legal.

#Lista de verificación