Bringing Life to the Mojave

7/21/2019 Bringing Life to the Mojave

http://slidepdf.com/reader/full/bringing-life-to-the-mojave 1/44

Bringing Life to the Mojave

Tutorial on Custom Creature Creation

By Mindboggles

Introduction.

I don't pretend to be an expert on the subject of custom creature creation and / or animation for that matter. The

information I provide in this tutorial and the theories / conclusions I have come to about many aspects of the

creation process I have arrived at through trial and error, applying theories to situations and then testing them in

practice to see if they hold water. There may be parts of this tutorial that are incorrect, but by following it you will be

able to create completely new creatures for Fallout New Vegas that are functional and stable. Hopefully you will also

gather some insight about Gamebryo animations and a better understanding of how the game goes about its

business.

1. Before we begin

1.1 Your level of experience.

Before attempting to embark upon creating your own custom creatures it is advisable that you have a good

understanding of the GECK. You should have a moderate to high level of skill with Nifskope, you should be

comfortable with creating /exporting static and Havokable Nifs. It is even better if you are capable of copy and

pasting collisions from one Nif to another and re-assigning data within blocks. You should at least have a moderate

skill with your 3D program. It is also advisable that you acquire a good supply of whatever your poison is, booze,chocolate, corn chips, etc.

1.2 Tools.

The GECK: I mod for Fallout New Vegas primarily but there's no reason why this guide won't work for Fallout 3.

Nifskope

3DS Max 2012: At the time of writing this was the last version to work well with Nifscripts. Older versions will be

more than likely to work as well. Blender user's are on their own to a degree, although much of what works for 3DS

can be interpreted for and applied to Blender.

Gimp: If you are creating a creature from scratch, then you will have you own custom UV map and therefore require

your own texture. I use GIMP but there are other paint programs like Photoshop, etc. I'm only mentioning the paint

programs since you will require them in the overall creation process.

2. Your Mesh

2.1 Create your mesh.

This can be something completely of your own creation. I will not be going into detail about general 3D design, UV

mapping, etc. How you create your mesh is entirely up to you but there are some factors you should be aware of.

For this tutorial I will be using various meshes that will hopefully demonstrate things the best.



The picture below shows the Flying Mine Bot, I've coloured the separate meshes differently to highlight the fact that

they are separate. Robots generally have sliding and rotating joints so it's often easier for vertex selection when it

comes to skinning the mesh. Also note the overall scene axis and the direction of the front face of the robot - this

mesh is actually positioned incorrectly because the front should be pointing towards the main y-axis.

The Select From Scene dialogue window shows the various objects in the scene, the helper points were added to

help with locating the skeleton bones later.

Once you have your mesh it is a very good idea to make sure you have positioned it at 0,0,0 and that it is rotated so

that it's face points towards the y-axis (opposite to what is shown here). When you are happy with it, make sure you

have set all your mesh pivots to the origin (0,0,0) and rotated to match the world / scene, then use Xform to lock

that in for each separate mesh.

Before you start creating your skeleton, you should export your creature as a static mesh. Don't worry about

collision you won't need it. It is important to get your mesh into the game as a static first, to make sure you have the

right scale in 3DS. If you create your skeleton and do all the rigging work, only to find out later that its scale is wrong

ingame, you can pretty much kiss all that work goodbye. So......EXPORT A STATIC SCALE TEST NIF FIRST!!!!

Your static nif can also serve another useful purpose. Provided you have exported your UV maps, use the static nif to

help create your texture. You can have Nifskope and your paint program running at the same time, export your ddstextures and Nifskope will auto-render the nif.

The picture below shows your static mesh in Nifskope. Note the shader flag doesn't have "skinned" set as this is not

a skinned mesh. When you export your actual skinned mesh later, the "skinned" flag must be set.



Quick reminder regarding the Nifscripts export settings: if you have vertex colours on your mesh, make sure you

check that option on export.



And finally just a picture demonstrating what your UV map should look like. Try to maximise the available space for

the texture as shown below:



3. Skeleton

3.1 The Base Bones.

When you are happy with your mesh scale, your textures, and have applied Xform to correctly set the scale and pivot

position of each of your meshes, you are ready to create your skeleton. Start by creating 2 separate bones in the

scene and make sure they each have their rotations set to zero, otherwise the game will rotate them on its own and

point your creature in the wrong direction.

Note the rotation values x = 0, y = 0, z = 0. Make sure your rotation values are set to zero too! So that you won't run

the risk of losing track later of the various parts of your own skeleton set, with 50+ bones in the mix set each of them

a different colour. Rename one of your bones "Bip01" set its colour to red and increase the size of its front fin.

Name the other bone "Bip01 NonAccum" (name your bones exactly, it's IMPORTANT). Set its colour to green and

make it longer than the other as these bones will end up sitting on top of each other.

Now move each bone in turn and position them both at 0,0,0. Once you have done that, link your Bip01 NonAccum

bone to your Bip01 bone.



You should have both bones sitting on each other, both at the zero position with no rotation, and as you can see inthe schematic view, the Bip01 NonAccum bone is connected to the Bip01 bone. It should also become apparent why

the bones are made to look so different (note the front of the robot has now been set to face the right direction).

3.2 The Rest of the Skeleton.

From here on, it doesn't really matter in which rotational direction the of the rest of the bones in the skeleton are.

However, for your own sanity and ease of animation later on, it is a good idea to go about it in a thoughtful manner.

If your creature is going to fire a weapon from some location on its body, it will need to have a bone defined for it.

ProjectileNode is default for embedded weapons but you can use other names as long as you keep a track of them

later. So, for example, you could have ProjectileNode_Left, ProjectileNode_Right, etc. Be aware you might hit

trouble with the orientation of the bone if the creature's embedded weapon has a muzzle flash effect as the flash is

dependent on the rotation of this bone. The projectile which is spawned from this point when the weapon fires will

always go in the direction your creature is facing, but not the muzzle flash effect.



This skeleton was built from the Bip01 Hip upwards and only after it was completed was it then linked to the Bip01

NonAccum bone to finish it off. Note the positions of where various bones start. Many have been chosen to

correspond with pivots on the robot itself. For example, each rotor fan gets a bone on its own, which once rigged,

will spin independently with each bone. Make note of Bip01 Head, the game reads certain Bones / NiNodes and

Bip01 Head is used by the game to determine where to point the camera when talking to the creature. Without it

you will have issues.

4. Rigging / Skinning

4.1 Skin Modifier.

When you are happy with your mesh and skeleton, it's time to rig your mesh to the skeleton. For this, the only

modifier you should be looking at is Skin.



In the picture above, you will notice that the mesh contains many separate bits. This allows easy selection of vertices

for weighting to their respective bones. Add only the bones you want to rig it to. In the example given above, the

vertices can be weighted to each bone by selecting them and assigning an absolute value of 1.0 in the weight

properties. There are many different ways to weight your mesh - it all depends on your preference and the situation,

like the example of K9 below, where just an envelope selection will suffices. If you get stuck rigging your mesh, there

are many Youtube tutorials on the subject.



Be aware when you have a mesh with varying weights across multiple bones you will need to include a RAGDOLL

CONSTRAINT in your skeleton.nif or you will end up with this happening when your critter is killed:



4.2 Meatcaps

Many of the robots / critters I have made I've cheated on the meat caps by building the damage mesh in as it only

becomes visible when the joint falls apart on death (they are the green meshes in both the K9 and T3M4 picture).

They are rigged the same as "normal" mesh and if you have to make your own from scratch (most likely) then it is a

good idea to create a donor mesh by copying the "normal" mesh after it is rigged (to preserve the same vertex

weightings). Rename the donor mesh to an appropriate meat cap name, then hack away at it (mesh or polygon at

the bottom of the stack) leaving only what you desire for the cap. There are tutorials around covering meatcaps forthe creation of armours and they serve as a guide on how to go about it.

4.3 Dismemberment

Things start to get a bit tricky when it comes to dismemberment partitions and they tie in with what you create for

them in the Body Part Data of the GECK. This would probably count as one of the trickiest minefields when creating

new creatures and the most opportunity you will have to notch up a record number of modder-induced ingame

CTDs (I am not kidding). I can't really provide a foolproof way to go about this process except to say, stick as close as

you can to a vanilla setup. There are obvious groupings to follow like Torso for the main body, Head for heads (of

course). But for other partition grouping it's not always clear what to do and you may find yourself having to

backtrack and redo your dismemberment partitions if things aren't working out for you.

You will notice you have a lot of choices when it comes to your partitions. Not only do you have things like Torso,

etc. but you have things like the following.

Looking at the following picture I'll try to help explain what I see as going on with them.



In the example above, the section of the left arm is set as Body | Left Arm. This means that when viewed in VATS, it

will be seen as part of the arm but when dismemberment occurs, it will remain with the body. The lower part of thearm is set simply as Left Arm, and that's the part which drops off. For the meatcaps (yes, plural since there's one for

the body one for the arm) you have Body Cap | Left Arm which will become visible on the body side when

dismembered and Section Cap | Left Arm for the bit that falls off.

Notice also you have multiples of the limbs etc. These are for creatures with multiple limbs. Ants, for example, would

require all the 3 left and all the 3 right partitions respectively.

4.4 Exporting

When you're ready to export, it is important to check a few things before hand. Firstly, check that all your vertices

have a full skin weight totalling 1.0 for the bones to which they are rigged to - a quick check is to rotate each bone

and see what moves with it. Make sure you don't collapse the modifier stack (EVER). If you have a multi-material on

a mesh that crosses partitions, the nifscripts will crash 3DS MAX. You can wipe out your material data if a multi-

material is causing export problems by going to Utilities -> More -> UVW Remove and tell it to remove Materials.

Don't worry, you can put a material back in Nifskope.

If you think your good to go, export your rigged mesh and then your skeleton immediately after the other. These are

the settings I use:



For the rigged mesh, make sure to remove extra bones. The inclusion of vertex colours is up to you depending on

whether you have made use of them or not. For the skeleton export, tick "Skeleton Only" - don't remove extra bones

or nothing will export, and don't flatten hierarchy.

If all goes well you should end up with a rigged mesh and a skeleton in your chosen folder.



Make sure your shader flags are set properly and have SF_Skinned set or your nif may be invisible or end up looking

like a mess. For each part of your rigged mesh, locate the BSDismembermerSkinInstance block as shown below:

In the above example I have selected the bodycaps mesh and opened up the 4 partitions in the block details. The

first thing to look at is the Body Part field just to make sure you have the partitions that you think you should have.

The other thing is the Part Flag. The information about PF_START_NET_BONESET and its functionality isn't all too

clear to me. If you're getting strange skin rigging behaviour in the GECK but not in Nifskope you might have to play

with this setting. Because these are meatcaps you don't want them visible in the GECK, so for meat cap partitions

make sure PF_EDITOR_VISIBLE is not set. For all the meshes that you want visible while the creature is alive, you

want to have them set as editor visible or nothing is going to show up in the GECK at all.

5. Skeleton.nif

5.1 After export.

When you open your exported skeleton in Nifskope, you should be greeted with something that looks like this:



I'm not sure if it's the same for all nifscripts or just my version for 3DS Max but I always have to do repairs to my

exported nifs, including the skeleton.nif. The NiNode Scene Root is wrong and must be converted to a BSFadeNode,

the BSX flag data value needs to be changed to 198, and you will need to alter the BSBound data to match the

overall size of your skinned mesh / collision shapes. If your creature is a flying creature, you will need to adjust the

Bip01 z-axis value accordingly. Your bounding volume also needs to reach all the way down to the ground or (even

though it's flying) it will get tripped up by stairs etc. You will also need to adjust the Bip01 z-axis in all your animation

files in Nifskope and your Bip01 NonAccum animation data also.

5.2 Collision.

All the collision required for various bones of your skeleton can be cut and pasted from vanilla skeletons. It may be

possible to setup your collision bodies in 3DS. However, considering the amount of work to ensure the nifscripts

helper tools are zeroed for each bone they are attached to and orientated correctly (bones use the x-axis as the

major axis) it's easier to just do it in Nifskope.

As shown below, you don't need to have collision on all the bones, only on the ones that matter:



The main body here consists of a spherical body. It has the appropriate collision shape and is attached to the Bip01

Hip Bone / NiNode. You will notice in the block details that the collision has the Target value of 10 (the header string

array index) and its value Bip01 Hip (the array text string) - this is important because there are two things required

before collision acts properly on its assigned Bone / NiNode and that is one of them, as the collision needs to be told

what NiNode to act upon. In this case the Bip01 Hip Bone. The other part is in the NiNode's own block details, as it

needs to be told that it 'owns' this particular collision.



So for the Bip01 Hip NiNode it has the field "Collision Object" set to 15 which is the collision block and the node now

owns it.

Returning to the picture for the collision where its block details have the target set to the Bip01 Hip, note that this

entry is what prevents the successful copying of the block. So before you can perform a block copy on it you must

first wipe that field out. Double click on the collision target value (so it is highlighted) and click delete, then click

outside the field and you should be left with "None" in its place. You are now free to copy and paste that collision

into other nifs. You should be familiar with having two instances of Nifskope running at once, one with the nif you're

working on and the other with your donor nif, allowing you to copy collision from one nif to another.

When you paste collision into another nif, it's not going to end up where you expect it and you will get something

like this:



As you might have guessed by now, you need to complete the entries for both the NiNode Bip01 Hip Collision

Object (value 15) and the Collision Target ( value 10) before it is setup properly.

5.3 Bone Geometry

As mentioned earlier, bones use the x-axis as their primary axis, so values in the x co-ordinate move you further

along the bone from its origin to its end. The best way to picture that is with a collision shape attached to it.



For this capsule shape, it has one point set at x = 1.9 and the other at 0.0 which places the capsule at the start, and

roughly at the end of the bone. Varying the Y and Z value will cause the ends to move off the axis of the bone

sideways. You should note the small axis set displayed in the centre of this capsule shape. This represents the centre

of gravity of the collision object (high school physics, game gravity and ragdolls).

In the picture below, the rigid body that owns the capsule shape has in its block details the field "Center", this is the

centre of gravity for this collision body and with the x value at 0.9 places it almost in the middle of the capsule. Just

below the "Center" is "Mass", this is a representation of this bodies mass (weight divided by gravity). If you have

dismembered collision bodies ingame whose values for mass are set too low, you will find you can pick up one part

of the dismembered body and drag other bits (supposedly now disconnected) by moving it, which is not acceptable.

If this happens, increase the values for the mass.

The collision filter or "Col Filter" and "Col Filter Copy" both have to be set for every rigid body in the skeleton. I'm

unsure about the system at work here. On one hand if you follow

(http://niftools.sourceforge.net/wiki/Oblivion/Oblivion_Bhk_Constraints ) you should be incrementing the Col Filter

upwards from 0 for each new collision body, however you can get some undesirable ragdoll behaviour from a

dismemberment partition / limb if they aren't set the same (body part dances around with its own energy). Another

one of those areas that you may have to play with before you get it right.



5.4 Constraints

Not so horrible after you get used to playing with them but at the start they can be very daunting. I have only been

playing around with ragdoll constraints since I've been able to achieve all that I've wanted to with them, but what I

describe here is also relevant to the other types.



You can block copy and paste these but it's a good idea to treat them the same as collision and clear their Entities

fields first (see above) otherwise they might paste into your skeleton nif pointing to weird places. In the example

above, the first entity is pointing at the ragdoll's own rigid body (the block that owns it) and the 2nd is pointing to

the rigid body of the bone / NiNode before it in the skeleton hierarchy. I should mention that constraints can only

work between bones that have a collision bodies, and they don't have to point to the bone directly preceding them

either. They can be tied to any collision body earlier on in the skeleton. Similar to collision blocks, the rigid body

needs to be told that owns that particular ragdoll as can be seen below:



You will see above for the rigid body block details, Num Constraints (the number of constraints acting on this body) is

1 in this case, an array Constraints (an array of 1) with the ragdoll constraint as its entry (36). If you have a rigid body

that has zero constraints you can change that value and then update the Constraint array which will enable entriesto be added to it.

Getting back to the previous picture, I want to talk about the properties of the ragdoll itself (since it can be scary

[censored]), but the more you get to know the way geometry is orientated for bones the easier it gets. The first

batch of entries refer to twist A, Plane A, etc. where A is the bone that owns the ragdoll constraint, as you can see

the ragdoll is shown at the start of the bone and you can see that reflected with its Pivot A values 0,0,0. If you

increased the x value, it would start creeping up the bone towards it's end while y and z will move it if off the bone

axis. For 99% of what you're after you want it set to zero (most vanilla ones are). The Niftools team have provided a

very good explanation of what the other fields are on their Source Forge site

(http://niftools.sourceforge.net/wiki/Oblivion/Oblivion_Bhk_Constraints ) so I won't be going into any detail here(they do a much better job than I would), but I will simply say that because your first part of the ragdoll (should be)

orientated with its owning bone, you can expect to see only 1's (90 degrees / perpendicular) and 0's for the A entries

as the geometry is perpendicular or square on to the bones own orientation (its locally orientated).



The B data fields are a different story and those values are determined by a complex interaction of 3D geometry.

Luckily for us, Nifskope has a function for doing this horrible bit for us.

You can either right click on the Ragdoll block or right click on it in the render window and select A->B and it will do

all the hard work for you.

6. G.E.C.K. Part 1

6.1 Data Folder

Set up a data folder and place both your skinned mesh and your skeleton inside it. It's a good idea to follow the

vanilla folder structure. You can create your own custom folder within the meshes folder but remember that your

animation files will also need to be placed here. The game will look inside the custom folder, it will assume that

anything found in it is an asset for the creature.



6.2 Importing your Creature into the GECK.

If you have your rigged mesh and your skeleton nif both in the one folder, you are ready to import it into the GECK.

The best way to do this is to duplicate an existing creature and set about altering the form to suit your needs.

First thing to do is to find Skeleton and direct it to your skeleton nif. Doing this will alter the entire list so it only

includes the meshes in the folder where the skeleton.nif resides. The GECK might squeal about the changes as it will

also dump the former creature's animation file list from the animation tab. You might notice that the static test

mesh is also included here simply because that file was included in the skeletons folder. Only use meshes setup for



the skeleton and nothing else as selecting the static mesh may just crash the GECK. You can include extra meshes

rigged for your skeleton here and have then as optional additions for your creature, a hat, jet flames, etc. There is

also Tilt Front Back and Tilt Left Right. These are ticked for creatures that hug the ground so that the game can keep

their angle to match the angle of the terrain. This is not always needed and can sometimes be buggy, creating issues

for some skeleton setups that can cause the creature to spin on the spot. The behaviour of the Tilt function is tied

closely to the Bounding Box since the Bounding Box is used to calculate the creatures general movement in regards

to collision.

6.2.1 Stats Tab.

The main parts I want to draw attention to are Attack Reach, Turning Speed, Base Scale, and Speed Mult %. Attack

Damage determines the hand to hand damage that a creature inflicts when it hits in combat an Attack Reach

dictates the distance from the enemy that the attack happens, meaning the game's AI positions your creature at this

distance for the attack. You could have a small creature with short arms which would require the attack distance to

be very close or a large creature with long arms that would require a greater distance. All this ties in with the hand to

hand attack animations.

Turning speed determines how fast the creature turns but your turning animations have to be in sync with the

settings here or the game will ignore your animation files and just turn the creature at the rate set. Make your

turning animations as fast as possible without compromising the flow of the animation. This will give you more

freedom to vary this value.

Base Scale is basically the scaled size of the creature. If you got your static test mesh size right in the first place, thisshould be 1.0 and you can change it for creature variations. Be aware that the vanilla creature you copied from

might have this value set to something other than 1.0. The base scale will also work in conjunction with the distances

you set in your movement animation files.



Speed Mult % again this directly effects the speed of the creature in conjunction with its size (Base Scale) and what

you have in your animation files, it's best if you can have that set as close to 100% as you can and have your

animation files set properly in the first place.

6.2.2. Body Part Data.

What a great way to crash your game! A lot of things come together here so it's no wonder problems here can result

in CTD's.

Body part data dictates how dismemberment happens and the interaction in VATS. It brings together the bones that

get pulled apart upon dismemberment, the skin partitions in the rigged mesh and the collision bodies attached tothe bones in your skeleton.

The GECK Wiki has only limited info about Body Part Data and I'll discuss the parts that are most important for your

creature. You need to select your skeleton.nif again for the Skeleton Model and then create your body parts for all of



the part you would like to have individually targetable in VATS. If you have made more dismemberment partitions in

your rigged mesh than you want targetable, don't worry. You only need to include the ones the player can select in

VATS.

The Part Name will be the name displayed in VATS. You can have multiple Part Types use the same name and VATS

will highlight the whole lot as a target under that name.

The Part Type corresponds directly to the dismemberment partition you set for your creature when you rigged your

mesh. From what I can gather, each partition needs to have a collision body associated with it. So if it is the head

then the head must have a collision body attached somewhere on the skeleton after the Part Node (bone).

The Part Node is the Node / Bone that this partition attaches to the rest of the skeleton. Here we have Bip01 Head

and the Bip01 Head can come off from the main skeleton, most likely from the Bip01 Neck.

The VATS Target I set as the bone for this partition which has a collision body on it. In this case, the collision body is

attached to the Bip01 Head bone so that is what I set as the VATS Target.

Actor Value is the condition that gets trashed when the limb / partition gets too much damage ingame so when the

head gets damaged too much, the creature's Perception is ruined. Similarly, for an arm it might ruin the creature'sLeft / Right Attack Condition and they might not be able to attack after that. It appears that not having an actor value

assigned to the partition will crash the game when you enter VATS.

6.3 Placing you creature in game.

At this stage you can place your creature in game and it will register as a creature in your HUD but it is not actually

living yet. Before your creature comes alive (before the AI will kick in and grab a hold of it) you need to have at least

an mtidle.kf file. If you have a problem with the skeleton collision and body part data partitions, the cell that your

creature is in will not even finish loading in game before it CTDs. If your body part data has an issue the, game might

load the cell but if you try to target it in VATS the game will CTD. As in real life, something needs to be alive before it

can be killed and the same applies to the game also: if your skeleton collision and your body part data is fine but you

don't have an mtidle.kf, the game does not see your creature as alive and if you kill it, the game will CTD. Guess it

doesn't make sense in the game world either.

6.2.3 Ragdoll.

I can't offer very much information about the Ragdoll entries in the GECK since the FONV GECK crashes regularly

when trying to edit entries (or even access vanilla ones). The best I can summarize the ragdoll data is that it informs

the game which bones to treat as a group and move as one and which ones are free to move around and have

physics apply to when an actor is in the ragdoll state. The creatures will work in the game without any ragdoll set in

the GECK.

7. Animation.

7.1 General Animation.

The animations are grouped in sets by their filename. If you open up some of the folders containing creature

animations you will come across filenames with pre-fixes like mt, h2h, 1hp, 2hr,etc. They are labelled this way to

represent the kind on animation they contain. I'll run through some for starters but it will become apparent pretty

quickly what they stand for.

mtidle.kf, mtforward.kf, mtbackward.kf, etc. the mt basically stands for 'empty' which are animations where the

creature hasn't got anything, is not armed, is not in combat, it's just kicking around. Most of the creature's

movement animations will be here.



h2hequip.kf, h2hunequip.kf, h2haim.kf, h2hattack.kf, etc. the h2h stands for hand to hand and all the animations

with these prefixes to their names are associated with the creature using unarmed combat on a foe.

1hp - One hand pistol.

2hr - Two hand rifle.

etc.

If you have looked at creatures and their animations under the animations tab in the GECK, you would have seen

something like this:

The Robobrainin the image above is performing the 1hpattackright.kf animation sequence. Next to the filename is

the AnimGroup for this animation and the value AttackRight is read directly from the file. The Group Frame

Properties also hold information which is read directly from the file's text keys. Start means the start of the

animation sequence, Hit means the opponent has been hit (for impact data, sound effects etc.), Eject means eject

(spawn) the empty ammo casing (if it has one) from the weapons ShellCasingNode (specific name), a: is attack I

suspect this is used by the AI to determine distances for calculating where the creature will end up when the attack

happens, i.e. it may lunge forward and the game needs to know how far back (it reads the Bip01 animation data

from the file) it can launch its attack from. You will notice they have entries like 6(0.20) in front of them, this is frame

6 and the time 0.2 seconds that the event happens since the animations are 30 frames per second so 6 X 1/30 = 0.2.

If we open up this file in Nifskope you will see these entries:



Firstly, up at the top you will see that the text name for the controller sequence is AttackRight which appears as the

AnimGroup in the GECK. I have expanded the controller sequence and even though it's not shown, I have selected

the text key extra data and you can see the text key entries it holds in the block details. As you would expect, you

can see the Group Frame Properties from the GECK. Note, however, the Eject text key is missing. It can be included

in the text keys when you make the animation but it appears that if it is missing, the game will include one at the

same time as the Hit entry. Lastly, you have "end" which simply says that this is the end of the sequence.



The NiControllerSequence holds all the info of the controlled blocks. Each controlled block is given a text name

which you will see in the value field of the controller block but it's entry point is actually within the block under the

Node Name. This is the NiNode / Bone of your creature's skeleton that will be controlled by this block when this

animation plays. The controlled block also points to a NiTransformInterpolator which is the block which holds the

actual animation data for the NiNode / Bone of your skeleton. So in the controlled block I have open here, it is the

Bip01 Tail which is defined by the Node Name Bip01 Tail. Change that Node Name and the controlled block's name

will change. The controlled block has the Interpolator set as (9) which is the NiTransformInterpolator shown in the

Block list at the top and that is where the animation data for the Bip01 Tail is kept.

When you export your own kf files, you should expect to see something like this. If you don't, you've made a mistake

with your export from 3DS. I should also mention that my version of Nifscripts for 3DS does not put an entry into the

controlled blocks for the Controller Type (it is blank). If you do not fill this field with NiTransformController for every

Controller Type of every controlled block, you will crash the GECK. If your new animation file crashes the GECK 99%



of the time this is the reason, make sure that it's set for all of them! You can change this to other Controller Types

when you want your animation to make use of animated textures or to control visibility of materials but that's more

advanced.

You will notice also in this controlled block it has a Priority set at 20. This value is important because it has to do with

the amount of control a particular animation has on the skeleton's bone. This animation file is the mtidle.kf and it is

the base animation for the creature. It will have an effect when your creature is moving and even while your

creature is running combat animations. This means that the priorities set for the Bip01 Tail bone will have an effecton other animations. This may not be so important for a tail wagging, but for the Bip01 bone it is very important and

should be set very low like 1 because when you create your motion animations, it's the Bip01 that has the distances

moved in that bone's animation data and the priorities have a proportional effect on those animations. For example,

if your mtidle.kf has the priority set in the controlled block as 20 and your mtforward.kf has the same priority of 20

then the game will average the two. Your idle should have the distance travelled in the Bip01 data set at 0 so

whatever distance your forward animation has set for the Bip01, it will be halved since it's 20 / 20. If your idle had a

priority of 1 then the forward animation distance will hardly be affected since it's now 1 / 20.

Also in the block details for the controller sequence you will see it has the entry Cycle Type set as CYCLE_LOOP. This

tells the game that this animation is to loop over and over again so that if you creature was just hanging around, youmight expect the game to keep looping this animation over and over again until the AI decides it's time for your

creature to do something else. There is another type of animation cycle type which is CYCLE_CLAMP which is used

for things that you want the game to keep fixed, e.g., when your creature equips its weapon, you want it to stay

equipped so both the Equip and Unequip animations have to be set as clamped cycles.

7.2 Creating your Animations.

Time to head back into 3DS MAX and load up the file you exported from. Once you have done this, save it under a

different name with something like "Base Animation" included the name. You will also need to do a few minor

alterations to your skeleton and add a text key track.



When you have saved under a new filename, you will need to delete the Bip01 NonAccum bone from your skeleton

and then link the bone that used to connect to it to the Bip01 bone instead. So in this case, the Bip01 Hip now joins

the Bip01 bone (goodbye Bip01 NonAccum bone). Don't worry, it will make a comeback when you export your

animations (make sure to re-save the file).

Now open up your Dope Sheet and select the Bip01 bone and then add a text key track to it. This track tells the

Nifscripts about the various properties of your animation file while also setting the text keys for the kf file. You will

need to add text keys to the track and enter in their fields. In the text box open here we have "start", tells the script

this is the start of the animation sequence, "-name Idle", the name of this animation sequence (the GECK

AnimGroup). Even though you won't be working on this file it serves as a good safety net, and I've set it up as an

mtidle sequence since the idle should be the first animation file you make for your creature.

7.2.1 mtidle.kf

This is the most important animation file your creature can have, the presence of this file will make your creature

come alive. Because of its importance, I tend to key all the bones but because the mtidle has an overall effect on all

the animations, it's best to set the priorities very low, to something like 5. It's up to you how long you want your idle

sequence and what pose you want. I tend to use 300 frames and try for as natural pose as I can. 300 frames gives

plenty of room to create animations that are smooth and casual looking. You want the initial pose of your idle to

match the final pose otherwise if / when the idle loops you will get a jerky transition from one sequence to another.

On top of that, you want to keep this pose as the basis of other animations so that when the AI switches to a

different animation sequence you won't get a jerky transition.



When creating keys, the Bip01 should be keyed with position key data only while all the other bones should be

keyed for rotational data only. If you have included any IK solvers in the scene, they will likewise need to be keyed

with just the IK parameters.

An unnatural pose.



A more natural pose.

When you are satisfied with your idle animation you can export it as mtidle.kf using the following settings:



Make sure when you export that you have an appropriate value for your animation priority (in this case 5 for the

idle) , tick the "Add Accum Nodes" so it will put an animation track in for the Bip01 NonAccum bone, and finally, set

the export to "Single KF w/o NIF".

When you export you should end up with something that looks like this:

In the text keys, you will find instead of "start" you have "start -name Idle -loop -at y". Edit this back to simply" start".

You will need to do other alterations to your NiControllerSequence. If it is an animation sequence involving

movement, you might also need to edit your Bip01 position keys.



First thing you should do for the controlled blocks is to set the Bip01 priority to 1 (instead of 5 here) for any

animation files that aren't intended to move the creature forwards or backwards as it will nerf those motionanimations if you don't. You will notice that the "Controller Type text field is blank - you must, MUST set them for

every block with NiTransformController or your animation file will cause the GECK and GAME to CTD. In this example

the Dark Star Alien has an IK solver and since the solver is keyed in 3DS, the Nifscripts will export it as a controlled

block. You don't want this (it's already done its magic on the associated bones when you exported). Now in this

example, it's easy to fix you simply change the "Num Controlled Blocks" from 24 to 23. Right click on the "Controlled

Blocks" and select update array and it will drop the last controlled block and the IK Chain001 in the process. You will

also need to clean up in the block list because you now have a NiTransformInterpolator on the loose and you will

need to delete it. If your IK solver block is in the middle of the array, then you will have to replace it's values with one

from the last controlled block in the array, then re-number and update the array. The only NiTransformInterpolator

displaced in the block list by this should be the one that belonged to the IK and you can just delete it.

For flying creatures you will need to make sure that your Bip01 and Bip01 Nonaccum animation data matches up

with your skeleton.



For the Bip01 NiTransformationInterpolator, here you can see its z-value is set to 80 which should be the same for

your skeleton.

For the Bip01 NonAccum animation data you will see the z-axis values similar and the variation from 80 gives it a

gentle bobbing motion.

7.2.2 The "mt" set of motion animation files.

Not all that dissimilar to your mtidle except you will need to alter the sequence name for each one and alter the

length of the sequence. Shorter sequences will give the AI more freedom to switch quickly. You can look through the

various vanilla animation files to see the various sequences available for you to use. The following ones are ones that

you should have:

mtforward.kf Forward

mtbackward.kf Backward



mtturnright.kf TurnRight

mtturnleft.kf TurnLeft Your creature can turn without these but turning without leg movement

would look strange.

If your creature doesn't have a basic set of movement animation files, its AI will fail when it comes to hand to hand

combat (most likely all melee attacks). There are many other movement animation sequences you can create, and

the more you can create the better more flexible your creature will be when moving around. When your keying for

the forward and backward movements, leave the Bip01 keyed at 0 for the start and move it to wherever you want

your creature at the end (y-axis only). You might need more keys for your Bip01 positions depending on whether

your creature walks with a stop / start motion but if you do try to keep your animation down to just one step for

each leg (shortest animation sequence possible). If you do have a walking sequence, then you need to deviate from

the normal pose position in your mtidle and create an animation sequence that gives a fluid transition when looping

with itself. The game does a certain amount of blending itself. On the whole, it's much better to have a single jerky

transition from an idle state to a walking state than it is to have one every time the creature takes a new step.

If you include a set of sidestep animations (mtleft.kf and mtright.kf) you will need to change your text key in the

Dope sheet at the start to read "start -name Left -at x" instead of the normal "start -name TurnLeft -at y" so that the

scripts export the sideways position to the Bip01 animation instead of the y-axis it normally writes. This is a case

where you can move the Bip01 bone in the x-axis and not the y-axis. When the key text has "-at y" the nifscripts will

write only the y-axis position into the Bip01 animation data, any x or z-axis positions get written into the Bip01

NonAccum animation data.

Another thing to be aware of when making animations other than the mtidle is to include only the bones you require

to be animated in the sequence, e.g., no need to include the Bip01 Head if the creature's head isn't going to be any

different from the idle animation.

When you export your movement animations, use something close to 20 - 25 for your priorities. Other than this,

your settings should remain the same as the mtidle.



The animation sequence above is a fast forward animation (running animation). In the animation data, you will find

the translation keys (distance moved) and is zero at time zero and 400 1.5 seconds later. This animation sequence is

looping and if it is to be fluid without any stop-start (into the next loop) then the Interpolation should be set toLINEAR_KEY. Conversely, If the motion your creature is to have is stop-start in nature then you would want it to be

the default of QUADRATIC_KEY.

7.2.3 Combat Animation.

To help describe the animations for combat, I'll concentrate on the 1hp but pretty much all that is presented here

can be applied to the other ranged weapons.

1hpequip.kf Equip

This animation file equips the weapon, it is cycle clamp and can be either a very simple sequence or complicateddepending on what you want. For a very simple sequence, you might have a creature with an embedded weapon

and not need any visual sign that the weapon is equipped, in which case you can leave many bones out and maybe

only include the Bip01 and Bip01 (whatever bone you want) in the animation along with the text keys. So your text

key track should have something like the following:- start , attach, Prn:Bip01 (whatever bone you want), and end.

The reason you can use whatever bone you want is because it is an embedded weapon and the mesh is built into the

creature's mesh so you're not actually attaching another model and the "weapon equipping" is in name only. Usually

for embedded weapons, I use the bone just before it's associated ProjectileNode so it's easy to keep track of

(especially if you have different embedded weapons). A complicated equip animation might have the creature reach

for a holstered weapon, in which case you must have a Bip01 R Hand bone and call Prn:Bip01 R Hand to attach the

weapon to, but it doesn't actually attach it that bone, it attaches it to the Weapon bone so you must have a bone

called Weapon in your skeleton also (positioned where the weapon would go in the hand). The game does this so

that you have a means to separate the weapon from the hand if required for reloading.



1hpunequip.kf Unequip

Similar to 1hpequip.kf except that you're pretty much calling for the reverse animation here. So for the simple case

where it's basically just a change in text keys you would have something like start, detach, Prn:Bip01 (whatever bone

you want), and end. It might seem silly to detach the weapon back to the same bone but since it's only in name only,

it doesn't matter but for the complicated cases, it's important! Playable weapons (the ones that can be holstered)

have an actual presence in the game (not just a visual presence) and they must be kept somewhere, so when a

weapon is holstered it gets placed attached to your holster bone.

1hpholster.kf Holster

This is a cycle clamp animation and it is only needed when your creature is making use of playable weapons, this

animation plays whenever your creature decides that it wants to switch weapons , e.g., when you give a follower a

better gun and it instantly appears on their back or hip. You would expect to see text keys similar to, start, Prn:Bip01

(your holster bone). If your creature is going to make use of playable weapons and you don't included the proper

equip, unequip, and holster animations you run the real risk of causing CTD when accessing the creature's inventory

because it might want to bring it into the world for your creature to use but it won't know where.

1hpaim.kf Aim

1hpaimup.kf AimUp

1hpaimdown AimDown

Many creatures only make use of the aim animation, no up or down and the difference is simply the pose that the

creature makes to make the aiming animations looks more realistic. They are cycle loop sequences and if you make

use of aiming up and down, make sure you especially key all the bones that will vary from normal, up, and down,

since they seem to want to interfere with each other otherwise. Not much to say about the text keys except they

have a start and an end.

1hpattack.kf Usually AttackLeft or AttackRight (there are heaps to choose from, HEAPS)

1hpattackup.kf Usually AttackLeftUp or AttackRightUp (see above)

1hpattackdown.kf Same but with Down instead of Up

Your creature aims and then it attacks so the pose your creature is in when it's aiming should be repeated for

attacking. Again, this is a looping animation sequence but it has a few extra text keys - start, Hit, Eject, a:, end. Hit is

for the impact of the target, Eject is for the spawning of the empty shell casing (if it has one) and a: is the attack (I

think for the calculation of the final position after the attack ).

1hpreload.kf Reload

This is a cycle clamp sequence. In the simplest case, it's basically just making use of the text keys, "start" and "end".

For complicated sequences and playable weapons, it gets very complicated as you need to make animation files that

match those required by the weapon and there might be many called things like 1hpreloada.kf, 1hpreloadb.kf, etc. In

order to create them, you are going to have to get the gun into your 3DS scene and place it in the hands of the mesh

(where it will attach to the Weapon bone ingame) then do some tricky animation work and hacking in Nifskope to

get it right. It's pretty involved and not something that can be covered quickly.

1hpjam.kf Jam

Not needed for embedded weapons (you can select no jam after re-load in the GECK). Again, it is a cycle clamp and is

similar to the reload animation in regards to complexity in creation for playable weapons. Normally it will have a

suffix similar to the reload animations like 1hpjama.kf and have "JamA" sequence name.



This pretty much rounds out the combat ranged weapons except for loop attacks. Loop attacks are used in the

automatic weapons and allow for the rapid firing of the weapon. The animation names will have "loop" on the end

e.g. 1hpattackloop.kf, and have a sequence name "AttackLoop". The text keys get easier with just "start" and "end".

7.2.4 Hand to Hand / Melee

These are similar to the shooting animations except for one major difference: the attacks are cycle clamp, and the

only cycle loop animations you are likely to find are the aiming animations.

7.2.5 Other animations

Death.kf Death

This is a cycle clamp sequence and plays once when your creature dies. It's not necessary for your creature unless

you have added a few funky things to your creature like jet flames etc., and you need the animation to turn the

visibility off for the jet flame material. In order to do something funky like jet flames you should have a controller

block in you mtidle.kf that tells the jet flame material to be visible.

SpecailIdle_YourOwnNameHere SpecialIdle_ YourOwnNameHere

You can create your own special idles for your creature, if you like you can create Idle Markers in the GECK for them

to use, and include Anim Objects that will work for your animations.

talking.kf Talking

I could not get this to work for me at the time I was playing with talking animations so I gave the creature its own

special idle animation link via the creatures dialogue / quest.

7.2.6 Text keys

If you go browsing through the text keys for various vanilla animations, you might find yourself coming acrossvarious text keys and wonder what they are for. I've put together a list of the ones I've come across and my

interpretation of what they might be:

start Pretty obvious, the start of the animation sequence.

end Again obvious, the end of the sequence.

Hit The enemy has been hit, most likely when the visuals and impact happens.

Eject Spawn the empty casing coming off the weapon.

a: These can vary and you might find them as a:R, a:L, a:4, etc. which I think refers to the attack type.

Blend:# Where # is the number of frames to blend this animation sequence with the previous one.

BlendIn:# Unsure about where the blending happens.

BlendOut:# Again, unsure about where the blending happens.

Sound: [sound name] Play the sound that directly corresponds to one defined in the GECK.

Enum: [text] Basically, Foley sounds are to be played as defined in the GECK, usually for walking.

Prn: Bip01 [bone] Put the associated object at this bone.

Hold I haven't played with throwing animations but most likely display the thrown weapon in hand.



Release Again, throwing (most likely, remove the visual from the hand and spawn the projectile nif).

Attach Telling the game that it is attached, e.g., 1hp a pistol is attached.

Detach Opposite of Attach.

This is by no means close to the full list and the more you look the more you will find.

8. G.E.C.K. Part2

8.1 Weapons.

For embedded weapons, you will need to make sure that Embedded Weapon box is ticked and enter in the name of

the node that you defined in your skeleton. Select an Actor Value that correlates to the limb where the weapon can

be found ( the one you defined for it in the body part data). Make sure the weapon isn't playable.



With Art and Sound, if you have an embedded weapon make sure you don't have any Model info otherwise you

might see meshes on your creature which you don't want. You don't need to worry about the Reload Anim but yourAttack Anim needs to match up with what you defined in your attack animation. The Animation Type needs to be set

to matchup with whatever set you chose to use, i.e. 1hp needs OneHandPistol.

You will need to define your own Form List and include all the weapons that you creature is able to use and you will

also need to tell your creature to use this list.



Finally, you need to give your creature the actual weapons and relevant ammo in its inventory.

I have not covered the case here for playable weapons since it's not the weapons you will need to modify. Rather,

it's the animations that you will be needing to make to suit the weapons (lots of hard work).

Conclusion.

This is hardly a definitive coverage on the topic of custom creature creation but serves as a guide to help you in the

creation of new creatures. I have arrived at the information provided here from various means, time, patience, trial

and error, and correlating results with hypothesis. As such it isn't the final word on the subject. If you follow thistutorial and have a good understanding of Nifskope and 3DS Max you should be able to create your own custom

creatures using the information provided here.



Credits.

Special thanks to:

Nonoodles from Nexus for correcting my ghastly grammar.

LordZues40 from Nexus for overall support and help.

All members of the modding community who have contributed to the general knowledge of modding, especially

those who have helped me solve many of the questions I have had over the years.

Documents

Bringing Life to the Mojave