.cmdlmodel as well as the material definitions can be edited as shown above also after the model has been placed into a map or world file. The changes will take effect when the program is next restarted.
_editor.cmatfile as explained at Model Files Explained. In fact, we should never have hand-edited the
_editor.cmatfile, but do all edits in
_editorpart) instead, but we thought it's too difficult to explain that in the video.
There are two main methods for scaling a model:
The Joint Inspector can transform individual joints of the model, but only for the bind pose. It is mostly useful for static, non-animated models, but even then only if there is a special requirement that the Transform dialog cannot handle.
The Transform dialog is much easier to use, as it transforms the entire model (the whole skeleton): the transformation is applied to all currently selected animation sequences. If no animation sequence is selected at all, the “bind pose” is transformed.
In some cases, importing animations is very easy: Use the “+” button in the Animations pane as demonstrated in the above video.
However, this works only if the animations are stored in separate files that are compatible with the already loaded mesh. This is specifically the case with
md5anims for their related
We will extend this functionality in the future. Until then and for all other cases, see the next How-To about generically sharing and re-using elements.
Creating variants of a model by sharing or re-using elements of another model is a straightforward idea, but generally not easy to implement: For example, it's easy to share meshes and animations when the skeleton is an exact match, but much harder to do otherwise.
The solution is to manually edit the
cmdl model file, which is a Lua script as documented at Model Files Explained.
For example, copying and pasting the definition of an animation from one player model into another (that has a compatible, matching skeleton), tends to work very well.
It is also possible to use Lua's
dofile() statement to include models into each other, which we intent to augment in the future to load globals from one model file into a table of another, as to keep the global namespace of the current model clean.
All variants of such file inclusion however suffer the problem that it creates a dependency of one file on another. This may be exactly what you want, or maybe not – where in the latter case falling back to copy and paste is probably the better solution.