I recommend making the framework code, open so people can edit it to fit their own framework.
The only things in here related to framework should be job check and item registration, which, that code if escrowed, doesn’t need to be as that isn’t proprietary code to your scripting.
Otherwise I have to oblige, will you be making an ESX version?
ESX = exports[“es_extended”]:getSharedObject()
should look recognizable compared to QB’s
ESX.RegisterUsableItem(item, cb)
similar to
QB.Functions.CreateUsableItem() or w/e that function is
Alternatively, there are servers using ox_invnetory which has its own method of creating usable items and utilizing exports independent of framework.
Any QB functions for notif’s or menus should be exposed so people can replace those with their menu’s of choice.
All of your functions responsible for controlling traffic behavior should be escrowed, and everything else should be editable.
I understand protecting your work and I 100% support that, but as developers, we need to either: A. dev around the needs of our customers and their environments
or B. Make the code dev friendly for them to implement into their suitable framework.
This script looks really good, I hope you take what I’ve said into consideration.
(again, idk what is and isn’t escrowed in your script so you may have done this already, so I apologize for this rant if you have )
I always welcome feedback
more then a few people now have asked be for a esx version so it will defenitly be something that i will do
Normaly i fully escrow my scripts, but i make extremely customizable configs , it requires more code for different settings , but like that i do keep my code protected while giving people to option to edit it to their needs
Within a week / 2 weeks the esx version should be placed onto my tebex