Badger object hierarchy
There is a bunch of configuration nodes in Badger that allow to represent as GUI object a parameter. They all inherit from ConfigNodeViewModel (if they can't have children) or NestedConfigNode (if they can). These two classes offer the common functionalities and virtual functions that need be implemented by subclasses.
Most of these classes represent a parameter object in a Simion app. For example, in the source code of an app we might have something like this:
CLogger::CLogger(CConfigNode* pConfigNode)
{
m_bLogEvaluationEpisodes= BOOL_PARAM(pConfigNode,"Log-eval-episodes", "Log evaluation episodes?",true);
`m_bLogTrainingEpisodes= BOOL_PARAM(pConfigNode,"Log-training-episodes", "Log training episodes?",false);`
`m_logFreq= DOUBLE_PARAM(pConfigNode,"Log-Freq","Log frequency. Simulation time in seconds.",0.25);`
}
CWorld::CWorld(CConfigNode* pConfigNode)
{
...
m_numIntegrationSteps= INT_PARAM(pConfigNode,"Num-Integration-Steps","The number of integration steps performed each simulation time-step",4);
m_dt= DOUBLE_PARAM(pConfigNode,"Delta-T","The delta-time between simulation steps", 0.01);
}
and, then, it will show up in Badger as:
Forks are the most helpful feature in Badger: they allow users to give several different values to a parameter. Then, Badger will do a parameter sweep, testing all the possible parameter combinations. A fork is a special node in the configuration node hierarchy.