@Arbiter & @Cloud , I have been thinking about the premium system more and more recently and come up with a large array of changes I think could really increase the potential and power of the system allowing bot authors to explore additional options while creating their bots. Below are my ideas my reasoning and how I would go about implementing them. Sorry for such a large post ahead. Limited Instances It would be massively useful to be able to limit your bot to a certain amount of global instances running, for example my Giant Mole I could release on the bot store and then say limit it to 10 bots running at once, so only the first 10 people to spin up an instance at any given time would be able to use it. This will help people who want to sell bots with limited access to not completely destroy the method. Too add further onto this, a local limitation COULD be added too, however personally I don't feel it is necessary. A local limitation would allow you to limit how many a specific User could run at once. Together you can really fine grain the access fairly. Implementation My preferred implementation would be very simple on developers. I would personally just implement this simply into the manifest like this: Code (Text): <maximumInstances>10</maximumInstances> If the bot has no instances currently available, you could make show a visual before they attempt to run the bot that this is unavailable at that time. (Maybe even include how many instances are running of that bot at this current time as a visual?). However upon running the bot it would not even start it and pop up an error saying "This bot is currently limited to 10 global instances, it has reached maximum capacity. Please try again later" Dynamic Costing Dynamic costing is a real must in my opinion. Our current costing is way too rigid and doesn't allow developers to fairly assess their costs. For this I'll use my Blast Furnace as an example however there are probably better examples. With Blast Furnace doing Rune gains around 1m / hr. However Iron is like 300k or something, in such a case I don't want to charge my followers the full cost, I want to maybe only charge them $0.05. However when it comes to Rune I want to change them big money for using such a profitable money making system. Currently I cannot do this without creating a lot of different bots. Having this will really allow developers to freely change their bot costs depending on the activity meaning the customers get a fairer price and are more inclined to pay for the lesser tier requirements. Implementation I would start by allowing the following in the manifest Code (Text): <price>DYNAMIC</price> When seen in the bot store, these bots would display "Price Varies" instead of Free/Supporter/$ amount. By default the bots would start at free, the developers would need to set the price within the bot. I would introduce a method in AbstractBot like so Code (Text): public final boolean setBotCost( int amount ); This would then pop up asking the user if they would like to confirm or deny the new price. With a message like follows; "Prime Blast Furnace is setting the price per hour to $0.05 per hour, are you happy to continue?" With a simple Confirm/Deny. If denied OR the user doesn't have the funds, they boolean returns false so the developer can handle the failure. Initial Payment It would be nice for the current system to add a 2 minute buffer before charging for a bot. I don't think this would be hard to implement but what it would do is mean that if the bot errors or something goes wrong in those first two minutes they do not get charged. This will save bot authors a lot of time refunding people for whatever reason something went wrong. Hopefully I have summarized my points fairly well and made it easy to understand what I would like to see. I also had a point about a specific feature for custom sales, but I believe this can easily be covered under the dynamic costing system now. Please provide feedback lads.
Big fan of the "dynamic costing" idea! People that make 4M should be charged more than people that could potentially (only) make 1M. Overall, great ideas, but I'm really digging the second one
I agree, the dynamic costing I do believe will turn our premium system from a good one to an amazing one. So much flexibility and that is what I wanted to Strive for.
These are very good suggestions and I hope they are implemented ASAP. I'll be trying blast furnace tonight!
Limited Instances: your use case here is very specific and not applicable to 99% of bots. This means a lot of effort for effectively no gain from the person trying to implement it. This also makes incorrect assumptions on the statefulness of how the overall system operates. I personally would reject this idea. Dynamic costs: this was an idea I pitched when premiums were being re implemented. The idea behind this should be "I need multiple bots" not the system needing multiplicity of costs itself. You can have a manifest for each method with different charges all pointing to the same code. From what I know about the workings of the system now the effort required to implement would be more substantial than you realize. Even webservices has been hard coded in such a way to prevent a feature like this. I would reject this idea also. Initial Payment - this one comes closest to viability. Once webservices becomes stable we can discuss options for how to handle startups. I would rather you just pay for time across sessions instead of a grace period. Both systems would be viable if/once webservices begins to manage sessions. I would reject this idea for a simpler hour across sessions format. Something to keep in mind in general is the amount of work required in the systems we have. A good chunk are straight up not possible (total current usage for a specific bot) and some are just not viable to be implemented this century. I agree change is needed but these aren't likely to be it. All in my opinion of course.
>Limited Instances No. "lol u cant bot 2 day cuz u werent fast enuf" I'd rather see an expanded Auth system. X amount of instances per Auth, defined by the manifest. Or, use the hourly/credit system. >Dynamic Costing No. There's no reason to make it more complex. If you really want to split up methods because one does better than the other, then make a separate script bot for it. To me, this is basically the same thing as selling individual scripts bots for a single method. PowerMine Iron: 0.2$/Hour, PowerMine Copper: 0.1$/hour. Gross. >Initial Payment Yes, but there's better ways of solving the issue at hand.
Love all of it. I was considering implementing a "dynamic cost" myself for runecrafting by having one version that just stops if your RC is above a certain level since the profit literally doubles at certain milestones, but I figured it would be too confusing for users. It would be nice to have it as an actual payment system option.
Absolutely no to dynamic pricing. It convolutes an already convoluted system. I'm sure there's plenty of consumers that are turned away by the lack of information on the hourly model, that number will only grow when they find out they'll seemingly randomly occur additional charges.
the instance suggestion seems like it could run into the problem where a few people are monopolizing a whole bot so others don't get to use it. Your example of 10 was low and just an example i understand, but lets say you did a 10 limit for the mole bot then 10 people could just monopolize the bot by never getting off of it and never giving others a chance to try it. defeats the purpose of putting it out on the bot store and simply keeps it as a sort of private bot. Ofc the mole bot was just an example, but i think bot monopolization would apply to anything that doesn't have like 50+ instance limits. dynamic pricing would be dope. ofc as a gold farmer it means i might have to pay more in some cases, but it's honestly just more fair for the low-tier bot farmer/consumer as well as the bot author. Also the people who use certain bots to just level their skills don't have to pay 10c/hr for doing something that they aren't necessarily farming. Only thing is that this sort of idea would only really appeal to the bots that have huge profit discrepancies like the example you used of your blast furnace bot. Something like a fishing bot all makes around the same gp/hr within a few 100k or so, but yeah it would be better.
