Closed kozaka-tv closed 1 year ago
I certainly know that it wouldn't be easier to use for the users, which should always be our focus. The benefits do not outweigh the additional effort to leave the program for a reconfiguration and mess with a separate file.
We could however restructure the actions, to have a config subaction as entry point, that calls the main engine. This way it would be easier to upgrade from version to version.
If we shift the config to a different file, that would not even solve the issue you mention for the users, as they have to adapt the file. It just moved the problem to outside of SB, not influencing it.
Yeah. You may have right. To maintain a file or maintain actions in SB is kind the same. But then if everything is in SB, it is easier.
I will create a Discussion out from your idea regarding the subactions....because I do not get it completely.
I do not know, that this would be easy to do, or easy to use by the users, but what if we create a config file (we could use the config.yml for mock) what is red in the SceneSwitcher Action in SB with a sub action and used. Then all the config values could be as key/value in that file and the user must not bother with the version changes. As so far I get, if we introduce a new global variable, the user must create manually the new sub action (setGlobalVariable), or delete everything and import new. But this delete and reimport is annoying and could happen an error during re configure.
What you think?