I simply don’t see any point continuing this argument, since I just listed the benefits above. In closing it’s not unusual for the costumer having to pay for tools that help the developer create their resource, and it shouldn’t be for FiveM related content either. 
1 Like
You got so much good feedback, but it’s a pity that you don’t perceive it.
| Code is accessible | Yes |
| Subscription-based | No |
| Lines (approximately) | ~550 |
| Requirements | Standalone |
| Support | Yes 
|
We simply have to disagree, again I see no issue wanting compensation for your time. And it’s my fundamental belief that funding increases motivation for continued development.
aint no way
I think the idea is great, I do agree that a customer shouldn’t be paying for the tool that a developer used to help with the development process.
This is plain and simple a dependency, those kinds of assets shouldn’t be put behind a paywall unless they’re a game-changer with tons of features that work for both the developer and the customer. Dependencies are what keep the machine going, you can’t simply think that it’s fair for a customer to have to pay for 1 item that does nothing for them other than make one script become useful.
Once it has more features, what’s your pricing range exactly? What happens to scripts that use your dependency when you increase the price and suddenly people can’t afford it for whatever reason (Just F* them and have them switch = more money they have to spend = less money the developer will make)?
Those are questions you should be making yourself, because regardless of if it’s 5 or 10 bucks you will have to answer those questions sooner or later. I truly think you have a great idea (As pointed out by most people) but your focus is on the wrong thing.
This interpreter you’re developing screams Open Source all the way through.
2 Likes
If I could only charge the developer for the resource, trust me I would. This is simply out of the realm of possibilities if the resource has to be sold on Tebex, which is required by FiveM. Therefor as discussed in the thread a commission for the sale would be ideal, and also therefor I’ve requested such feature on Tebex Ideas. So in short the reason the end-costumer has to pay for the dependency is cause I can’t charge the creator of the resource in any other way.
In regards to the pricing range, it will always cost $2.95, the original idea was actually to put out a lower “launch price”, but since I’m not able to create coupons for the launch, and don’t want to raise the price from the original one, it simply had to be $2.95, and always will be.
Glad you could see the potential in the resource, and kept it civil. I will be continuing development, and hopefully the price of $2.95 will be justified if not now, then with the additional upcoming features.
In terms of “it will always cost $2.95”, to kind of back track a bit. Pricing will change if for an example commission becomes a possible solution (This one I would prefer), or I might create optional extensions for it, if funding isn’t sufficient to continue maintenance.
Great idea. But as pointed out by everyone on the thread: Custom should not pay for your resource, only developers should.
As an example, imagine if a Jetbrains created a policy that every developer who releases a software using thier paid IDE should also tell their customs to buy the license for their IDE else the software they created won’t work.
This is a basic principal. You never ask the customers of the customers to pay. You only YOUR customers to pay whatever amount you think is justifiable
Simple solution, don’t encrypt it. If you’re worried about it getting leaked then include strict license which requires any creator using this to include this in their escrow bundle.
I’ve rethought the pricing model based your guys’ input. I am thinking about changing it to license key model. Here a developer will buy a license per script basis. That way the consumer wouldn’t have to pay any additional fee for the script, and isn’t required to pay monthly either. Please let me know if this would be a more viable solution. 