Add way to instantiate indicator with default parameters, instead of having to supply EVERY PARAMETER

I have an indicator with over 20 parameters.

If I want to use this indicator in a cBot, I have 2 problems.

1. If I want to allow the user to customise the parameters of the indicator within the cBot, I have to create parameters for the cBot for every parameter of the indicator. So if my cBot uses an indicator with 20 parameters, my cBot also needs an extra 20 parameters.

2. If I want to instantiate the indicator, I have to provide EVERY SINGLE PARAMETER to GetIndicator<T>. That is very annoying, because it means that whenever I change the order/name/type of ANY of the parameters in the indicator, I have to make changes to the cBot GetIndicator call, as well as the parameters of the cBot. This is annoying and causes update anomalies.

At the very least, I should be able to instantiate an indicator without having to supply EVERY parameter, only some of them. And the ones I don't supply will have their default value.
I presume that GetIndicator<T> is using reflection PropertyInfo magic to instantiate indicators.

USING DICTIONARIES
A possible way to allow us to instantiate indicators by passing some or none of the parameters would be to have GetIndicator take a Dictionary<string, object> that would map each key/value to a property on the indicator, and the rest would be assigned their default values.

INDICATORS WITH PUBLIC CONSTRUCTORS
Or a better way, but would take more effort, would be to change the way indicators are created, so that instead of using GetIndicator, we could create them normally with constructors, and the code that creates the indicator could be called inside of the cAlgo Indicator base class.

Since we're on .NET 6 now, we have init only setters, so no need to have every parameter in the constructor, we can use nice object initializer syntax like cool kids. So indicator constructors need not even supply any parameters! 

var myIndicator = new IndicatorName
{
    Param1 = 2,
    Param3 = 5
};

Wow!

And cAlgo could do all the code to set up the indicator behind the scenes after the object has been initialized. 

I'm sure this is all easier said than done, because object initializers are called after the constructor, so you'd have to figure out how to know when the class has been constructed, and then set up the indicator (or just have the user call an init function, but that's not the best imo).