Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Derived from the concept found in #10597, but generalized to allow for custom implementation in class modules.
Significant outstanding issues:
Error with merging enemy action lists. (undiagnosed, likely due to cancel position)sim_controller_t::evaluate_*calls. Makes it impossible to validate on objects such as secondary stats, etc.Is there a better way to identify if aCurrent strategy seems satisfactory. Can remove all risk by causing the relevant sim controller options to only be instantiated on profilesets. The inverse of this behaviour exists already (skipping profileset opt parsing for profileset child sims).sim_tinstance is a profileset? Currently usingparent != nullptr && profileset_enabledwhich is not spectacular.TODO:
Current return value ofsim_controller_t::set_data<T>(...)is stupid. Probably should just be void, as asim_controller_t::get_data<T>(...)for an improperly initialized derivedsim_controller_tis an error which already asserts.Usingsim_t::cancel()does not clearly report what is occurring when a profileset gets eliminated.std::shared_ptr<sim_controller_t>is not a good fit.Simplify reporting methods,hook up tojsonandhtmloutputs.Developer interface issues:
sim_controller_trequires ausing data_t = <derived from sim_controller_data_t;type alias. Every controller probably should get and set a derivedsim_controller_data_t, just for the sake of reporting.sim_controller_t::get_data()is debatably a footgun. It's relatively uncommon in the simc codebase, but if the lock is not captured (which is prohibited as of time of writing via private), the temporary's lifespan will lapse prior to the end of theevaluate_controller_*method returning. This is very bad.sim_controller_t::get_data<T>()andsim_controller_t::set_data<T>(...)require a template parameter which is always equal to the type-aliaseddata_tfor the derivedsim_controller_t. This kind of sucks, but I'm not sure of a way to avoid this without introducing manual mutex management and gratuitous casting.Return value semantics ofSettled onsim_controller_t::evaluate_*methods is somewhat awkward, but I haven't convinced myself if one is better than the other. ("keep going" => true,"keep going" => false)"keep going" => true.