Model switching is a concept I have used to centralize the model sheets for different types of the same character. Traditionally, a character in OpenBOR is represented as a player, enemy, or npc, each labled by the type parameter int heir model text files. Should an author desire to create a character that is both playable and an enemy ( a common example would be making enemy bosses playable as a bonus feature), the usual method is to copy the model text file, change type, and fix some header settings. The same holds true for adding an npc type.

The problem arises when models begin to get highly complex, and/or changes are made after the initial design. Every change must be copied over by hand, else-wise they won’t match. In some cases this may not be so noticeable, but if a major animation change or other redesign is made to one model and not the other, their differences will be glaringly obvious. Naturally maintaining two identical models can quickly get tedious and confusing, especially when scripts or other advanced features are involved.

The model switching concept is an attempt to somewhat alleviate the problem of maintaining multiple texts. Through the script command changeentityproperty({ent}, “model”, {model}, {ani flag}) OpenBOR allows any entity to switch over to another model text. This switch behaves in many ways like the built in weapon system:

1. Animations from the new model replace those from the old.
2. The model retains its original name and path, along with most header commands. A few are overridden or not retained, see below.

The initial model switching itself is an easy process; organization and ensuring the right model is always in use during game play events can get more involved, especially when combining with the default weapon system. Step by step, this is the process:

1. Each character contains a single centralized model text of enemy type. This file contains every animation and header setting that is possible to share. The name header setting and file name must be identical to the folder it resides in (data/chars/example/example.txt).
2. Each of the other types (player, npc) the character may represent are given their own model sheets, as in the traditional method. These models however, only contain the bare minimum of settings unique to a type or required by circumstance and serve as a staging model. They are labeled by a name plus type identifier. These are the models spawned into play by the engine.
   • examplep: Player type.
   • examplen: Npc type.
3. When a staging model is spawned into play its onspawnscript immediately runs a model switch to the main model.
4. No other steps are needed unless weapons are in use.
5. If weapons are in use, the weaponframe command is replaced by a scripted alternate.
6. Weapon removal in response to being killed or knocked down works normally. However, as this effectively sets the model back to it’s staging version, the switch from staging to main must be performed immediately afterward.

I have found this method to be effective and surprisingly stable. The slight complication with weapon use and issues below is more then made up with having with a few exceptions only one large set of animations to work with.  It does however require paying careful attention to property behavior, as most properties are retained from the original model. The following is a list of these as I catalog them find them and a work around for any issues. Unless noted otherwise, these properties must be included in all model sheets.

• atchain
• bflash
• cancel
  • Requires inclusion of the full animation, including cancel command, in original model.
• com
• combostyle
• dust
• gfxshadow (until new model moves on Z axis).
• jumpmove
• weaponframe
  • When reverting to primary model (no weapon), scripts from weapon are retained in place of primary model.
  • There is no true workaround. Solution is to replace weaponframe with scripted substitute.