Guidelines for Plugin Creation
UBot Studio, as it stands, is the most powerful web automation tool on the internet. With the ability to add plugins, its power is only limited by the creativity of its contributors. A UBot Studio plugin is a class library (a .dll) that expands the functionality of UBot Studio, usually by adding commands and functions.
UBot Studio plugins are written in C#, or alternatively, Visual Basic.Net. If you do not yet know either of these languages, you can learn C# here. If you are already comfortable with C#, then you are ready to start creating plugins: Plugin Development.
By adding functionality, you have increased the potential power of UBot Studio. Chances are good that if your plugin is of good quality, other people will benefit from it as well. By contributing to the UBot Union, UBot’s open source initiative, you will receive status, admiration, and respect from the larger community of UBot users and creators. You may also be eligible for various perks provided either by the community, or the UBot team.
While we strongly encourage participation in the UBot Union, we do also allow for the sale of plugins as well. If a plugin is particularly appealing, the UBot team may make an offer to buy the plugin outright, to then offer for free to the community. Otherwise, you may purchase a license to sell your plugin to the community.
When you create a UBot Studio plugin, at first, installing it in UBot Studio will result in a nag screen every time you use it. To get rid of the nag, you must get a plugin key. Plugin keys exist to help us control the quality of plugins that are created for UBot Studio.
If you plan to contribute to the UBot Union, plugin keys are free. Simply contact support with your plugin idea and they will guide you on how to create it. If you plan to create a commercial plugin, contact support with your plugin idea and they will either make an offer to buy your plugin, or give you the price of the development key for your project.
Plugin Quality Standards
It is very important that UBot commands and functions maintain a very high level of quality, and this is a standard that must extend to plugin commands and functions as well. Plugin developers should have a solid understanding of C# and object oriented programming. An understanding of software usability is also important.
Before starting on a new open source plugin, check to see if your idea already exists in some form . If it does, you may contribute to the existing plugin to increase its code quality, or perhaps add new features to it. If no similar plugins exist, you are free to create your own.
Commands and functions should be given names that are as short as possible, but descriptive of the command in a way that lets the user understand what it does without further documentation. I’ll note that this is often easier said than done, and can require very deliberate thought, and possibly the mental contribution of colleagues as well. Taking your time on this pays off. The name “sort” is less effective than “sort table”, but the name “sort table rows and columns” is probably unnecessary, as the “rows and columns” part is probably inferred by the end user.
Parameters should be named with the same rigor as the command and function names themselves. Parameters are generally one or two words, but if more explanation is needed, 3, 4, or 5 words can be used. As a matter of convention, all commands and functions should be named in all lower case. Parameters should be labeled in title case (with the first letter of each word capitalized).
Plugins should strive to get the most done with the fewest number of commands/functions, but commands/functions should try to strive for the fewest number of parameters. Commands/functions should also clearly accomplish one goal or concept.
For example if you wanted to create a plugin to play various system sounds, it would be unwieldy to have a command for each, such as “play beep sound”, “play asterisk sound”, “play hand sound”. It is better to create a single command called “play system sound” that uses a drop down box as a parameter to choose which sound you wish to play. It would, however, be confusing to use the same command to also play sounds based on wave files. Instead, create another command with a single “File” parameter. You might be tempted to name the second command “play custom sound” to juxtapose it from the other command, but simply naming it “play sound” is probably better.
Commands and functions should try to solve as many problems as possible. If a commands only addresses one specific issue for one specific script or website, it is not as good as a command that can be used in a variety of scripts and situations. If your commands idea only solves one problem, try to think of how you might adapt it to solve multiple problems. Keep in mind that each new command adds to the learning curve of the software and makes uScript more cluttered and confusing. Adding a new command or function means that its level usefulness must justify its adding to the learning curve.
Important Points to Keep in Mind
1) When you release a paid plugin to the community, in your support ticket request for the plugin key, you must specify the entire feature set of that plugin. It is important when you purchase your plugin that you do not then add to the plugin in substantial ways, besides bug fixes.
2) Please remember to use the API's UBotVersion property if you are adding any features that relate to current UBot Studio features which are only functional in Professional or Developer. As an example, if you are expanding on the whitelabeling feature, this command should only be available to users of the Developer Edition.