Come vendere script FiveM: Tebex, Cfx.re escrow, packaging e supporto

Hai scritto uno script che funziona sul tuo server, e altri proprietari di server lo pagherebbero. Tra « funziona » e « le persone possono comprarlo » c'è un negozio, un metodo di consegna, packaging e supporto. Questa guida va attraverso ogni step nell'ordine che li incontrerai.

#Scegli dove vendere

La maggior parte degli script FiveM sono venduti attraverso un negozio Tebex. Tebex gestisce i pagamenti, le tasse, i rimborsi, i codici di sconto e la consegna. Per una consegna protetta, colleghi il tuo negozio Tebex con il tuo account Cfx.re, e lo script è consegnato come una risorsa asset escrow: all'account Cfx.re dell'acquirente è concesso l'accesso, e i file criptati girano solo per quell'account.

Il negozio ha bisogno di essere presentabile. Un tema gli dà pagine di prodotto, categorie e un checkout pulito; il template Tebex nel negozio di Mic Scripts è un'opzione:

Tebex TemplateUn tema premium senza codice per il tuo negozio Tebex, modificabile interamente dal pannello Tebex.da 30,25 €Vedi lo script →

Segui la documentazione attuale di Tebex e Cfx.re per come collegare gli account, poiché i menu e i requisiti cambiano.

#Prepara la risorsa

Una risorsa vendibile è più che i file Lua. Controlla ogni punto prima di caricare:

• fxmanifest.lua con fx_version 'cerulean', game 'gta5', una riga lua54 'yes' se la usi, linee dependency per ox_lib, oxmysql o un framework, e una version.
• Un config.lua con ogni valore che un acquirente ha bisogno di cambiare: prezzi, località, keybind, lingua, scelta del framework.
• Locale, così i server non-inglese possono usarlo. Vedi script traducibili.
• SQL in un file, come install.sql, se lo script ha bisogno di tabelle. Idealmente lo script crea le sue tabelle all'avvio, così gli acquirenti non dimenticano.
• Un README con passi di installazione, dipendenze, le righe server.cfg da aggiungere, e il test al primo avvio.
• Articoli e job per ESX, QBCore e QBox se lo script li usa. Fornisci frammenti per ognuno, come in aggiungere articoli ox_inventory e aggiungere un job su ESX.

Decidi quali file rimangono aperti. Config, locale e framework bridge sono i soliti; vedi escrow_ignore.

#Carica e testa la build escrow

Carica la risorsa nel portale Cfx.re come asset escrow, collegala al pacchetto Tebex, poi scaricala di nuovo come un acquirente potrebbe e eseguila su un server pulito. Questo cattura file aperti mancanti e problemi di cifratura prima che un cliente lo faccia. escrow lack entitlement è l'errore che gli acquirenti vedranno se la chiave e l'account non si abbinano, quindi risponderai a quella domanda spesso.

Suggerimento: compra il tuo prodotto una volta con un account diverso. È l'unico modo per testare l'intero percorso dal checkout a una risorsa in esecuzione.

#Versioning e changelog

Usa versioni semantiche: 1.0.0, 1.1.0 per le funzionalità, 1.1.1 per le correzioni. Metti la versione nel manifest:

version '1.2.0'

Tieni un CHANGELOG.md nella risorsa e nella descrizione del negozio:

## 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)

Dì nel changelog quando un cambio ha bisogno che gli acquirenti modifichino la loro config o database. Le sorprese all'aggiornamento sono la ragione più comune per le recensioni cattive.

#Documentazione

Una buona pagina di docs previene cento messaggi di supporto. Non ha bisogno di essere elegante:

• Installazione in passi numerati, con le esatte righe ensure e l'ordine di avvio.
• Configurazione spiegata, chiave per chiave.
• Export e event che altri script possono usare, con esempi.
• Troubleshooting: i tre errori che le persone colpiranno e le loro correzioni.

Schermate e un breve video dello script in uso aiutano gli acquirenti a decidere prima di pagare.

#Supporto

Decidi come fornisci supporto e dilo nella pagina del prodotto. Un server Discord funziona bene: un canale per prodotto, un ruolo per gli acquirenti, e messaggi FAQ fissati. Imposta aspettative su tempi di risposta, e scrivi quali problemi copri (bug nel tuo script) e quali no (un conflitto con una risorsa non correlata fortemente modificata).

Rispondi alla stessa domanda due volte, e appartiene nella documentazione.

#Nozioni basilari di licenza

Dichiara i termini dove gli acquirenti possono vederli, nella descrizione del prodotto o un file LICENSE:

• Una licenza, un server è il modello comune: l'acquirente può eseguire lo script sul loro server.
• Nessuna redistribuzione o rivendita dei file, quelli aperti inclusi.
• Cosa gli acquirenti possono cambiare: possono modificare file aperti per il loro uso.
• Rimborsi e aggiornamenti: dì se gli aggiornamenti sono inclusi e per quanto tempo.

Escrow applica l'accesso ai file criptati, ma i termini coprono il resto. Se i tuoi termini hanno bisogno di essere legalmente a prova di bomba, chiedi a un professionista; questa guida non è un consiglio legale.

#Checklist