Simplified customization for TurboHUD

[KillerJohn]

This thread is created to discuss a simplified configuration interface for TurboHUD plugins.
I would like to discuss this topic with mainly plugin developers.

Even the C# "Customize()" method is way too complex for most regular users.

We need a simplified way to customize plugins.

requirements:
- persist user settings in 1 or more files
- if a setting is invalid, just ignore it and allow the plugin to use default settings (example: the property behind the setting is no longer exists in the plugin, or just renamed)
- support basic property value types: integer, float, double, bool, IFont, IBrush, ITexture (any more ideas?)
- special property values (lists, dictionaries, enumerables, delegates, etc) are not in the scope of this tool
- integrated into HUD itself, so it will be unaware of any classes/types in the plugins (decorators, etc)

[johnbl]

KJ, if something like TCT could be integrated into TH, it would definitely make life easier for new users.

You could also get some ideas from PoEHUD. It allows customization from inside the game, using a tree-like menu.

[User5981]

Hard for me to imagine something else... But here are some ideas :
A key launching a window with a user interface featuring an "apply & restart TurboHUD" button.
Using a special PluginSettings class, available settings could be displayed (including a setting description text) & set in the interface.
One page per plugin, default plugins separated from custom ones.

[icheck]

I think it's a good idea, it would be useful for those who do not know how to edit those files without spoiling them. For compatibility, in my opinion, I would have to work on the PluginEnablerOrDisablerPlugin.cs instead of having my own configuration file. Initially I could modify the simplest types of data such as boolean, and gradually expand, and leave the more complicated parameters to edit them by hand for those who know how to do it.

[KillerJohn]

1) add Winforms window UI into HUD, activated by hotkey
2) display all plugins and suppprted properties in a tree (discovered by reflection)
3) on close, persist changes in two files: a well structured file (xml, json, or binary) and a generated 'customizer' plugin C# file
4) on open always read data from the structured file

opinions?

[User5981]

1) add Winforms window UI into HUD, activated by hotkey
2) display all plugins and suppprted properties in a tree (discovered by reflection)
3) on close, persist changes in two files: a well structured file (xml, json, or binary) and a generated 'customizer' plugin C# file
4) on open always read data from the structured file

opinions?

Sounds good :-)

[bm206]

I think the effort is too big. Most users use a complete plugin package from a clan user who knows about it. For all plugins, only the text needs to be copied to a cs file. If adjustments are required for the plugin, these are specified by the creator. Here it would only help to offer these adjustments as a separate config file. This is where most mistakes happen. So one config file per plugin. Then only true / false would have to be changed.

[JarJarD3]

Easy configuration without C# is great idea for both end users and plugin developers a like!

UI would be nice and convenient for most users.
As a programmer I prefer text files for configuration (most of the times) and definitely for the initial version (to make it work).

Could you first persist all settings (from all plugins) in the text config file.
In practice this requirement would mean that on startup all plugins has to inspected and the text config file synchronized with actual plugin "settings".
Add new and remove deleted settings but do not touch existing settings as user may have modified them.

Property files (.properties - Wikipedia) are my favorites.
There are other popular text formats for config files as well (like YAML).
Which is easiest to read and write could be one selection criteria if good UI is provided.

UI needs to have "reset to default" option for each plugin.
UI could notify about new plugins or settings (nice to have feature).

[JarJarD3]

I think the effort is too big. Most users use a complete plugin package from a clan user who knows about it. For all plugins, only the text needs to be copied to a cs file. If adjustments are required for the plugin, these are specified by the creator. Here it would only help to offer these adjustments as a separate config file. This is where most mistakes happen. So one config file per plugin. Then only true / false would have to be changed.

It is true that work estimate for this feature is quite big.
Maybe (optimistically) 2-3 days for the code to persist plugin settings from and to a config file using reflection etc..
I suggest breaking changes without backwards compatibility as existing plugins can be configured already using original method.
New settings should use new Configuration interface or maybe annotations would be easier and better suited for this kind of task.

I can not even estimate work amount for the UI task, definitely a much longer time than persisting the settings.

[bm206]

But don't break old plugins. There are so many useful plugins, but their developer is gone...

[User5981]

But don't break old plugins. There are so many useful plugins, but their developer is gone...

We can upgrade them to the new system, I don't think there are so many useful abandonned plugins...

[johnbl]

I think there are quite a few useful abandoned plugins. The thing is that they are still working with the latest TH so nobody complained yet.

[User5981]

I think there are quite a few useful abandoned plugins. The thing is that they are still working with the latest TH so nobody complained yet.

I would be interested in having a list of those.

[JarJarD3]

But don't break old plugins. There are so many useful plugins, but their developer is gone...

It is better to leave current plugins "as is" and new plugins has to implement a configuration API or use annotations for configurable settings in order to use proposed configuration UI.

[JarJarD3]

It is better to leave current plugins "as is" and new plugins has to implement a configuration API or use annotations for configurable settings in order to use proposed configuration UI.

I vote for annotations as they are easy to use and easy to implement.