Allow a custom system type to be defined for a given task driver type.
This is a workaround to allow developers to order their task driver against other systems/task drivers due to the limitations described in #287
What is the current behaviour?
Developers have no way of ordering their task driver's update within a ComponentSystemGroup
What is the new behaviour?
Developers may pass a type through the constructor parameter customSystemType to specify the system type that their task driver instance is bound to. The explicit cast later in initialization enforces that the provided type is a subclass of AbstractTaskDriverSystem.
If null or no value is provided to the customSystemType parameter the traditional TaskDriverSystem<MyTDType> is used.
Allow a custom system type to be defined for a given task driver type. This is a workaround to allow developers to order their task driver against other systems/task drivers due to the limitations described in #287
What is the current behaviour?
Developers have no way of ordering their task driver's update within a
ComponentSystemGroupWhat is the new behaviour?
Developers may pass a type through the constructor parameter
customSystemTypeto specify the system type that their task driver instance is bound to. The explicit cast later in initialization enforces that the provided type is a subclass ofAbstractTaskDriverSystem.If
nullor no value is provided to thecustomSystemTypeparameter the traditionalTaskDriverSystem<MyTDType>is used.What issues does this resolve?
What PRs does this depend on?
Does this introduce a breaking change?