Bis have an excellent document describing the architecture of model.cfg's
Note this describes the architecture .
At first glance, the contents of model.cfg's appear to be nothing more than just another variation on config.cpp's and rvmats
There are subtle differences.
In any other parmfile you need to use __EVAL and __EXEC to produce constants for sqx verbs.
example:
degrees=__EVAL(rad 90); // in a config.cpp
angle=rad 90; // in a model.cfg
angle=-rad 90;
angle=rad -90;
because the sqx language is inherent, these two booleans are pre-defined. In a config.cpp they are not hence.
#define true 1 // an integer
#define false 0 // an integer
do not define them in a model.cfg. They are booleans and the bis parser will not understand what you did
in config.cpp
class whatever; // simply tells the engine to look for it in some other pbo.
in a model.cfg
class whatever; // tells bis binarise to look for it right now in a parent\folder.
the rules are, this parent model.cfg must be named, "model.cfg"
if the class is not defined in that model.cfg, it will backtrack to the next parent.
and so on, all the way back to the root of the P drive (this is the only time in all of bis tools where the root of P is insprected. All other times, tools stop at Pdrive: myProject
Typical for bis, if it can't find this class it ignores the problem.
Typical of pboProject, if it can't find the class, it screams at you.