This thread is dedicated to giving developers some rough guidance when it comes to the best practices for getting their code to fit into the design of Exilebuddy. Over time it will be updated with issues people run into, and how they can avoid them.
1. Initialization logic should mostly take place in Initialize; not in static initializers.
When user code is compiled and loaded by EB, any static initialization logic is executed. Depending on when this takes place, the state of the bot is not guaranteed to be the same as previous expected. Anything coded with such assumptions should be avoided so your code doesn't break. For example, if you have static initialization logic that attempts to get the current bot, and invoke the Execute function, you have no guarantee there even exists a current bot yet, so you should defer such logic until you actually need it. Exceptions to this guideline are simple .Net classes/types that have no dependency on EB itself. Creating a new Stopwatch is perfectly fine, as is storing the ILog instance for the current type.
2. Avoid pre-maturely caching anything before Start, and after Stop.
If you cache data before Start is called, the bot might change, enabled plugins might change, and so on. Caching is useful in some situations, but it's ok to instead implement a property whose get implementation simply executes the logic, in which you use the result of that for the current Tick. Performance issues can result from the lack of using caching in places where needed, but faulty code can result if you simply cache everything without first understanding when or why it can change.
3. Your content should attempt to play nicely with Exilebuddy's intended design.
Users should not force enable their plugins, or hook into the bot unless their plugin is enabled (this is easily done if you simply hook in Start and unhook in Stop). Try to avoid intentionally breaking other plugins or Exilebuddy by changing something commonly used, unless you're warning people this is how your plugin works. We try to give developers the flexibility needed to do what they need, but life is easier if everyone tries to get along.
4. Make use of the logging system.
While a lot of people don't like log files and a lot of logging, comprehensive logging can help identify issues when they occur, with minimal user involvement. Please be sure not to log sensitive data such as character names or the like, or anything that could trivially give away someone's account. The implementation of certain content EB provides does need logging revamps to be less spammy, but the current setup was a necessity due to the way the game worked, and things that were breaking in the bot.
5. Any files the user can change should be stored in the Settings path for the current configuration.
Settings and user configurable files should be stored via the Settings path for the current configuration, not in the current directory for code. To get the relevant path, you simply need:
* Configuration.Instance.Path will be added in the next Beta as a convenience property.
6. <Todo>
1. Initialization logic should mostly take place in Initialize; not in static initializers.
When user code is compiled and loaded by EB, any static initialization logic is executed. Depending on when this takes place, the state of the bot is not guaranteed to be the same as previous expected. Anything coded with such assumptions should be avoided so your code doesn't break. For example, if you have static initialization logic that attempts to get the current bot, and invoke the Execute function, you have no guarantee there even exists a current bot yet, so you should defer such logic until you actually need it. Exceptions to this guideline are simple .Net classes/types that have no dependency on EB itself. Creating a new Stopwatch is perfectly fine, as is storing the ILog instance for the current type.
2. Avoid pre-maturely caching anything before Start, and after Stop.
If you cache data before Start is called, the bot might change, enabled plugins might change, and so on. Caching is useful in some situations, but it's ok to instead implement a property whose get implementation simply executes the logic, in which you use the result of that for the current Tick. Performance issues can result from the lack of using caching in places where needed, but faulty code can result if you simply cache everything without first understanding when or why it can change.
3. Your content should attempt to play nicely with Exilebuddy's intended design.
Users should not force enable their plugins, or hook into the bot unless their plugin is enabled (this is easily done if you simply hook in Start and unhook in Stop). Try to avoid intentionally breaking other plugins or Exilebuddy by changing something commonly used, unless you're warning people this is how your plugin works. We try to give developers the flexibility needed to do what they need, but life is easier if everyone tries to get along.
4. Make use of the logging system.
While a lot of people don't like log files and a lot of logging, comprehensive logging can help identify issues when they occur, with minimal user involvement. Please be sure not to log sensitive data such as character names or the like, or anything that could trivially give away someone's account. The implementation of certain content EB provides does need logging revamps to be less spammy, but the current setup was a necessity due to the way the game worked, and things that were breaking in the bot.
5. Any files the user can change should be stored in the Settings path for the current configuration.
Settings and user configurable files should be stored via the Settings path for the current configuration, not in the current directory for code. To get the relevant path, you simply need:
Code:
// This is called inside a plugin, so Name is the IPlugin.Name property.
// You can use whatever name for your settings folder though, just keep all your files inside your own folder.
var settingsDir = Path.Combine(Configuration.Instance.Path, Name);
Directory.CreateDirectory(settingsDir);
// Now use settingsDir as your base path for files.
// Path.Combine(settingsDir, "local/path/file.ext")* Configuration.Instance.Path will be added in the next Beta as a convenience property.
6. <Todo>
