It’s probably the most asked question for any new starter when it comes to playing with cfg files and setting up your own build. As far as many of us are concerned, the golden rule of cfg editing is:
‘ Don’t edit any of the delivered cfg files.’
There is no negotiation in this one as you’re only opening yourself up to issues with versioning and much more.
OK, with that rule burned into memory, what can be considered the best option? Well, for me, the best way to play or build your own CAD environment is to start with a blank cfg file in the config>appl directory. The reason I start here is, most importantly, the cfg load order that MicroStation uses. This can be found at the start of the msconfig.cfg file and tells us which config files MicroStation uses and when. This looks like:
#----------------------------------------------------------------------
#
# Levels are defined as follows:
# 0) System Level
# 1) Application Level
# 2) Site Level
# 3) Project Level
# 4) User Level
The application level is that defined by the cfg files located in the config>appl directory. Basically, what this means is that nu variable set here will override those set at the system level by MicroStation. This is important when it comes to debugging your build variables if you make an error.
The one issue with using this location is that it can be hard to change\update cfg files in this directory as they reside on each users machine. As such, what I do is use my custom cfg file to point to my ‘site level’ cfg files. The way I do this is to have a series of variables in my application cfg file that set directory location that are then used to set the site level or the variable _USTN_SITE.
%if exists ($(build_drv)Standard/$(STD_MS)/Standards/.)
_USTN_SITE = $(build_drv)Standard/$(STD_MS)/Standards/
%endif
The important thing to remember about this variable is that it sets a directory location ONLY and not a file name. The reason for this is that any cfg file found here is automatically read so be careful what you have sitting around. Only have cfg files you need here.
To start with you can use a single cfg to play with setting your build variables. As you get more confident, I would split out you cfg files to make them easier to debug and load. You’ll find more on cfg file naming in my earlier blogs.
Another thing worth considering is using the same directory structure here as in the delivered build. In MSCONFIG.cfg, _USTN_SITE is set to:
_USTN_SITE : $(_USTN_WORKSPACEROOT)standards/
This is derived from:
# Default to a completely local (non-network) installation.
MSDIR : ${_ROOTDIR}/
MSLOCAL : $(MSDIR)
_USTN_BENTLEYROOT : ${parentdevdir {parentdevdir {MSDIR}}}
_USTN_WORKSPACEROOT : ${_USTN_BENTLEYROOT}Workspace/
_USTN_HOMEROOT : ${_USTN_BENTLEYROOT}Home/
_USTN_DOCUMENTATIONROOT : ${_USTN_BENTLEYROOT}Documentation/
If you follow the directory path you’ll see how we have directories for cells, dgnlib etc. This sets an excellent base for your own build and also helps when it comes to debugging errors later.
Well, I hope this gives you some idea where to at least start with the cfg mine field. Don’t rush yourself with this. Little mistakes can build up and make it very hard to debug later. Check things as you go and make sure you have issues resolved as you go.
Good luck.