New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Game initialization using BootStrap classes will not work #189
Comments
I followed your example in the latest commit for the default broker - is this still an open issue? |
The implementation in DefaultBrokerInitializationService is not quite correct. The setDefaults() method is supposed to create the PluginConfig with default values, and the initialize() method is supposed to apply the values when the game starts. The reason for this separation is to make the default values available for inspection/modification before starting a game. I believe this is documented in the commentary on InitializationService. |
Ok took care of it for the default broker. |
This issue appears to be resolved. |
I have written a detailed description of the problem on Nabble. This issue should result in most or all of the existing BootStrap code being moved, and an updated CompetitionController. This process also requires formalization of plugin role names. I suggest we use the CamelCase versions of the names we are using for the plugin repos, so that would be AccountingService, BrokerDefault, Genco, etc. However, some plugins are members of a set of alternatives, such as auctioneer-pda and auctioneer-cda. I suggest that the role name in this case be Auctioneer. These names can then be used to qualify the names of the InitializationService subclass services, as in AccountingServiceInitializationService. This will work in all cases, as long as we don't have two plugins in the same role that use the same package names. This could possibly happen with Customer models.
The text was updated successfully, but these errors were encountered: