Animations in MTW - how, what, where, why and \"lots more\"

[Wellington]

Hi Guys,.

It would be great if everyone could collect their knowledge, re animations and graphics, in order to create an 'image modding guide' that can be downloadable from The Org.

That is the intended purpose of this thread.

Here's what I know/suspect regarding the animations in MTW. I don't think this type of info has been completely documented yet, although there are many bit's and pieces scattered throughout threads. A lot of this may be known or self evident but I've tried to cover as much as I can, for both established modders and newbies.

I've split my contributions to this thread into parts (in seperate posts) in order to make it more readable. How many parts? Don't know yet. Depends on what else I manage to figure out.

Please contribute what you know, add whatever I've overlooked, and correct any misconceptions/mistakes I may post.

[Wellington]

PART 1: Basics, Images and BIF's

There are over 120 individual units in the game. Each unit is built up from a combination of the following -

- a generic unit
- a generic mount (for cavalrymen)
- a specific weapon (optionally)
- a specific shield (optionally)


For example, the generic unit 'Peasant' is used for multiple specific units -

- Peasant
- Spearman
- Pikeman
- FeudalSergeants

.... and MANY others!

These specific units are different insomuch as they carry different weapons/shields, and (in the case of cavalry) may use different mounts.


The generic units are contained in their own folders within the folder 'Textures\Men'. The images for these are contained in 2 BIF's in each of the generic-unit folders.

The relationship between a specific-unit and the generic-unit (in terms of which generic-unit and, optionally, generic-mount to use for any specific-unit) is contained in the crusader_prod11.txt file.


Most graphics associated with the generic-units are contained in their own folders, within the folder 'Textures\Men' (flags and banners are not). These generic-units are represented by 2 BIF files, for the low res and high res images. Each of these 2 BIF's contain 12 frames.


The lowres BIF frames are all 256x256, the hires ones 512x512. Images in the high res BIFs are twice the size of the low res ones. This is important for weapons/shields resizing when a specific unit is being 'built' in the MTW engine.

These BIF files also contain images of all weapons and shields that may be used, in conjuction with the generic unit, in order to create a specific unit.

Both BIF graphics plates have the same name as the folder, with the high res BIF plate adding "_H" for differentiation. For example, the unit plates for the specific-unit Longbows are contained in the folder 'Textures\Men\Bowman', along with several related text files, and be named -

- Bowman.bif
- Bowman_H.bif

(Note: within the generic unit folders there is also a TGA file - ignore it - it is'nt used)

Any figure image, shield image or weapon image in a BIF is defined by its own 'image rectangle', the size of this image-rectangle being constant for all 12 frames.

[Wellington]

PART 2: Camera angles and frames

The number of images in any BIF, or frame, is always a multiple of 4. Why ? Well each action a figure is capable of performing (walk/run/die etc) is always represented by exactly 4 images on a frame.

Each figures actions can be represented on the MTW battlefield from any one of 8 angles, for each of the hires or lowres definitions. If you consider scanning a camera all around a figure (0 to 360 degrees) on the battlefield, the 4 images for each action represent 'camera angles' between 0 and 180 degrees (at 36, 72, 108 and 144 degrees - roughly speaking). There are no exact front or rear images. However, the MTW engine 'flips' these 4 images along their vertical axis to represent the 4 camera-angles on the other side (between 180 to 360 degrees), thus allowing 8 camera-angles from 4 images.

The different generic plates may well contain a different number of images - always in multiples of 4. However, the number of images in any generic unit plate will differ; you may see 24, 28, 32 or even more images per frame. Why ? For 2 reasons -

1) some specific units have more possible actions than others
2) these are generic-units, used for multiple specific units

Note that, in most case, a specific-unit does'nt use all the figure images defined (un the BIF's) for a generic-unit.

Each image in a frame (figure, weapon or shield) is a stand-alone image, and can be thought of as being encapsulated in its own invisible 'image rectangle'. These image-rectangles don't overlap and are important to consider when adding or changing unit images. Think of each frame in these BIF's as being comprised of multiple rectangles.

Each action associated with a figure has 4 'camera angle' images associated with it in the BIF's. Considering each image can be flipped on its horizontal axis, this provides a total of 8 camera angles, per action, in the animation).

Each of these 4 camera-angles has 12 frames that serve to represent the movement sequence for the action and camera-angle.

Now lets call any image (what you see if you pause the game and don't move the camera) a figure-image. Thus, any single figure-image is defined by 3 criteria -

1) the action the figure is performing (1 of 6/9 or more)
2) the camera-angle for that action (1 of 4)
3) the position of the figure in a movement-sequence (1 of 12), for the action and camera-angle

There is no other 'real' relationship between any of the images on any single frame, but there is a critical relationship between any image (defined by the image-rectangle) throughout all 12 frames.

The 12 frames in each BIF contain 1 of 12 'image cycles' for each figures image-rectangle (pertaining to a specific action/camera-angle. Each of these 12 image-cycles serve to define the next movement for the figure image, and if shown in frame order comprise a cyclic sequence of movements that (when looped continuously) ensure the smooth animation of any figures action. The image-rectangles for any figure image will be exactly the same across all 12 frames.

(TIP: Open one of the generic-unit BIF's and try using the "Timer(Go)" option in the Shogun 2.1 BIF editor - you'll see the relationship between all 12 frames very clearly)

Note that whilst there is no 'real' relationship (in animation terms) between any of the images on any one single frame, there is a critical relationship between any figure image (defined by the image-rectangle) throughout all 12 frames that comprise that figure images image-cycle.


Why are some of the images in the frames displayed horizontally instead of vertically ? Purely to get all required images within the confines of the high res and low res BIF frames, and within non-overlapping image-rectangles. The orientation of any image in the BIF's does'nt matter as the x/y coordinates of any image-rectangle will serve to inform the MTW engine whether or not re-orientation is required before use (think about it!).

[Wellington]

PART 3: Actions

A variety of actions may be associated with any specific-unit. Six actions are generally standard (walk/run/idle/die/fight/charge) and are associated with most units. Other actions may also be specified for specific types of units.

For example -

- Bowmen also have a 'shoot' action, giving 7 performable actions.
- Arbalesters also have 'standing_shoot' and 'kneeling_shoot', giving 8 performable actions
- Arquebusiers also have 'standing_shoot', 'kneeling_shoot', 'standing_reload' and 'kneeling_reload' actions (but no 'charge' action!), giving 9 performable actions.

(Note: two actions are generally the same 'idle' and 'stand')

The main criteria to consider in all of the animation process for a figure is action. The current action of a figure in a specific-unit will serve to determine -

- which image to use for the figure in the generic-unit BIF's
- which image to use for the mount (if it's a cavalry figure)
- which weapon to use (if a figure has a choice of weapons)
- where/how the weapon is positioned on the figure
- where/how the shield is positioned on the figure


There are multiple text files within MTW pertaining to a units action. Each specific-unit MUST have it's own set of actions (with all that this implies) defined.

The primary files pertaining to a units actions are contained within the folder 'Textures\Men\ActionsPage'. This folder contains a text file for every specific-unit in the game (eg: Pikemen.txt, Peasants.txt etc). This text file basically contains -

1) a list of all the possible actions this specific-unit can perform, each action followed by:
2) 4 lines of parameters (1 per camera-angle), each line referencing the correct image to be used
in the generic-unit BIF's for this combinationof specific-unit/action/camera-angle

Each line in 2) also defines an x/y co-ordinate (which I refer to as the 'xy-origin'; more of this later!).

Other files/folders pertaining to a specific-units actions are also contained within the general folder 'Textures\Men\Items'. This 'Items' folder serves to define the positioning of shields/weapons on any specific-units figure-image, for the action being performed. More of this later!


(Note: there is another folder that also appears to define specific-units and actions, 'Textures\Men\ActionsDiddy' - ignore it - it is'nt used)


Note that some of the various actions, and hence the parameters/files associated with that action, may be very similar across several units (eg: 'stand' or 'walk' actions for Spearmen/Peasants/FeudalSergeants). Other actions will be very different (eg: 'fight' action for a Spearman/Billman/MedievalManatArms).

Therefore, whilst many of the parameters/files pertaining to action may be re-usable across some types of specific-unit, others will most certainly not be.

[Wellington]

PART 4: Weapons/Shields and specific-units

Each specific unit may have weapons and shields defined for them.

All weapon/shield images are also defined by their image-rectangles, but as shields and weapons are always generic the xy-coords of these are defined by 1 line in either weapons.txt or shields.txt - two files contained within each generic-unit folder.

These 2 files contain 1 line per shield/weapon in the BIF, each line giving the xy-coords of the image-rectangle. Any specific-unit defines its weapon and shield by referencing the line number, in the weapons.txt/shields.txt files, that define that weapon/shield.

This reference is contained in the appropiate '_S' or '_W' suffixed text file for that specific unit.

For example, if we consider a generic unit folder (the negro infantry generic unit - folder 'NegInf'), it will define the following generic files -

- NegInf.bif
- NegInf_H.bif
- Weapons.txt (2 lines defining a spear and axe image-rectangles)
- Shields.txt (1 line defining the shield image-rectangle)

This generic unit is used as the basis for 2 specific units, NegroSpearmen (shield and spear) and AbyssinianGuard (axe). Therefore the specific files required to define these specific units are -

- AbyssinianGuard_W.txt (contains the number '2' indicating the 2nd weapon in 'weapons.txt')
- NegroSpearmen_W.txt (contains the number '1' indicating the 1st weapon in 'weapons.txt')
- NegroSpearmen_S.txt (contains the number '1' indicating the 1st shield in 'shields.txt')

Hence we now have our specific units, defined via the '_W' and '_S' files.

However, some specific units may contain more than 1 weapon number in order to use different weapons for different actions. Missile units may have a bow/javelin/gun defined as a 'shoot action' weapon, and a sword for a 'charge action' weapon. For example, the file Arquebusier_W.txt (Within the 'HlPlArHm' generic unit folder) defines 2 weapons - the primary weapon being an arquebus and the secondary being a sword.

Note that, so far, we have only managed to associate shields/weapons with a specific-unit - and not with a specific figure-image.

[Wellington]

More to follow - but right now I'm going to bed!!!

[Wellington]

PART 5: More on weapons and shields


Weapons resizing

Weapons.txt also contains 2 more numbers. These are used for the rescaling of weapons, relative to the figure-image, BEFORE a full image is rendered. For example, look at the weapons.txt in Peasant folder. A single image-rectangle (representing the spear) is defined twice -

Line 6: 125,252,254,254,3,1
Line 7: 125,252,254,254,5,1

Line 6 defines a spear, line 7 a pike. The image is the same but the last 2 numbers serve to resize the length of the image in order to represent either a spear or a pike (in the ratio 3:5 respectively).

Likewise within the weapons.txt in MShelm folder we have -

Line 3: 92,216,172,230,2,3
Line 4: 92,216,218,230,1,3

Both lines define the image-rectangle for a poleaxe weapon. Line 4 is used for Crossbows, line 3 for MilitiaSergeants. You should now read the last 2 figures as fractions. For MilitiaSergeants this means the size of the poleaxe should be 2/3rds of it's defined image-rectangle when rendered on the figure. For Crossbows the size should be 1/3rd. The size of this 'poleaxe' image as rendered for the 2 units will now be in the ration 2:1, and for the Crossbows it now appears as a 'handaxe' as opposed to a 'poleaxe' .


Therefore the last 2 numbers in a weapons.txt line serve 2 purposes -

1) to resize a weapon relative to a figure
2) to portray a different type of weapon - by virtue of size


Weapons/Shields

I should now say that there is a major difference between shields and weapons (and its NOT the obvious one). For the purposes of animation shields and weapons are built differently onto the figure-image. The critia is "would that object look different if viewed from a different camera-angle?" - object meaning weapon or shield. Any object that may look different (shield, crossbow) is defined as a shield. Those that would not (spear, pike, arquebus, sword) are defined as a weapon.

For example, if you look at a shield from the front and then the side, it obviously looks different. If you look a spear or pike it does'nt (ok, halbards and swords are still defined as weapons - this is because the difference, when viewed from front/side is so little as to be irrespective).

Therefore, the MTW engine, when rendering an object that has been defined as a WEAPON on an image need only consider the length perspective (ie: a line). When rendering an object defined as a SHIELD, however, it must consider both the length and the width perspectives (ie: a rectangle - or more precisely a quadrilateral!).

(Note: that is why a crossbow is defined as a shield - instead of a weapon!)

Some objects may be difficult to determine whether or not they should be represented as a weapon or shield. That is why (presumably!) archers/bowmen don't have their weapons defined in the standard manner but have their bows already drawn onto the actual images.

[Wellington]

PART 6: Defining object parameters for positioning

Before we can look at how any object (weapon/shield) is 'positioned' in order to look realistic on each figure-image, we have to ascertain "where everything is".

In order to perform this positioning MTW defines 8 weapon folders ('weapon1' - 'weapon8') and 8 shield folders ('shield1' - 'shield5' and 'shields'), all within the folder 'Textures\Men\Items'. For reference, lets call each of these folders an 'object folder'.

Note: the folders 'shields' and 'weapons', also defined, don't appear to be used.

The number suffixes relate directly to specific lines in the weapons.txt/shields.txt files contained in the generic-unit folders.

Any specific-unit that references one of these lines must also have its own folder defined in the appropiate object-folder. These folders will have the same name as the specific-unit. For reference, lets call each of these folders a 'unit object folder'.


Considering the previous example -

- AbyssinianGuard_W.txt (containing '2') requires an 'AbyssinianGuard' folder within the 'weapon2' folder.
- NegroSpearmen_W.txt (containing '1') requires a 'NegroSpearmen' folder within the 'weapon1' folder.
- NegroSpearmen_S.txt (containing '1') requires a 'NegroSpearmen' folder within the 'shield1' folder.


Why have all these object-folders? Why not just have 1 folder for weapons objects and 1 for shields objects ? Well, that is because some specific-units have 2 weapons or 2 shields (remember - a crossbow is actually defined as a shield!), thus requiring 2 unit-object-folders.


I should now stress that the use of objects is directly related to the action being performed. For example Arquebusiers have an arquebus (used for shoot action) and a sword (used for fight action).

Now, what are all these unit-object-folders actually used for ?

Well, each unit-object-folder contains 1 or more text files, each text file pertaining to the positioning of the object for any specific action the figure may perform. Lets refer to these files as the 'action object file'.

There is a major different between unit-object-folders, containing action-object-files, pertaining to shields and those pertaining to weapons -

- for shields, almost ALL actions require an action-object-file
- for weapons, an action-object-file is only required if the weapon is relevent (ie: in use or visible) for the action


For example, consider EarlyRoyalKnights -

- the ActionPage defines 6 actions for this unit (charge/die/fight/run/stand/walk)
- EarlyRoyalKnights_W.txt defines weapon 2 (Lance)
- EarlyRoyalKnights_S.txt defines shield 4
- weapons2 defines an EarlyRoyalKnights unit-object-folder, which contains 6 text files (1 per action)
- shields4 defines an EarlyRoyalKnights unit-object-folder, which contains 6 text files (1 per action)

Therefore, we see that both the Shield and the Lance for this unit are either visible or in use for all actions.


Now consider Arquebusiers -

- the ActionPage defines 9 actions for this unit
- Arquebusiers_W.txt defines weapon 2 (Arquebus) and weapon 1 (Sword)
- weapons2 defines an Arquebusiers unit-object-folder, which contains 8 text files (1 per action excluding 'fight')
- weapons1 defines an Arquebusiers unit-object-folder, which contains 1 text file (the action 'fight')

Hence, Arquebusiers use their arquebus for all actions except fight. For the fight action which they use a sword and the arquebus is not shown on the image for this action. Arquebusiers carry no shield - hence no shield folder required.


A point to note here. Missile troops are defined as having missile type weapons in the crusader_prod11.txt file. If you wish to change an Arquebusiers weapon image from a gun to an axe, the unit will still be capable of 'firing the axe' on the battlefield !!! These are IMAGES only!

[Jagger]

Please don't stop! This is some good stuff!

[Wellington]

PART 7: Positioning of objects on a figure-image


So we now know that an action-object-file is required to "define the positioning of any object, weapon or shield, for any figure-image performing a specific action".

Ok, but what about the 4 different camera-angles and 12 different frames for each action ?

Well, if we look into any of these text files, for either shield or weapon objects, we see that they ALL contain 48 lines (although the number of parameters per line are slightly different for weapon and shield action-object-files).

The 48 lines in each of these action-object-files should be thought of as 4 groups of 12 lines, representing -

- 1st 12 lines; parameters for each of the 12 frames for camera-angle 1
- 2nd 12 lines; parameters for each of the 12 frames for camera-angle 2
- 3rd 12 lines; parameters for each of the 12 frames for camera-angle 3
- 4th 12 lines; parameters for each of the 12 frames for camera-angle 4

Let's call each set of 12 lines an 'action object set', and each line an 'action object line'.

(apologies for all the terminology/definitions - it IS important to track of what I'm trying to say - if only for me!)


Thus, we have finally reached the point whereby we can say that - "an action-object-line serves to define the position of a specific object, within one specific frame in the movement-cycle, for the figure image of a specific unit, performing a specific action, for a specific camera-angle".


Phew! At this point I should also say that whilst all of this 'MTW animation system' may appear to be overly complicated, it is also EXTREMELY FLEXABLE.

To continue, however, action-object-lines for shields contain 9 parameters, whilst for weapons they only have 5. Why? We'll see why a bit later. For now lets just say they represent xy-coords in order to provide a degree of 'fine tuning' for any object on any figure-image frame.


Let's now look at a few examples of these action-object-lines, for both weapons and spears. Let's use the Spearmen specific-unit to illustrate. Spearmen have 1 shield and 1 weapon defined for them. Let's also consider three actions for the Spearmen - 'stand', 'walk' and 'die', but only for camera-angle 1 (ie: we'll only look at the 1st action-object-set - the 1st 12 lines - we'll ignore the other 36 lines).


So, the 6 files we'll be looking into are -

a) Textures\Men\Items\Shield3\Spearmen\stand.txt
b) Textures\Men\Items\Weapon6\Spearmen\stand.txt
c) Textures\Men\Items\Shield3\Spearmen\walk.txt
d) Textures\Men\Items\Weapon6\Spearmen\walk.txt
e) Textures\Men\Items\Shield3\Spearmen\fight.txt
f) Textures\Men\Items\Weapon6\Spearmen\fight.txt


We don't have to understand (yet) all the numeric parameters contained in these files. Some things should become evident. So, what do the 1st 12 lines (the action-object-set) of these files actually contain -


Example 1: Action stand
-----------------------


Shield3 Weapon6

10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0
10 -38 8 -38 10 -15 8 -15 1 -3 -25 -3 -5 0


Ok, so the numbers above represent positions on a figure image.

The first thing we see is that each action-object-set is different for weapon and shield. In other words, these 2 objects are in different positions on the figure image. Obvious! The shield is in one hand and the spear is in the other!!

The next thing we see is that each action-object-line is the same, for each shield and weapon set. In other words for all 12 frames representing the 'movement sequence' for Spearmen standing. What does this tell us? It tells us that the shield and weapon images remain in exactly the same place RELATIVE TO THE FIGURE IMAGE. In other words THEY DONT MOVE. As these 2 sets are specifically for a spearman standing still - only to be expected.

Why 'relative to the figure image'? Well, in this example all 12 frames for the figure-image don't move much either (the head bob's back and forth but that's about all!). However, IF the 12 frames in the movement-sequence for Spearmen standing were redrawn to show the whole figure moving slightly back and forth (let's say to stretch their legs!) then the above 2 set's of parameters would probably have to be amended slightly to ensure the weapon and shield stay in-sync with each new/redrawn figure-image for each frame in the movement-cycle.

Example 2: Action 'walk'
------------------------


Shield3 Weapon6


7 -35 7 -30 15 -18 15 -13 0 -9 -22 -16 -17 0
6 -38 5 -35 16 -16 15 -13 0 -9 -21 -17 -18 0
6 -39 5 -38 15 -15 13 -14 0 -10 -20 -18 -19 0
7 -39 5 -39 15 -14 13 -14 0 -10 -19 -18 -19 0
7 -38 5 -37 15 -14 13 -13 0 -9 -19 -18 -18 0
7 -37 6 -34 16 -15 14 -12 0 -9 -20 -19 -17 0
6 -35 6 -30 16 -18 15 -13 0 -8 -22 -19 -17 0
7 -33 8 -26 14 -20 14 -13 0 -7 -24 -19 -17 0
8 -30 9 -23 13 -21 14 -14 0 -6 -25 -18 -16 0
9 -28 11 -20 11 -22 12 -15 0 -6 -25 -17 -15 0
9 -29 11 -22 10 -21 11 -14 0 -7 -23 -17 -13 0
9 -31 11 -24 11 -19 12 -12 0 -8 -22 -18 -13 0


Now the Spearman is walking we see a slight change in the parameters for both the weapon and the shield. This tells us that the positions of each object differ for each frame of the movement-cycle for Spearmen walking. This makes sense. We'd expect both objects to swing/shuffle as the figure walks. They would'nt remain 'still' for this specific action.

Two things to note with the parameters in these 2 action-object-sets -

First, the values don't change much. In other words the 'movement' of these objects is not great in respect to the figure-image.

Second, the parameters in the first and last action-object-lines stay relatively close together (in terms of the numeric values specified). This is VERY IMPORTANT, and is generally the case for most actions!

Why? Well, consider each of the 12 action-object-lines in an action-object-set that represent object positioning for a movement-cycle - CYCLE being the operative word! As these movement cycles are looped continuously for the animations, you have to ensure any object ends up in roughly the same place from where it started. If the parameters for object-action-line 12 were VASTLY different to those in object-action-line 1 you would witness great 'jumps' in the positioning of an object within a movement-cycle. Not conjucive to smooth animation!

The exception to the rule is our final example.


Example 3: Action 'die'
-----------------------


Shield3 Weapon6

10 -25 13 -34 14 -27 15 -36 0 -3 -34 4 -23 0
7 -25 8 -34 18 -21 19 -29 0 -6 -33 2 -30 0
11 -25 12 -33 18 -17 16 -26 0 -6 -30 1 -32 0
19 -23 15 -31 17 -20 13 -27 0 -5 -23 -4 -25 0
23 -14 22 -22 12 -19 10 -27 0 -5 -5 -10 -5 0
24 -1 29 -8 9 -10 13 -18 0 2 -2 -11 -10 0
22 3 27 4 18 -19 22 -19 0 6 5 -10 1 0
9 -1 10 4 33 -6 35 -1 0 9 5 -8 3 0
9 -1 10 3 32 -6 34 -3 0 8 5 -8 3 0
9 0 10 3 32 -6 34 -3 0 8 5 -8 3 0
9 0 10 3 32 -6 34 -3 0 8 5 -8 3 0
9 0 10 3 32 -6 34 -3 0 8 5 -8 3 0


So now we have the 'die' action.

Now we see that the parameters are changing rapidly at first, then eventually remain constant. In other words, the object images for both shield and weapon move about a bit at first then remain in the same place (all relative to the frame of course!). This also makes sense.

Obviously, as our Spearman is dying the movement-cycle for the figure-image will show him dropping to the ground then remaining there. Therefore the first few action-object-lines change position rapidly in order to show his objects falling with him. The last few action-object-lines are the same, which tells us the objects ar'nt moving (these last few lines actually position the objects on the ground - whilst the final 4/5 cycles of the figure-image show him oozing blood!).

Our Spearman has now died and after this movement-cycle all animation ends in respect of this single figure-image in the specific-unit Spearmen. Note - he is only one of the figure-images in this unit of 100 or whatever. However, he is now replaced by an image in the Deadpage (more of this later!).

Therefore, the 'die' action is the one movement-cycle whereby the final positions of the figure-images objects are totally unrelated to the starting position. Why? Because this specific movement-cycle for the action 'die' in NOT looped continuously - it only happens once. Cat's may have nine lives; Spearmen don't!

'Hands on' Example!
-------------------

If you feel adventurous and are eager for more punishment, try the following example! It's for the Pikemen specific-unit (as the change/amendment to the weapon is far more visible).

We are going to change the Pike parameters for the 'stand' action, in order to make it 'sway' a little instead of remaining still.


1) Make a backup of the 'Textures\Men\Items\Weapon7\Pikemen\stand.txt' file.

2) Replace EACH of the 4 action-object sets in this stand.txt file with the action-object-set below (in other words delete the whole contents of the original and copy the 12 lines below 4 times) -

9 -21 10 0 1
9 -21 10 0 1
9 -21 10 0 1
10 -21 9 0 1
10 -21 9 0 1
10 -21 9 0 1
10 -21 9 0 1
10 -21 9 0 1
10 -21 9 0 1
9 -21 10 0 1
9 -21 10 0 1
9 -21 10 0 1

3) Next time you play MTW in the Late Period (or if you wish - create a Historical Battle/Campaign and define a Pikemen unit) start a battle with an army that contains a Pikemen unit and see what happens to the weapon whilst the Pikemen are standing still.

4) Position the camera in front of, or behind,the middle of the unit. Watch the Pike! Notice how some figures 'sway the Pike inwards' whilst others 'sway it outwards'. Can you see why this is? (Remember: 4 camera-angles that serve to represent 8 animations).

Note: if you try this make sure you have 48 lines in the stand.txt file. Any less and you'll experience a crash to desktop whilst the battle is loading.

Example Summary
---------------

Well, we still don't know what these numbers represent. Hopefully, though, the above examples haven given a 'feeling' for how these parameters work in respect of object positioning on a figure-image.

I've tried to stress that the parameters in any single action-object-line are ALWAYS relative to the figure-image in the movement-cycle frame. Two things to note in this respect (which don't occur often and are only an 'aside') -

First, any object may appear to be 'not moving' in the animations, but the action-object-lines comprising the action-object-set may be slightly different. This is because the actual figure-image frame may be moving, and as the object must remain relative to each of these frames repositioning of the object may be necessary.

Second, and conversely, the object may appear to move in the animations, but the action-object-lines comprising the action-object-set may be exactly the same. Same reason as above!


As a final note to this PART - if you take a look at enough of these action-object-sets and action-object-lines, after a while you can often have a good 'guess' as to what the object is 'doing' - roughly speaking. Alternately ... doing this may drive you mad!!!

[Wellington]

Hhmmm - posting this last part f****d up the text file positions for the shield/weapon definitions. Shit!

Never mind - I'll repost this PART in a different manner -

[Wellington]

The parameters for the shield/weapons lines for Spearmen in the previous PART 7 for the 3 Examples were intended to read -

Example 1: Action stand
-----------------------


Shield3

10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1
10 -38 8 -38 10 -15 8 -15 1

Weapon6

-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0
-3 -25 -3 -5 0


Example 2: Action 'walk'
------------------------


Shield3

7 -35 7 -30 15 -18 15 -13 0
6 -38 5 -35 16 -16 15 -13 0
6 -39 5 -38 15 -15 13 -14 0
7 -39 5 -39 15 -14 13 -14 0
7 -38 5 -37 15 -14 13 -13 0
7 -37 6 -34 16 -15 14 -12 0
6 -35 6 -30 16 -18 15 -13 0
7 -33 8 -26 14 -20 14 -13 0
8 -30 9 -23 13 -21 14 -14 0
9 -28 11 -20 11 -22 12 -15 0
9 -29 11 -22 10 -21 11 -14 0
9 -31 11 -24 11 -19 12 -12 0


Weapon6

-9 -22 -16 -17 0
-9 -21 -17 -18 0
-10 -20 -18 -19 0
-10 -19 -18 -19 0
-9 -19 -18 -18 0
-9 -20 -19 -17 0
-8 -22 -19 -17 0
-7 -24 -19 -17 0
-6 -25 -18 -16 0
-6 -25 -17 -15 0
-7 -23 -17 -13 0
-8 -22 -18 -13 0

Example 3: Action 'die'
------------------------


Shield3

10 -25 13 -34 14 -27 15 -36 0
7 -25 8 -34 18 -21 19 -29 0
11 -25 12 -33 18 -17 16 -26 0
19 -23 15 -31 17 -20 13 -27 0
23 -14 22 -22 12 -19 10 -27 0
24 -1 29 -8 9 -10 13 -18 0
22 3 27 4 18 -19 22 -19 0
9 -1 10 4 33 -6 35 -1 0
9 -1 10 3 32 -6 34 -3 0
9 0 10 3 32 -6 34 -3 0
9 0 10 3 32 -6 34 -3 0
9 0 10 3 32 -6 34 -3 0


Weapon6

-3 -34 4 -23 0
-6 -33 2 -30 0
-6 -30 1 -32 0
-5 -23 -4 -25 0
-5 -5 -10 -5 0
2 -2 -11 -10 0
6 5 -10 1 0
9 5 -8 3 0
8 5 -8 3 0
8 5 -8 3 0
8 5 -8 3 0
8 5 -8 3 0

Hopefully these parm's will show up being a little bit better spaced.

[Wellington]

Still shit! This forum does'nt like multiple spaces in lines. It reduces them all to 1 space.

Any ideas anyone?

[GilJaysmith]

Try the code tag... see http://www.totalwar.org/ubb/ubbcode.html

e.g.

code:#!/usr/bin/perl

I'd like two spaces between each word here please.

print "Content-type: text/html

";
print "Hello World!"; [/QUOTE]


[This message has been edited by GilJaysmith (edited 10-14-2002).]

[MagyarKhans Cham]

Message from my Khan...

"Hi Wellington http://www.totalwar.org/ubb/redface.gif)"

[Lord Krazy]

you wrote in one of my threads that ratio at the
end of the the line in weapon.txt

e.g.
Line 6: 125,252,254,254,3,1

did not make any difference to the pespective
of the weapon and weapon movement


Now if one of the 0 point is in the
center of the image and another
on the ground so to speak and you
change the length of an object
and make it longer for example
you must change the weapons files too
if they are set for a differant weapon
with different dynamanics
and if you don't change the width
then it should appear thiner and at
somepoints make the object dissapear.
This in my mind is changing the perspective.

Do you understand what I mean?
This question is for Welly btw.

LK

[Wellington]

PART 8: Object parameters for positioning

Let's now look at the specific parameters that make up an action-object-line, and the considerations for object positioning on a figure-image.


The xy-origin
-------------

In PART 3 above we mentioned the xy-origin, this xy-origin being the first 2 values defined on every parameter line of a specific-units action file in the ActionsPage folder.

Remember, each of these lines also contain parameters that define the image-rectangle in the BIF's to be used for a specific action/camera-angle. Thus, the xy-origin is DIRECTLY RELATED to any figure-image for both an action and a camera-angle. Therefore, it is constant for all of the 12 frames comprising the movement-cycle, just as the other parameters on the same line (the image-rectangle coords) are.

From this we can see there is an xy-origin for EVERY action/camera-angle, and it is defined as a pair of x/y coord parameters in a line pertaining to action/camera-angle.


Why so many xy-origin's for just 1 specific-unit ?

Well, unfortunately not all image-rectangles are the same size. Consider an Arbalest standing shooting and kneeling shooting. Different sizes (heights) of image-rectangles. Also, consider any unit walking. The image rectangles may be different (widths) depending on the camera-angle.

Therefore, any figure-images image-rectangle size will differ for different actions and camera-angles. although they will be constant for a movement-cycle.

The only image-rectangle we know is constant (for any specific-unit) for several images is the one that relates to all 12 frames in a movement-cycle - ie: the figure-image. Make sense?

We can now say that THE XY-ORIGIN IS CONSTANT FOR ALL 12 FRAMES IN A MOVEMENT-CYCLE.


Ok, so what is the purpose of the xy-origin?

We have seen in the previous PART that the numeric parameters within an action-object-line may well be negative as well as positive. Why is this ?

Well, up to this point, all image-rectangles and all x/y coordinates defining them, have been specified in numeric terms RELATIVE TO THE LOW RES BIF FRAME in which the image-rectangles are contained. In other words, relative to a 0,0 origin that is defined as the top left hand corner of the low res BIF frame. As all coords are relative to a BIF's origin point in a corner - hence all numbers are positive.


Rescaling and reorientation
---------------------------

Let's now digress a little.

We have seen that rescaling of a figure-images image-rectangle, and perhaps reorientation also, is necessary before rendering objects onto the figure-image. After these 2 processes the image-rectangle of the figure-image can now been considered to have its OWN origin. The 0,0 origin of the image-rectangle that defines the figure-image - as opposed to the 0,0 origin of the BIF that contains image-rectangles for multiple figures, as well as image-rectangles for shields and weapons.


To illustrate this consider the text file 'Textures\Men\ActionsPage\Pikemen'. The 1st 5 lines specify the parameters for all 4 image-rectangles (1 for each of the 4 camera-angles) for pikemen walking.

"walk
11 44 1 39 23 88
16 43 221 56 253 104
12 43 48 184 1 213
12 44 84 80 108 130"

Ignore the 1st 2 values per line (the xy-origin) for the moment.

If we rescale each of the image-rectangle parameters, relative to their own x/y origins (not THE xy-origin!) we get -

"walk
11 44 0 0 24 48
16 43 0 0 33 49
12 43 0 0 -50 30
12 44 0 0 25 51"

(remember the last 4 values represent 2 pairs of xy-coords - all we have done is subtract the 1st x value from the 2nd, and the 1st y value from the 2nd, then added 1 - than we have the true size of the image-rectangle - relative to its own 0,0 x/y origin)

We now see that a negative value appears in line 3. This tells us (and also tells the MTW engine) that this image-rectangle is lying horizontally in the BIF; therefore it requires reorientation. To do this merely swop the values and make all negative values positive (we are only concerned with the size of the image-rectangle - the MTW engine would have to perform a similar process for every pixel!).

We then have -

"walk
11 44 0 0 24 48
16 43 0 0 33 49
12 43 0 0 30 50
12 44 0 0 25 51"

Now we have the TRUE sizes of the image-rectangles defined (the last 2 values), no longer relative to the BIF but relative to their own origins (the middle 2 values - 0,0).


We can also now see that the xy-origin-coords (the 1st 2 values) serve to define a point (the xy-origin) in rescaled, and if necessary reoriented, image-rectangles for any figure-image.

(Note: the image-rectangle of a figure-image only defines the maximum size of an image in a BIF - the actually fully rendered image in an animation, once shield/weapon/mount have been added, may be larger than this rectangle)

Now lets move on to the actual parameter values.


Weapons parameters
------------------

When rendering weapons onto a figure we MUST think of the weapon image-rectangle as a line. Therefore, in order to position a weapon for any image in any frame we need 2 pairs of x/y coords to define the position of the 2 ends of the line; relative to the figure-image xy-origin.

For weapons folders each action-object-line contains 5 parameters as follows -

a) 2 xy-origin-positions for top left of the image-rectangle
b) 2 xy-origin-positions for bottom right of the image-rectangle
c) 1 rendering sequence value

The numbers contained in a) and b) are used to reposition a weapon RELATIVE TO THE XY-ORIGIN. As the xy-origin is constant for all 12 frames in a movement-cycle this means that the positioning of weapons (and also shields) is NOT relative to any single frame but to ALL 12 FRAMES comprising the movement-cycle - regardless of what each individual frames depicts as an image.

Two points to note here -

First, the xy-origin may appear to be an 'arbitory position' in an image, but it is generally specified as a point that serves as the 'centre of gravity' for objects on that figure-image. For example, Pikemen may have an xy-origin close to the head for many figure-images. Specific units with smaller weapons will tend to have the xy-origin defined closer to their chest.

Second, as the xy-origin (0,0) is a point defined somewhere in the 'middle' of any figure-image, we can expect the 2 pairs of xy-origin-positions to specify both positive and negative values, as they will have to define coords in the negative quadrents of the image-rectangle.


The rendering-sequence-value is either '0' or '1' and merely determines which image-rectangle is rendered first.

'0' means render the weapon before the figure
'1' means render the figure before the weapon

Hence the '0' and '1' really specify whether or not the weapon may be partially obscured by the figure. Obviously, this depends on the specific camera-angle for the figure-image/action.

How much of a weapon is obscured will also depend upon the size of the weapon and the positioning of it relative to the size/position of the figure-image.

(TIP: when building new specific units its a good idea to always specify '1' whilst testing, as this ensures that you can ALWAYS see the weapon)

Shields parameters
------------------

When rendering shields onto a figure we should think of the shield image-rectangle as a quadrilateral. Therefore, in order to position a shield for any image in any frame we need 4 pairs of x/y coords to define the position of all 4 corners of the quadrilateral; relative to the images xy-origin.

For shields folders each action-object-line contains 9 parameters as follows -

- 2 xy-origin-positions for top left of the image quadrilateral
- 2 xy-origin-positions for bottom right of the image quadrilateral
- 2 xy-origin-positions for top right of the image quadrilateral
- 2 xy-origin-positions for bottom left of the image quadrilateral
- 1 rendering sequence value

(PS: I may have got the exact corners of the quadrilateral incorrect - a minor point)

Therefore, by considering a shield image-rectangle as a quadrilateral, we can reconfigure such an image in any manner (size AND perspective) by amending 4 xy-coords. We can amend these cordinates to show a full frontal view, a side view, a tilted view - and almost anything else in between.


'Hands on' examples!
--------------------

As a bit of fun only, the following example is merely to illustrate the possibilities implicit in defining an object as a shield. I'm not interested in a 'perfect images here - only to show what's possible with a little 'tweaking' of values. The following example pertains to the shield image for the French Gendarmes in the 'stand' action.

As before -

1) Make a backup of the 'Textures\Men\Items\Shield2\Gendarmes\stand.txt'

2) Replace the 1st action-object-set in this stand.txt file with the action-object-set below (leave the other 36 lines as is) -

10 -48 8 -49 10 -27 10 -28 1
15 -48 8 -49 15 -27 10 -28 1
20 -48 8 -49 20 -27 10 -28 1
25 -48 8 -49 25 -27 10 -28 1
30 -48 8 -49 30 -27 10 -28 1
35 -48 8 -49 35 -27 10 -28 1
40 -48 8 -49 40 -27 10 -28 1
45 -48 8 -49 45 -27 10 -28 1
50 -48 8 -49 50 -27 10 -28 1
55 -48 8 -49 55 -27 10 -28 1
60 -48 8 -49 60 -27 10 -28 1
65 -48 8 -49 65 -27 10 -28 1

3) Start a battle with an army that contains a French Gendarme unit, and move the camera arounf the unit whilst they are standing still.

4) Now try playing around a little with the paramters above. See what's possible!

5) After you've finished 'playing around' don't forget to replace the stand.txt file with the original saved backup.

Summary
-------

I think by now you can see that the whole MTW animation process is governed by numbers which define positions of images, origins, coordinates, line references, values etc etc. Looks daunting at first but they DO make sense.

I hope by this time you will have developed an appreciation of the flexabilty in the 'MTW animation system' and (maybe) you now can see the potential for amending values to change the 'effect' of some animations.

Later on we'll look at the potential implicit in this flexability a bit more.

[Wellington]

LK,

I think I understand your question, and your quite correct in that I've not made this too clear -

this feedback is good! I may have said 'rescaling' in my reply to a previous post. If so, my

apologies for poor terminology.

Let me try to explain like this (a bit long-winded for your specific question LK but I'm thinking

in terms of documenting something I've overlooked so please bear with me!). If it does'nt answer

your question let me know.


Object and figure-image sizes in BIF's
--------------------------------------

Any generic-unit folder contains BIF image-rectangles for both figure-images and weapons/shields.

Considering these image-rectangles we see 3 things -

1) the size of all figure-images are ALWAYS constant to each other
2) the size of all shield images are also constant to each other, but not always constant to the

size of the figure-image that will 'carry' the shield.
3) the size of all weapons images are NOT constant to either each other (ie: other weapons

images) or the figure-images


Considering 2) above we see that in the generic-unit plate for Peasants the single shield image

defined looks fine (in terms of size) in respect of the figure images within that BIF.

Now look in the generic-unit plate for ChainHlm. We see 5 shields, and some of them are certainly

NOT good (in respect of size) for the figure-images defined on that plate.

Does it matter? Absolutely not! As any shield image is always positioned by virtue of the

parameters (4 sets of xy-coords for each corner of the shield) defined for an

action/camera-angle/frame in an action-object-line, the size of the original image in the BIF is

not important. In other words, a shield image is CONSTANTLY BEING RESIZED during animations.

You can make a shield image 10 times larger than the figure-image in the BIF (if it would fit!).

It matters not one iota!


Two points to note for shield images -

a) the shields.txt file within a generic-unit folder only contains parameters defining the

image-rectangle.

b) a shield image can only ever represent that specific shield image. It CANNOT represent any

other object.


Considering 3) above we see that (in any generic plate) the weapons images appear to be somewhat

'erratic' (in terms of size) relative to the figure-images defined on any plate. Far more so than

shield images.

Note: a weapon image in a BIF may serve to represent many different weapons. It CAN represent

other objects (weapons).


Two points to note for weapons images -

a) the weapons.txt file within a generic-unit folder contains parameters defining the

image-rectangle, and also 2 more parameters that serve to define the size of the weapon (relative

to the figure-image). Let's call these 2 parameters the 'weapon scaling parameters'.

b) a weapons image can represent multiple weapons, by virtue of the 2 'extra' parameters for

weapons referenced in a) above . It CAN represent any object that differs only in terms of size.

For example, a spear weapon may also be used to represent a pike - a poleaxe weapon may also be

used to represent a 'hand axe', etc, etc, etc.


The two stages of object scaling
--------------------------------

We can now say, in terms of object images -

- a shield image represents a single specific shield; full stop!
- a weapon image may represent multiple weapons (accomplished via the last 2

weapon-scaling-parameters as defined in the weapons.txt files).


Therefore, before any figure-image is rendered (with it's weapon/shield/mount) a rescaling

process must take place ONLY IN RESPECT OF WEAPONS, before the actual positioning of weapons and

shields relative to a figure-image frame can take place.

Hence, the MTW engine must consider 2 stages in respect of object scaling, and must 'ask itself'

the following questions -.

Stage 1: Do any weapons require rescaling, in respect of their size relationship with the

figure-image, in order to portray a different type of weapon. Should a weapon image really

portray a spear or a pike (sizewise)? Let's check the last 2 parameters of the appropiate line in

the weapons.txt file. If we have to rescale, let's do it now before the second stage (which

allows for positioning as opposed to size!). We can ignore shield images - they can only ever

represent 1 image (and hence don't have the same last 2 parameters that weapons images have for

rescaling).

Stage 2: Ok, any weapons that may have been resized are now THE CORRECT SIZE, IN TERMS OF A

SPECIFIC WEAPON OBJECT THEY ARE INTENDED TO PORTRAY, AND IN RELATIONSHIP WITH THE FIGURE-IMAGE.

Now let's look at how the weapons and shields objects require positioning on the figure-image,

via the action-object-sets and action-object-lines in order to change the perspective of these

objects, if necessary, for any frame in the movement-cycle.

[Wellington]

At this stage I should say 2 things -

a) I don't knoe exactly where my contributions to this thread will end, but my final PART will cover a checklist for creating new units within MTW. Probably be named 'PART x: Checklist for adding new units' or something similar.

b) Please feel free to question, and/or correct anything I've written. First, I certainly don't 'know it all' and I'm sure other people can contribute. Second, as the info in this thread is intended to serve as the basis for an 'MTW Animations modding guide' I would appreciate comments in respect of mistakes/omissions/repetition/bad terminology/confusing points/insufficient examples etc, etc

[Wellington]

Quote Originally posted by GilJaysmith:
Try the code tag... see http://www.totalwar.org/ubb/ubbcode.html

e.g.

code:#!/usr/bin/perl

I'd like two spaces between each word here please.

print "Content-type: text/html

";
print "Hello World!"; [/QUOTE]


[This message has been edited by GilJaysmith (edited 10-14-2002).][/QUOTE]

Thanks for the tip GilJay.

However, considering my last post for LK ...

... any ideas on prevent multiple spaces between lines ?

I HATE documentation on PC's. Give me ISPF or Script any day!

[Wellington]

PART 9: Mounts (camels and horses)


Up to this point we have only considered infantry figures. Now let's take a look at the cavalry.

There are 5 generic-unit folders that contain images for mounts -

1) Armhorse (an armoured horse)
2) Camel (an african camel)
3) Ehorse (an East-european style horse)
4) Khorse (a Knights horse)
5) Lihorse (a light horse)

Mounts are ALWAYS generic. Therefore, unlike the generic-unit folders for figure-images

(infantrymen/cavalrymen), the generic-unit folders for mount-images contain nothing else. There is

nothing specific to associate with a mount within its folder.

These folders each contain a hi res and a low res BIF, depicting 16 images only.

These 16 images represent 4 actions, and 4 camera-angles per action, for any mount.

Mount-images only have 4 actions associated with them (stand, walk, run and die). Why? Because

although the figure-images of the cavalryman may have multiple actions associated with them, the

mount-image is not capable of some of these actions (eg: fight, shoot).

Therefore, an appropiate action for the mount must be considered depending on the actual action of

the cavalryman.

For example -

- figure-image action stand/shoot/fight = mount-image action stand
- figure-image action run/charge = mount-image action run
- figure-image action walk = mount-image action walk
- figure-image action die = mount-image action dies .... and so on and so forth

Therefore we can see that mount-images, just like figure-images, are also 'action driven', but are

directly related to the action being performed by the cavalyman.

As all mounts are generic, any specific-units (representing a cavalryman - not an infantryman!)

may be associated with any mount. This association is, again, contained in the crusader_prod11.txt

file.


Mount definitions
-----------------

Where are the actions and image-rectangles for mount-images defined? In there own text file within

the same 'Textures\Men\ActionsPage' folder that also contains the specific-unit definitions. Let's

call these text files the 'mount definition' file. For mounts the names of the mount-definition

files are exactly the same as those of the generic-unit folders for mounts.

The contents of these mount-definition files contain similar lines and parameters as for

specific-units (an action followed by 4 camera-angle parameter lines), BUT ARE USED FOR 2 SLIGHTLY

DIFFERENT PURPOSES -

1) the actions do NOT represent the mount actions, but the actions of any specific-unit that may

be associated with this mount.
2) the xy-coords are NOT used for the positioning of weapons/shields, but for the positioning of

the Cavalrymans image-reactangle relative to the image-rectangle of the mount.


For example, consider the mount-definition file 'Textures\Men\ActionsPage\Lihorse.txt' for the

action standing_shoot -

"standing_shoot
14 54 195 1 138 29
21 50 195 125 246 175
19 44 165 124 121 175
12 40 37 95 65 142"


The parameters still represent 2 xy-origin-coords, and 4 xy-coords for the image rectangle.

However, considering the first parameter line, this now reads as -

"for any cavalryman image that is performing a standing_shoot action for camera-angle 1, use the

mount image (in this example in the Lihorse BIF) as defined by the image-rectangle 195/1 138/29,

then position the cavalryman relative to the point 14/54 in the mounts image-rectangle"

Note that any shield or weapon should have already been positioned on the cavalrymans

image-rectangle mount positioning takes place.

So, the xy-origin's for figure definitions serve to position objects on a figure-image. The

xy-origins for mount definitions serve to position a figure-image, together with his objects, on a

mount-image.

Note: the figure-image is ALWAYS rendered 2nd (ie: over the mount-image).


Positioning a figure on a mount
-------------------------------

Now lets take a look at the actual positioning process for mount and cavalryman.

If we rescale and reorient the values for the mounts image-rectangles in the example above we get

-

"standing_shoot
14 54 0 0 30 58
21 50 0 0 52 51
19 44 0 0 45 52
12 40 0 0 29 48"

We now see the xy-origins lie (generally) within the figure and somewhere near the 'top middle'!

They actually define a point just above the centre of the saddle on the mounts image-rectangle,

which is covenient for the positioning of the cavalyman.


Now let's take a look at a cavalryman (we'll use HorseArchers) that will use these 4

action/camera-angle image-rectangles for this mount. The file

'Textures\Men\ActionsPage\HorseArchers.txt' for the action standing_shoot contains -

"standing_shoot
16 62 210 1 170 30
13 62 28 59 58 100
7 62 254 1 212 24
8 60 26 102 48 141"

Rescale and reorient -

"standing_shoot
16 62 0 0 30 41
13 62 0 0 31 42
7 62 0 0 24 43
8 60 0 0 23 40"

Now look at the actual sizes of the image-rectangles (30/41, 31/42 etc) and consider the centre of

these image-rectangles. In order to position a figure relative to a mount, the MTW engine aligns

the centre of the image-rectangle for the cavalrymans figure-image over the xy-origin of the mount

figure-image. Is it as simple as this ? NO! But this is enough info to serve our purposes.

So, are ALL cavalryman generic-units and mount generic-units interchangeable ? Yes, it appears so

(allthough I hav'nt checked every combination!). Therefore if you want to create a new specific

unit by placing a Turkish Archer on a Knights horse - you can do so. Don't ask me what this new

specific-unit would represent; it's only an example.


'Hands on' example
------------------

To illustrate the above (and because its also a bit of fun!) try the following simple examples -

1) take a backup copy of the mount-definition file in 'Textures\Men\ActionsPage\Lihorse.txt'

2) amend the xy-origins for the 4 camera-angles for the stand action from

"stand
14 54 195 1 138 29
21 50 195 125 248 175
19 44 165 124 121 177
12 40 37 95 66 142"

to

"stand
14 0 195 1 138 29
21 0 195 125 248 175
19 0 165 124 121 177
12 0 37 95 66 142"

then see what what happens on the battlefield for any Cavalry specific-unit using this mount (eg:

Hobilars, HorseArchers, etc http://www.totalwar.org/ubb/smile.gif whilst they are standing.

3) amend the xy-origin again to


"stand
14 100 195 1 138 29
21 100 195 125 248 175
19 100 165 124 121 177
12 100 37 95 66 142"

and check again.

4) play around if you wish but don't forget to replace the backup copy after you've finshed.


(TIP: we can 'play about' with positioning values whilst in the same battle. Start a battle,

pause, Ctrl/Esc to desktop, change the values in whatever files your 'playing with', save them,

select the MTW battle again from the taskbar - the changes will take effect immediately. A lot

quicker than starting a new battle every time you change something!)


Example summary
---------------

There are two points to note from this example -

1) it's now obvious that the mount is positioned in respect to the cavalryman figure-image.
2) the algorithm used to position a mount image-rectangle relative to a cavalrymen image-rectangle

is actually more complex than we have specified above (but I have'nt worked out the exact formula
yet).

[Lord Krazy]

Just to clarify this point
from Welly.
_____________________________________________


(TIP: we can 'play about' with positioning values whilst in the same battle. Start a battle,

pause, Ctrl/Esc to desktop, change the values in whatever files your 'playing with', save them,

select the MTW battle again from the taskbar - the changes will take effect immediately. A lot

quicker than starting a new battle every time you change something!)
_____________________________________________

Do NOT copy a file from another directory
as this will not take affect.Just edit
fles in the directory they are in and do not
move them.Moving files from directory to
directory after you boot the game
dose not work well.
Just to make sure you don't misunderstand
what the man said.

great work welly

LK

[Wellington]

Thanks for the clarification LK.

I also was'nt sure if you could do this if you have a super PC with loads of memory. Maybe, with enough spare memory, the MTW engine would have more images pre-loaded - so you may not see some changes?

Hard to tell.

[Lord Krazy]

Quote Originally posted by Wellington:
Thanks for the clarification LK.

I also was'nt sure if you could do this if you have a super PC with loads of memory. Maybe, with enough spare memory, the MTW engine would have more images pre-loaded - so you may not see some changes?

Hard to tell. [/QUOTE]

-----------------------------------------------

This is also the case it seems.

LK

[Wellington]

Ok, to continue this thread I first have to post a correction to my previous (incorrect!) deliberations in PART 5.

So please read the next post as an amendment that replaces PART 5.

[Wellington]

PART 5: More on weapons and shields (AMENDMENT TO ORIGINAL TEXT)

Weapons resizing
----------------

Weapons.txt also contains 2 more numbers. These are used for the rescaling of weapons, relative to the figure-image, BEFORE a full image is rendered.


For example, look at the weapons.txt in Peasant folder. A single image-rectangle (representing the spear) is defined twice -

Line 6: 125,252,254,254,3,1
Line 7: 125,252,254,254,5,1

Line 6 defines a spear, line 7 a pike. The image is the same but the last 2 numbers serve to resize the length and breadth of the image in order to represent either a spear or a pike.

These last two values in such lines represent -

a) a length-multiplier for the weapon; prior to rendering
b) a breadth-multiplier for the weapon; prior to rendering

Therefore, 'Line 6' can be read as - "this weapon should be increased 3 fold in length before any rendering takes place, but retain the width (ie: 1 times the size modifier)".

Similarly, 'Line 7' can be read as - "this weapon should be increased 5 fold in length before any rendering takes place, but retain the width"

Hence these two weapons definitions serve to identify these 2 weapons to be in the ratio 3:5 lengthwise, whilst retaining the original width (as drawn on the BIFs).


Likewise within the weapons.txt in MShelm folder we have -

Line 3: 92,216,172,230,2,3
Line 4: 92,216,218,230,1,3

Both lines define the image-rectangle for a poleaxe weapon. Line 4 is used for Crossbows, line 3 for MilitiaSergeants. If we now read the last 2 figures as modifiers for both length and breadth we see that for MilitiaSergeants (line 3) this means the size of the poleaxe should be resized to be twice as long and three times as wide before rendering considerations for the figure-images. For Crossbows (line 4) this means the size of the poleaxe should be resized to be the same length but three times as wide before rendering considerations.

The size of this 'poleaxe' image as rendered for the 2 units will now be in the ration 2:1, and for the Crossbows it now appears as a 'handaxe' as opposed to a 'poleaxe'.

The following PARTS in this guide will serve to illustrate these parametres by examples.


Note: whilst these 2 resizing parameters are VERY IMPORTANT in terms of determining weapon sizes in respect of each other, and in relation to the figure-image, they are ALWAYS SCALED A 2ND TIME on the battlefield, to ensure these resized images fit within the co-ordinates defined by the action-object-lines pertaining to the figure-image/camera-angle/frame.


Therefore the last 2 numbers in a weapons.txt line serve 3 purposes -

1) to resize a weapons length relative to a figure
2) to resize a weapons breadth relative to a figure
3) to portray a different type of weapon - by virtue of size (ie: the 2 constraints mentioned above).

[Wellington]

This thread WILL CONTINUE!

Next 3/4 parts will be posted this weekend.

[Lord Krazy]

It better or I'll come to you house and
throw stones at your window
I'd use a sling but I haven't
got one http://www.totalwar.org/ubb/biggrin.gif

LK

[Fearless]

Hey Wellington!...... I am sitting waiting for the continuation of your very interesting write up. Any news??

[Wellington]

Coming tonight 3 more parts - I PROMISE!!!

Got a bit tied up working with LK on the new units.

[Fearless]

Okay I forgive you!

I would be interested in the work you have done with regards to the units. As I am at the moment contemplating doing the same if I have the time. As I have said to Lord Krazy I am a professional graphic designer so am very familiar with quite a few of the software packages.

[Swoosh So]

Nice to see peeps sharing their knowledge on modding , nice one welly

[fenir]

thanks Wellington, I have been waiting for you to finish this http://www.totalwar.org/ubb/smile.gif

PS: what program would you recommend for all this?

Or did I miss that part?

Thanks fenir

[Wellington]

PART 10: Artillery


MTW defines 11 types of battlefield artillery that are represented quite differently to Infantry and Cavalry units, in that they really consist of 2 different elements -

1) a specific-unit representing the artillery crew
2) a model representing the artillery piece


The artillery crew are merely another specific-unit, based on the Peasants generic-unit. The number of crew associated with each type of artillery piece (and the relationship between an artillery crew and a specific artillery piece) is defined within the crusader_unit_prod11.txt file.

Artillery pieces are represented as models (similar to houses, windmills, bridges etc) in MTW.

There are two types of Artillery models used within MTW -

1) static - used to represent artillery pieces in other model structures (eg: castles)
2) dynamic - used to represent artillery pieces on the open battlefield


We are (or I am!) not interested in Type 1) above.

For type 2) dynamic does'nt really mean DYNAMIC. It just means the model can turn a number of degrees. Dynamic models, as per all other models, CANNOT MOVE on the battlefield.


Where
-----

The artillery model definitions are mainly defined in their own folders within the general folder 'Models\Western European'. For example -

- 'Models\Western European\ballista'
- 'Models\Western European\Catapult'
- 'Models\Western European\demi-cannon' .... etc etc

Let's call these artillery-folders.

The actual images plates that contain the animation 'components' of an artillery model are not held in the artillery folders, but within the 'Models' folder, and are LBM files. For the above 3 examples these are named (respectively) -

- 0ballist
- 0catapul
- 0seige

These LBM files consist of a single plate of images pertaining to the various components of the artillery piece. Each component (barrel, sides, base, fence, etc) is also contained in it's own image-rectangle but the xy-coords of these are NOT defined in a moddable text file (as per other generic units) but are hard-coded.

Lets call these LBM files the artillery-plate.


Model files
-----------

Most models can be represented, and built, by virture of just 2/3 files - a TXX, a 3XX and (optionally) a txt file. For example, a bridge model is defined via the 2 files -

a) 'Models\Western European\Bridge.TXX'
b) 'Models\Western European\Bridge.3XX'

and the txt file -

c) 'Models\Western European\Bridge.txt'


The TXX files merely references the LBM plate(s) that contain the textures/images representing the individual components used to build the model (eg: gun barrel, gun carriage).

The 3XX files contain hard coded subroutines used (in conjuction with the TXX file) to actual build a visual 3D representation of the model.

The txt file serves to define various parameters (model height, model scale, is it an obstacle, what type of obstacle, etc) that overide a specific models characteristics from the 'norm'. What is the norm? A hard coded default set of parameters applicable to all models.


Animating Artillery
-------------------

For Artillery models there are 2 differences to most (not all) models -

a) they can rotate/fire (requiring animation)
b) they can be destroyed/collapse (requiring animation)

Consider a figure-units movement-cycle. 12 BIF frames are provided in order to animate any action. The 2 differences for artillery models mentioned above could be thought of as 'actions' that pertain only to Artillery type models. You therefore require some sort of 'frame' system for Artillery in order to animate the next 'frame' for the actions fire and collapse.

Let's call the 'frames' required for each of the Artillery animations above 'stages'.

These stages are actually hardcoded and are managed by means of parameter identifiers (named 'ObjectNN' where 'NN' is a number) that serve to defined the next hard-coded sequence that should be performed for the next stage in the Artillery models 'action'.


Artillery folders
-----------------

To handle the extra necessities, a) and b) as mentioned above, all Artillery models are contained in there own folders.

Each artillery-folder contains the 3 files required to build the static model, named -

- '2.TXX'
- '2.3XX'
- 'x.txt'

as per other models.


Each artillery-folder also contains 2 more sets of files pertaining to the animations required for a) and b) above. Lets call these the '0' and the '1' sets. Each set consists of 4 files. The '0' set, for example, consists of -

1) '0.TXX' - defines the artillery-plate to be used for the normal image
2) '0.3XX' - actually builds the model based on the plate(s) referenced in 0.TXX
3) '0c.ATX' - defines the artillery-plate to be used and the stages required (ObjectNN) in order to animate either action a) or b) above
4) '0c.A3X' - actually builds each stage in the animation (based on ObjectNN)

Consider, for example, that a catapult firing has to go through several stages in order to ensure fluid animation. The ObjectNN parameters mentioned above are merely references to subroutines in '0c.A3X', each subroutine building the next stage in the animation.


The '1' set is similar to the '0' set above.

Note that the '0' and '1' sets are specifically for animating the actions required by virtue of a) and b) above - either '0' is for rotating/firing and '1' is for destroying/collapsing or visa versa (don't ask me which is which!).

Note also, you can open all these files in notepad - may make more sense then!


Changing Artillery durability
-----------------------------

The amount of damage any model (and therefore Artillery models also) can take before they are destroyed is defined in the file 'Models\ModelDamage.txt'. This file basically contains 2 elements -

1) a damage class - defines the amount of damage a model can sustain
2) a model reference - serves to associate a specific model with a damage class


Considering 1), the damage class for all Artillery pieces is called 'weapon' and is defined as follows -

"DamageClass weapon
HitPoints 10
MinDamage 5
FireHitPoints 10
MinFireDamage 5
AttackableWithHandWeapons
SoundEffect SE_WOODEM_BUILDING_COLLAPSE
EndDamageClass weapon"


Considering 2), model references for Artillery pieces are defined as follows -

WE "Trebuchet" "weapon"
WE "siege-cannon" "weapon"
WE "serpentine" "weapon" .... and so on


If we wished to amend the amount of damage an Artillery pieces can sustain we can easily create another class and associate the model reference with our new class.

For example, if we wished to make siege-cannon more durable, and make it resistant to hand weapons, we could create a new model class -

"DamageClass toughweapon
HitPoints 20
MinDamage 10
FireHitPoints 20
MinFireDamage 10
SoundEffect SE_WOODEM_BUILDING_COLLAPSE
EndDamageClass toughweapon"

and change the model reference to -

WE "siege-cannon" "toughweapon"


(Note: there are extensive comments in the file ModelDamage.txt which explain every parameter in detail)


Summary
-------

You wish to play around with the parameters defining Artillery. Most of the parameters in the txt file (eg: bombard.txt) can be amended.

The most useful, in terms of modding, is probably changing the size of the model on the battlefield (animscale).

And that's all there is, as far as I'm concerned, to Artillery (although I'll add a bit in later PARTs regarding creating 'new' artillery pieces).

[Wellington]

PART 11: Elite unit shields


As we have seen, all specific-units may be alloted shields, providing a shield image is contained in the BIFs for the generic-unit.

MTW also provides for imaging of 'shield transfers' for some specific-units, the idea being that the shield image of the specific-unit is "overwritten" on the battlefield by a more suitable shield 'transfer' - specifically for that unit.

This allows for all units to utilise all shields in the BIF's, whilst providing for certain specific-units (Elite units) to have a second phase of "shield rendering" when the image is being built in order to represent a more appropiate heraldic design for that units shield.

This process is NOT limited to just certain specific-units, but to each faction that may build that unit. It other words, both French and English units of ChivalricMenAtArms can have different, faction dependant, shield transfers.

Lets call this 'shield system' FacShield (for faction shield), and refer to each image in a FacShield folder a shield-transfer.


Location
--------

MTW provides FacShield folders (for both lowres/hires images) for 10 specific-units. 9 of these units have a FacShield shield-transfer defined for all 20 factions. This is necessary as even though not ALL factions can build all of these unit types in the Campaign game, they CAN in Historic Battle/Historic Campaigns.

The names of FacShield folders are the same as the specific-unit name.

The shield-transfers for all 10 defined specific-units are TGA files and are contained in 2 folders, these folders being located in the folders -

1) 'Battle\FacShield\Lores'
2) 'Battle\FacShield\Hires'


For example, the 20 faction dependent shield-transfers for the unit ChivalicKnights can be found in -

- 'Battle\FacShield\Lores\ChivalricKnights\Almohad.tga'
- 'Battle\FacShield\Lores\ChivalricKnights\Aragon.tga'
- 'Battle\FacShield\Lores\ChivalricKnights\Burgundy.tga' ... and so on (all size 20x31)

and also in

- 'Battle\FacShield\Hires\ChivalricKnights\Almohad.tga'
- 'Battle\FacShield\Hires\ChivalricKnights\Aragon.tga'
- 'Battle\FacShield\Hires\ChivalricKnights\Burgundy.tga' ... and so on (all size 61x95)


Whilst each of the 10 specific-unit FacShield folders will contain different size/shape shield-transfers between folders, ALL of the 20 faction specific TGA's within any single folder will be the same size and shape (obviously!).


Size and shape
--------------

So, do the shield-transfer shapes and sizes match the definitions in the generic-unit BIFs? Shape - yes, size - no, not always; although the size is generally very close.

For example, ChivalricKnights shield-transfer sizes within the FacShield folder are 20x31 and 61x95 pixels for the lores and hires images respectively. Their generic BIF shield (2nd shield in shields.txt within PlateCav) is defined as '30,208,60,254'; a 31x47 image-rectangle in the low res BIF (62x94 for the high res).

Likewise, FeudalMenAtArms shield-transfer sizes are 20x44 and 44x96. Their generic BIF shield (2nd shield in shields.txt within ChainHlm) is defined as '85,207,106,254'; a 22x48 image-rectangle in the low res BIF (44x96 for the high res).

Does this matter? Not usually! All shield-transfers are rescaled (to some degree) during the rendering process in order to fit the size of the actual image-rectangle size defined in the BIFs. However, this rescaling process is'nt as obvious or 'exact' as you would expect - see examples below.

Why are shield-transfers only resized 'to some degree'? Because the algorithm for sizing in MTW appears to 'expect' a close corresspondence between BIF and FacShield images. If the sizes are close the resizing process appears to work fine - if the sizes are NOT close then some 'weird shield-transfer imaging' may occur.

Why ar'nt the FacShield shield-transfers the same sizes as in the BIFs? Well, the slightly different sizes in the FacShield folders are probably due to 'artistic considerations' - it may be easier to draw a specific shield-transfer image in a 20x44 frame, rather than a 22x48.


What about the shape? That's easy. All shield-transfers are drawn in the TGA's using the shape of the shield in the BIFs, and using the colour pink to 'outline' the image.


Note: the most important consideration in terms of how MTW defines and manages the FacShield 'system' (and therefore how we can manipulate thse FacShields!) is shield SIZE and SHAPE.


Exceptions to the rules
-----------------------

There are exceptions to the general FacShield 'system' -

a) the unit OrderFootSoldiers DOES have a FacShield folder, but this folder DOES NOT contain shield-transfers for all 20 factions but rather for all 4 Orders (hospitaller, templar, santiago, teutonic).
b) some Elite specific-units use the FacShield folders of other specific-units (eg: there is no folder for 'Gendarmes' - they use the folder defined for 'ChivalricKnights')
c) some Elite specific-units do NOT use the FacShield folders but have a shield-transfer actually drawn onto the generic-unit BIF's.


Considering a), as Orders ALWAYS have there own Heraldic shield images there is no provision for different images for different factions - is is'nt necessary.

Considering b), both Gendarmes and ChivalricKnights are defined via the generic-unit PlateCav, which contains 3 shield images in the BIF. The image-rectangle of the 2nd shield defined in shields.txt ('30,208,60,254') is used for both of these specific-units; hence as they both use the same shield image in the BIF (and therefore the same shield SHAPE and SIZE) they both share the same FacShield folder.

Considering c), all 4 Order Knights specific-units (KnightsTemplar etc http://www.totalwar.org/ubb/smile.gif, and TeutonicSergeants (which use the same shield as TeutonicKnights), are defined via the generic-unit Mknight. The 4 different shield images in the Mknight BIFs actually have a 'shield-transfer' drawn onto the shield image in the BIF - hence they do not require FacShield folder.

Note: The 4 OrderFootSoldier units all share the same BIF shield size - hence it's easier for the MTW engine to treat them 'as a group' via a FacShield folder. The 4 Order Knights units have different BIF shields (and therefore different shapes and sizes) - hence its easier to merely draw the 'shield transfer' directly onto the image in the generic-unit BIF, rather create a whole FacShield folder just for 1 unit.


What determines whether a unit is an 'Elite' unit with a FacShield? Although you'd expect to find this relationship in Crusader_unit_prod11.txt - it ISNT!! Its hard coded somewhere!

Can we add more shield-transfer folders for other units? Unfortunately, no. Its hard coded.


Also, considering points a) and b) above, it becomes obvious there MUST be some hard coding within MTW in order to represent these two exceptions from the norm.


'hands on' example
------------------

In order to illustrate the above, we can try a few examples using the Bannockburn Historical Battle. This is convenient as the Scot's have a unit of ChivalricKnights defined. Note that the Scot's in this battle use French shield-transfers for FacShields.

Remember - the size of the Hires shield-transfers for ChivalricKnights are 62x94.

Now, try the following -

1) Make a backup of the file 'Battle\FacShield\Hires\ChivalricKnights\france.tga'

2) Replace france.txt with the file 'Battle\batinit\Historical Battles\Battle of Bannockburn\scottish.tga' (Note: the TGA not the BIF!). You'll have to rename 'scottish.tga' to 'france.tga'

3) Start the Bannockburn battle and have a look at the replaced shield-transfer image on the Scottish Generals ChivalricKnights unit.

Three points of interest here -

- the shield-transfer is rendered onto the shield relative to the top left hand corner
- the area covered the shield-transfer is in proportion to the transfer size (32x32)
- the shield-transfer is considerably smaller than the Generals flag (remember - they are exactly the same image)

3) Now exit MTW, and replace france.txt with the file 'Battle\FacShield\Lores\ChivalricKnights\france.tga' (ie: using the Lores, 20x31, shield-transfer image on the Hires shield).

4) Start Bannockburn again, and take another look.

Now we see that -

- the area covered the shield-transfer is NOT in proportion to the transfer size (20x32) as it only covers approx 1/3rd of the width - we would expect it to cover about half.

5) Now try replacing france.tga by the file 'campmap\Portraits\Catholic\Admiral\admiral01.tga' (size 96x142) and take another look. Same problem as 4) above!

If you have a Graphics utility to resize tga's, try resizing admiral01.tga to 62x94, and try again. Interesting?

6) Finally try replacing france.tga with a ground texture - try 'Textures\Ground\Arid\180.tga' (size 256x256).

Animal hide?

Now 'charge' this unit, pause the game and look again! Can you guess what's happened to the bottom of the lance? (a bit of overwriting occuring here - after all, this is a BIG tga!)


7) After you've finished don't forget to replace the france.tga file with the original saved backup.

Summary
-------

If we want to replace the shield-transfers this is relatively easy, but it's preferable to ensure the new image size closely corresponds to the currently defined FacShield sizes as the scaling process for shield-transfers is as not as 'simple' at we would expect.

Although we can't delete the FacShield folders, or the shield-transder TGA's within, if you don't want a shield-transfer image for some units/factions, you can merely create a TGA containing just the pink 'outline' colour (ie: a 'blank transfer'). Then your Elite unit would retain the shield image as drawn on the BIFs - removing the 'Heraldic look'.

[Wellington]

PART 12: The Deadpage


We already know, from PART 7, that when any figure in a unit dies the last movement-cycle they perform is that for the die action, after which the single figure-image is replaced on the battlefield by an image in the Deadpage.

The 'Deadpage' actually consists of 2 files within the 'Textures\Men' folder -

1) 'DEAD256.LBM' - which contains images of all dead figures
2) 'Deadpage coords.txt' - which serves to define the image-rectangles of the dead figures


Note: there are also a few files in the same 'Textures\Men' that appear to be related (Deadpag2.txt, Deagpag2.lbm, Re-load.txt etc http://www.totalwar.org/ubb/smile.gif. Ignore them - they ar'nt used - merely a throwback from the Shogun days.


'DEAD256.LBM'
-------------

DEAD256 is a 256x256 LBM file that contains 4 images, 1 per camera-angle. Each of these 'sets' of 4 images serve to represent the dead figure/mount images for 1 or more generic-units.

It is not directly related to specific-units. Also, some generic-units share the same 4 dead images (eg: for mount images the generic-units LiHorse and Ehorse share the same 4 images).

Why is it an LBM and not a BIF? No idea!

All 4 images within DEAD256 share a common shape/position with the last 4 frames (for the die action) of the images in the generic-unit BIF's they are intended to represent. However, they do NOT share a common size!

For example -

- open the file DEAD256.LBM with a suitable graphics editor (Paint Shop Pro!)
- open the generic-unit file KHorse (with Bifreader 2.1) and view the last (12th) frame.
- compare the images of the dead Knights horse in both graphics (in DEAD256 they are near the top left hand corner)


You will see that whilst all 4 dead images are very similar, the DEAD256 images lack the resolution that is contained in the BIF's. Obviously so! Considering the number of images contained in DEAD256 these images are very cramped and suffer accordingly.


Note: dead figure images don't have weapon or shield objects, also dead mount images don't have a cavalryman image


'Deadpage coords.txt'
---------------------

'Deadpage coords.txt' basically contains -

a) a list of all specific-units, each specific-unit followed by:
b) 4 lines of parameters (1 per camera-angle), each line referencing the correct image to be used within 'DEAD256.LBM' to represent the dead figure or mount.


For example, the lines in this file pertaining to DesertArchers are -

"DesertArchers
26 13 173 311 224 334
21 16 76 177 113 204
24 15 141 259 186 284
26 13 279 311 334 334"


Each of these 4 lines represent -

1) an xy-origin for the dead image
2) 2 pairs of xy-coords defining the image-rectangle of the dead image


Unfortunately we now have a problem in that some xy-coords (such as the DesertArchers above) are greater than 255, and thus lie outside the 256x256 DEAD256.LBM plate. Also, other xy-coords, for other specific-units, don't appear to define image-rectangles within DEAD256.

Is this a problem?


Resizing DEAD256.LBM
--------------------

No problem! We merely have to resize DEAD256.LBM, increasing it by approx 30%, and making it 315x315 in size (or thereabouts).

Try resizing DEAD256.LBM (in Paint Shop Pro! or whatever) then re-check any of the image-rectangles defined in 'Deadpage coords.txt'. Now they will match the images! Also, re-compare the KHorse images as in the example above.

You will now see that the image sizes in DEAD256 are consistant with the images in the 12th frames of the KHorse generic-unit low res BIF.

However, due to the resizing process we have obviously lost some resolution here. This is why the DEAD256 image colours do not match exactly with the colours of the dead images in the generic-unit BIFs.

This beg's the following question -

"Why have CA chosen to use this 'Deadpage system', that loses resolution and adds another degree of complexity, when the BIF images for all generic-units already contain a perfect 'dead image' in every 12th frame of every camera-angle for the die action? Why not use that PERFECT image instead?"

My answer is - I suspect its a throwback to the Shogun days. Whilst CA have put a lot of graphics work in the creation of high resolution MTW units, a lot of the engine (and therefore program logic) must still originate from Shogun. Therefore there may have been too little time (in programming terms) in which to amend the engine logic to use the last frames of the newer/better images in MTW - it was easier to use the existing Shogun 'deadpage system'.


Positioning the dead-image
--------------------------

We can now see how the final frame in a die action movement-cycle (for any specific-unit) relates to an entry in the 'Deadpage coords.txt' file and hence to a dead image in 'DEAD256.LBM'.

Obviously the dead image in DEAD256 must be positioned correctly, in respect of the final frame of a movement-cycle for the 'die' action in any generic-unit BIF. This would ensure the dead image is positioned in the precise position, relative to battlefield terrain, on which the figure-unit was fighting - before he died.

Let's now consider how this dead image is actually positioned on the battlefield. To do this we have to compare 2 sets of values for the same specific-unit.


1) Taking the parameters in 'Deadpage coords.txt' from the example above -

"DesertArchers
26 13 173 311 224 334
21 16 76 177 113 204
24 15 141 259 186 284
26 13 279 311 334 334"

after rescaling and reorientation we have -

"DesertArchers
26 13 0 0 52 24
21 16 0 0 38 28
24 15 0 0 46 26
26 13 0 0 56 24"


2) Now let's look at the appropiate 'die' action lines from the unit-definition-file for DesertArchers ('Textures\Men\ActionsPage\DesertArchers.txt'). This contains -

"die
26 39 190 166 245 215
21 40 146 145 188 196
24 41 19 72 65 125
26 43 1 127 56 180"

after rescaling and reorientation we have -

"die
26 39 0 0 56 50
21 40 0 0 43 52
24 41 0 0 46 54
26 43 0 0 56 54"


We now see 2 things -


a) the image-rectangles for both sets of parameters have VERY SIMILAR values for the width (eg: 52/38/46/56 and 56/43/46/56), but different values for the height

b) the xy-origins for both sets of parameters have EXACTLY the same values for the x-coord (eg: 26/21/24/26), but different values for the y-coord.


Considering a) this is only logical. All 12 figure-images for a 'die' action movement-cycle are encapsulated in an image-rectangle that defines the maximum possible size for all images (ie: from the figure standing, getting killed, falling to the ground and then lying dead on the ground).

The 12th and final frame shows the figure image dead on the ground, covering a lot less height than when he was alive! If we were to redraw a 'true' image-rectangle for just the 12th frames image, the height would be a lot less. This redrawn height would be the actual height represented in the DEAD256 image (which does'nt have to consider 12 frames - merely the last one).

Therefore the image-rectangles in DEAD256 would match a 'true' image-rectangle for just the 12th frame for any 'die' action within the generic-unit BIFs.


Considering b) we expect the widths of the dead images to be the same (after DEAD256 has been resized). We also know that the x-coord of the xy-origin ( eg: the value 26 in the pair 26/39 for camera-angle 1) of the generic-unit image can be used to align both images on the x-axis, in terms of width. This is why the x-coord of the xy-origin for the DEAD256 image is EXACTLY the same as that specified for the generic-unit; for width alignment/positioning.

Now consider the height of the DEAD256 image. The y-coord (13/16/15/13) of the xy-coords of any image defined in the Deadpage is RELATIVE ONLY TO THE 12TH FRAME for that generic-units movement-cycle. The values 13/16/15/13 actually represent roughly half the height of the 'true' image-rectangle for the 12th frame in the generic-units 'die' movement-cycle (ie: the same image rectangles defined for in Deadpage Coords - for DesertArchers these have a height of 24/28/26/24).

In other words, the xy-origin of any DEAD256 image represents roughly the middle of a 'resized' and 'true' image-rectangle for just the 12th frame of a figure-images 'die' movement-cycle. In some cases it cannot be EXACTLY the middle of any figure-image as the image in DEAD256 may represent several dead figure-images for several generic-units.


Thus the DEAD256 image can be aligned/positioned, not EXACTLY but very close, in respect of the last frame of a 'die' movement-cycle.


'hands on' example
------------------


To illustrate the above, if your so inclined, try the following.

1) make a backup of 'Deadpage coords.txt'

2) Change xy-origin values in 'Deadpage coords.txt' for DesertArchers (or any other specific-unit) as follows -


"DesertArchers
0 13 173 311 224 334
0 16 76 177 113 204
0 15 141 259 186 284
0 13 279 311 334 334"

then

"DesertArchers
60 13 173 311 224 334
60 16 76 177 113 204
60 15 141 259 186 284
60 13 279 311 334 334"

then

"DesertArchers
26 0 173 311 224 334
21 0 76 177 113 204
24 0 141 259 186 284
26 0 279 311 334 334"

then

"DesertArchers
26 60 173 311 224 334
21 60 76 177 113 204
24 60 141 259 186 284
26 60 279 311 334 334"

3) check what happens (regarding positioning of the DEAD256 image) when any of the figures in the specific-unit dies; for each of the above combinations

4) dont forget to restore the backup afterwards

xy-origin's - the final word
----------------------------

We can see from this part, and previous parts, that although many xy-origin's are specified for different image types (objects/figures/mounts/deadpage images) they all serve a similar purpose.

They all serve to define different points for the purposes of positioning, and although the point/xy-origin may be specifically related to one image in respect of another image (or in respect to the battlefield terrain), the general principle is the same.

The MTW unit animation system relies heavily on this 'xy-origin positioning methodogy'.

[Wellington]

Wow, I kept my promise - someone please tell the ex-wife http://www.totalwar.org/ubb/wink.gif

Ok, the next 2 PARTS will be posted in 2 days time (they are already written but lets give 48 hours to digest the last 3 PARTs - and give me more time to write the next ones).

What PARTs are to come? Well, we are on PART 12 now. I anticipate 20 PARTS, the last 8 being -

PART 13: Unit and Faction colours
PART 14: New Units - possibilities
PART 15: New Units - objects
PART 16: New Units - specific processes
PART 17: New Units - special/different units
PART 18: Crusader_unit_prod11
PART 19: Other necessaties for modders
PART 20: Checklist for creating new units

As you can see, a lot of the more interesting PARTs are yet to come, but please bear with me on this. It's no good documenting something quickly if it turns out to be too obscure. I hope to have my contributions finished within the next 2 weeks (or less).

BTW - thank you for the feedback Guys. It serves to assure me I'm NOT wasting my time doing this!

Also, please feel free to whinge and whine if some aspects of what I've tried to cover ar'nt too clear.

regards,
Welly

[Wellington]

Quote Originally posted by Fearless:
Okay I forgive you!

I would be interested in the work you have done with regards to the units. As I am at the moment contemplating doing the same if I have the time. As I have said to Lord Krazy I am a professional graphic designer so am very familiar with quite a few of the software packages.[/QUOTE]

Fearless,

Thank you very much for the offer. Any help or assistance in any aspect of the 'modding projects' that are currently ongoing would be certainly appreciated - regardless of how much time any individual is capable of committing.

At present a few of us are heavily involved in releasing LK's New Units to the community and a few of us are quite involved in this. Having said that its LK that has really done all the hard work!

Basically we would love to have people who are skilled in the graphic process. In fact we'd love to get more people involved in the whole modding process (as a hobby!!) - which is one of the reasons this thread was started.

At present (for the next 2 weeks or so) we will be heavily involved in the QA/release process for LKs units - but we'd love to have more willing assistance from yourself and ANY OTHER INDIVIDUALS who are interested in modding MTW to produce new possibilities.

Keep in touch Fearless!

[Wellington]

Quote Originally posted by Swoosh So:
Nice to see peeps sharing their knowledge on modding , nice one welly[/QUOTE]

Er ... whats a peep?

My ex-wife used to call me that ... or something similar http://www.totalwar.org/ubb/frown.gif

[Wellington]

Quote Originally posted by fenir:
thanks Wellington, I have been waiting for you to finish this http://www.totalwar.org/ubb/smile.gif

PS: what program would you recommend for all this?

Or did I miss that part?

Thanks fenir[/QUOTE]

I don't follow you Fenir http://www.totalwar.org/ubb/frown.gif There is no 'program' involved at all. This thread is merely a write up of thoughts/knowledge/ideas/presumptions pertaining to the MTW animation processes - and how to mod them.

Program ??????

[Fearless]

Hi Wellington! I have to say I think you guys are doing a great job with all the effort that's going into the mods. Give me a little time to read and digest your articles to see what's involved. I do understand animation and frames rates and I do have the abilities to produce artwork. I used to be a pencil and paper with airbrush artist before this wonderful invention the 'Wacom tablet and pen'. To attempt to draw with a mouse is bloody difficult to put it mildly.

Changing the subject. I notice regarding animations that we have 12 frames containing a number of images. In each frame the images are different. On each frame are weapons. Would one have to reproduce the same to produce a new unit? Remember I am new to all this!

[fenir]

Wellington, oops sorry that part was suppose to go the thread for Lord Krazy.
Sorry it was late and I was having trouble with my bif loader. I then realised I needed v2.1.

Duh!
About then I went to bed.

The Numbers that represent the walk run idle etc... It looks like a matrix.
Probably works on the same basis. Just an idea.

Fenir

[Wellington]

Quote Originally posted by Fearless:
I notice regarding animations that we have 12 frames containing a number of images. In each frame the images are different. On each frame are weapons. Would one have to reproduce the same to produce a new unit? Remember I am new to all this![/QUOTE]

Fearless,

Ok, I was about to have a good whinge telling you read the writeup - then I realised I hav'nt yet posted the "New Unit - Possibilites" PART that details what's possible. A case of RTFM for myself!!

I'll post this part either tonight/tomorrow but for now lets just say -

- a 'new unit' should be defined as "what anyone (ie: modder) can CURRENTLY do to create a new representation, on the MTW battlefield, of a unit that may have have new/different weapons, shields (and other 'objects') or a different mount associated with the unit - but retains the basic generic image (with tunic/colours/images) of one of the several generic BIF folders that CA have provided us with for the basic/generic figure images"

- we CANNOT currently ADD new generic BIF folders as CA have hard coded these folder names into the MTW engine (obviously to protect their investment); so we cannot add new IMAGES for new units to MTW

- if you wish to create a completely new mod (ie: Roman mod/Fantasy mod) you can totally dispense with the 20 or so generic figure foldersd and create new ones (with all of the problems/work that this entails). You can then draw/redraw whatever images you want - using the same names for the actual folders as are hardcoded in the engine.

- if you do this you have to consider there are 6 basic (sometimes more) actions that are ALWAYS associated with a unit. Of these 6 2 are sometimes the same ('run' and 'charge'). Therefore we have 5 MINIMUM actions, 4 camera-angles per action and 12 frames that represent the cycle/sequemce of any action. This gives a minimum of 240 images to be drawn for the hi-res BIF's (the lo-res BIFs can be created from the Hi-res by merely resizing)

In practice your talking, on average about 7 actions per unit - so work that out! Not a proposal for the faint
-hearted.

Note that whilst many people may suggest a 'new' redrawn unit, or a completely new mod (ie: doing BIF's for many units for a different period of time, whilst retaining the MTW engine) the logistics of what is actually required are often overlooked.

Hope that helps for now.

[Lord Krazy]

Well at least you WTFM http://www.totalwar.org/ubb/biggrin.gif
Which is nice!

Regards,

LK

[Wellington]

Quote Originally posted by Lord Krazy:
Well at least you WTFM http://www.totalwar.org/ubb/biggrin.gif
Which is nice!

Regards, LK[/QUOTE]

Not finished yet mate ...

... Jeez why DID I ever start this!

BTW: I'll need some help from you LK in respect of some of the parameters in Prod11; in order to cover all aspects of the parameters in this file in a forthcoming part. Obviously, you have FAR more experience of this than me (having already created close to 100 new units!) so your help in this respect will be invaluable.

[Fearless]

Thank you Wellington now I know what work there is to produce a new unit. As you said not for the faint hearted!........Cheers!

[Wellington]

PART 13: Unit and faction colours, flags and banners


Each faction in MTW is represented by 2 colours, a primary and secondary. For some factions the 2 colours are the same.

The colours on all figure-images in the generic-unit BIFs, and within the Deadpage, can be thought of in terms of 2 types -

1) non-faction replacable colours
2) faction replacable colours

The non-faction replaceable colours are different for all generic-unit BIF and serve (in part) to identify the basic characteristics of a generic-unit such as armour/helmet/boots and other items of apparel that are not faction dependent.

The faction replaceable colours are the same for all generic-unit BIF and serve to identify (on the battlefield) which faction a specific-unit belongs to. These colours are various shades of green and purple, used on parts of a figure-images tunic and helmet plume, and signify to the MTW engine which areas of the tunic should by replaced by the faction colours when rendering the figure-image.

The RGB numbers for the faction replaceable colours are -

a) 0,anynumber,0 (green colours, except 128 - replaced by the factions primary colour)
b) anynumber,0,anynumber (purple colours - replaced by the factions secondary colour)


Note: there is also a standard background green which serves to outline the image (RGB 0,128,0) but we should'nt have to consider this.

All generic-unit figures contain these 2 faction replaceable colours. Generic-unit mounts do not (it is'nt necessary for mounts as the cavalryman figure-image associated with the mount will have faction replacable colours on his tunic.


Can we change any colours? The non-faction replaceable colours, of course. For the faction replacable colours we can also increase/decrease the area on the tunic that is currently faction dependent.

However, bear in mind that when changing colours on a generic-unit BIF -

1) any change will be effective for all specific-units using the generic-unit BIF
2) if the change is in respect of decreasing the amount of the 2 'faction replacable colours' on any BIF it may effect how 'identifiable' a unit is on the battlefield
3) you may have to change/recolour the image definition in the Deadpage


Faction colours and specific-units
----------------------------------

Where are the real faction colours defined, and how can we change them?

At present no-one has managed to figure this out yet. It would seem likely that faction colours are held in a hard-coded table somewhere the MTW main .EXE. Anyone adept at using a Hex editor could probably change the values in such a table, and hence change the predefined faction colours, but as yet any such table is still 'awaiting recognition/discovery' and therefore we can't change faction colours at present.


At this point I should say that whilst we know that all generic-unit are GENERIC, many specific-units are also generic; but in a somewhat different sense. Certain specific-units are generic in respect to certain factions (ie: nationalities) and/or religions. Many Christian factions have Peasants/Spearmen/Hobilars etc: that are specific to Christians. The various Muslim/Orthadox factions also 'share' a variety of specific-units that are only available to themselves. Likewise, only Orthadox Russians have the ability to create SteppeCavalry. This relationship between specific-unit and culture in defined via parameters in the crusader_prod11.txt file.

Therefore any specific-unit is specific (in terms of animation) in respect of the type of armament/shield/weapon/mount it is equipped with. It is also 'specific' (in terms of the actual MTW campaign game) in respect of the tactics employed by, and availabilty of, such a unit for a specific nationality/religion/culture.


Flags
-----

Most flags used on the battlefield are defined within the 'Battle\Flags' folder. This folder contains two file types, TGAs and LBMs. Each of these has 20 files named FLAG1001 to FLAG1021 (the last 2 digits representing the faction number). For example, the files ...

- FLAG1009.TGA
- FLAG1009.LBM

... represent the flag images used fot the Polish faction. The TGA image is used as the flag image for the generals unit on the battlefield. What about the LBM image? I'm not sure where this is used (if indeed it is) - if anyone knows please tell me!

The actual numbers representing the factions are -

1) ALMOHAD
2) BYZANTINE
3) DANISH
4) EGYPTIAN
5) ENGLISH
6) FRENCH
7) GERMAN_HRE
8) ITALIAN
9) POLISH
10) RUSSIAN
11) SPANISH
12) TURKISH
13) ARAGONESE
14) BURGUNDIAN
15) GOLDEN_HORDE
16) HUNGARIAN
17) NOVGOROD
18) PAPIST
19) SICILIAN
20) SWISS


Banners and pennants
--------------------

There are 2 other images that may be associated with a battlefield unit. A banner, carried by all units other than the generals unit, and a number of pennant images.

The banner and pennants are contained in one TGA file in the same foler as the flags above - 'Battle\Flags\Flags.tga'.

There is just 1 banner image, and 20 pennant images are contained in this file. However, the pennant images they represent just 1 pennant (think of them as 20 'frames' to represent the fluttering animation of the pennant). Therefore, both pennant and banner images are used for ALL factions.

The pennant is recoloured with the faction colour. The banner is also recoloured with the faction colour, after which the faction flag (FLAG10nn.TGA) is imaged onto the banner.

For, example try the following -

1) take a backup of FLAG1001.TGA, then delete the file FLAG1001.TGA
2) copy and paste FLAG1005.TGA then rename the copy FLAG1001.TGA
3) start a battle with the Almohad faction and take a look at both the banners and the generals flag on the units. They now carry the 'English' images.
4) do'nt forget to restore the backed-up copy of FLAG1001.TGA


So, can we change the images in Flags.tga? Yes, of course. However, bear in mind that any changes will be effective for ALL factions. You CANNOT give different factions different banner/pennant images.


CastleFlags
-----------

What about castles? Are these flags also used on castles? No. The flags that appear on castles (in the campaign game) are all held together in a 20 frame BIF file named -

- 'campmap\pieces\buildings\CastleFlags.bif'.

Each frame contains the flag image for a faction (20 factions, therefore 20 frames).

Can we change the flags? Of course. Just use BifReader 2.1 to "Extract All frames", amend the BMP file of the flag you wish to change, then rebuild the BIF via the "Import All frames" option.

(TIP: if you do these, ensure you rebuild rebuild the 20 frame BIF via "Import all frames" into the EXISTING CastleFlags.bif - DON'T try to re-create this file by importing the BMPs into a newly defined BIF. This is to ensure the colour mode remains as "FFFF" and not "7FFF" which is what you get if you create an entirely new BIF)


Note that in the same folder there are also 5 BUF files, pertaining to CASTLE, KEEP, CITIDAL, FORT, FORTRESS. These are NOT images, but rather are the subroutines required to build a CastleFlag on any of the 5 possible castle structures on the campaign map.


Colours on the battlefield
--------------------------

So how do we differentiate between shared specific-units on the battlefield?

The differentiation between shared specific-units (units that may be created by more than 1 faction) on the battlefield is determined by three things -

1) the faction colours superimposed on all specific-units
2) the banner colours held by such specific-units
3) the Nationality Flag held by the generals unit


(BTW: if you've read this far you probably know all this - but, for completeness ...)

[Wellington]

PART 14: New Units - Possibilities


This section is aimed at modders who wish to create new units. However, it does'nt discuss the steps required to create new specific-units (more of that later!). Rather, it discusses what is or is not feasable.


Possibilities
-------------

First, what is possible within the MTW animation system?


a) We CANNOT (at present) create new generic-units (new folders containing new BIF's plates) as MTW won't recognise the folders. This is quite understandable as such an option would allow the possibility for "outside parties" to "steal CA's thunder!".

b) We CAN change the combination of existing shields/weapons associated for a generic-unit to create a new specific-unit.

c) We CAN add new shields/weapons on the BIF frames (if room permits) and, after defining these new objects in weapons.txt/shields.txt, associate them with the generic-unit to create a new specific-unit.

d) We CAN, providing there is enough room on the BIF's, add/draw a new set of 4 images (for all 4 camera-angles) in order to represent another type of action for that generic unit - due to 'space constraints' this is generally only feasable for cavalry images.


Extreme possibilities!
----------------------

Can we do anything else ? Yes! We can do a few other things in order to create new specific units (if we're mad enough!).

For example, if we add an image for a helmet on a BIF and define it as a shield, by superimposing this object on the 'head' of the generic-unit figure-images (positioning this helmet image via the action-object-line definitions for shields - a lot of work involved here!) we can create a new specific unit with, say, a large viking helmet.

Another example. We could add one or more "feathered wing staff" images on a BIF, also define them as shields, and superimpose them on the 'back' of a cavalry figure. We then have Polish Winged Hussars! Again, an immense amount of work involved.

BTW if your not familiar with Polish Winged Hussars check the following links -
http://www.grenadier.f9.co.uk/iemins/polishhussar.jpg http://www.szlachta.org/obraz/husarz_balt.gif


Ok, the 2 images mentioned above probably would'nt look good on ALL figure images (due to problems inherent in the representatiojnm of such images for all 4 camera angles). More suitable examples would be objects that look simliar from all angles. For example the standard English/German Medieval 'pot' helmet. Check the helmet on the figures in the following links -
http://members.sia.net.au/dispater/humble_1400.JPG http://www.xenophongroup.com/montjoie/ribaud.gif http://www.xenophongroup.com/montjoie/hgunt-ts.gif

Obviously, such an helmet image would present far fewer problems, in terms of camera-angles, than would a Viking helmet with 2 horns!


Note that creating additional shields images for 'special purposes', such as the 2 mentioned above, would NOT lose the ability to equip such units with actual shields and weapons objects as any figure may have several shield and weapon objects in use/view at any one time (eg: PaviseCrossbows have 2 shields!).

We can also (if we want a lot of sleepless nights!) dispose of one of the generic-units, remove the specific-units represented from MTW altogether, and use the now 'available' generic-unit BIF's to redraw any unit images we want. NOT an option for the faint hearted !!


Existing 'unobvious' possibilities
----------------------------------

Is there any potential for creating and equipping a new unit (specific-unit) with different types of weapons that are not present on the BIF's - without having to add/draw new weapons images on the BIF's ?

In some cases, YES! For example, try the following 2 examples (don't forget to backup anything that is going to be amended) -


EXAMPLE 1

1) First take a look into the BIF 'Textures\Men\HlPlArSH.BIF' using BifReader 2.1. Have a good look at the four weapons in this BIF (2 swords, an axe and a handgun). The only weapon defined for the VarangianGuard specific unit is a large axe (weapon 3 in this generic folder).

2) Now open weapons.txt (in the 'HlPlArSh' folder) and add the parameters "151,243,179,244,3,1" on the next available line in this file - should be line 5. We've now defined a new weapon!

3) Open the VarangianGuard_W.txt file and change the '3' to a '5' (telling this unit to use our new weapon)

4) As we gave changed the weapon, we have to add some positioning parameters to this 'Weapon5' folder for this unit. Go to the folder 'Textures\Men\Items\Weapon5' and add a new folder 'VarangianGuard'

5) Now copy the 'stand' action file for spearmen (file 'Textures\Men\Items\Weapon6\Spearmen\stand.txt') to our new 'VarangianGuard' folder

6) We should now have created the file 'Textures\Men\Items\Weapon5\VarangianGuard\stand.txt' which defines the positioning of our new weapon (weapon number 5) for a 'stand' action. Now start a battle with a Byzantine VarangianGuard unit and look at the unit whilst it's standing. It should now have a spear.

7) Now move the unit, and pause the the battle. Can you understand why the unit no longer has a weapon?

8) Don't backout the changes yet!


So, we have created a new spear weapon for the generic-unit HlPlArSH. I'll leave the reader to work out how this has occured (if anyone really want's more details post to this thread and I'll explain).

A final point. If you require a pike as opposed to a spear, then try the following line in weapons.txt - "151,243,179,244,5,1".

EXAMPLE 2

1) We will use the same folder and unit as EXAMPLE 1 above. Open weapons.txt (in 'HlPlArSh') and replace line 5 with the parameters "236,241,285,252,2,3". We have now defined another weapon.

2) Open the VarangianGuard_W.txt file and change the '5' to '3,5'. We have now defined 2 weapons for this unit. The original axe and a new weapon.

3) Go to the folder 'Textures\Men\Items\Weapon5\VarangianGuard' which we defined in EXAMPLE 1, and edit the 'stand.txt' file. Note this file contains parameters pertaining to a spear type weapon, weapon 5 in weapons.txt, which we have now replaced. Therefore, we have create new parameters for our new weapon.

4) Delete all 48 lines in stand.txt and replace the lines as follows -

- replace EACH of the 1st 12 (lines 1 to 12) with "-9 -23 -8 -4 0"
- replace EACH of the 2nd 12 (lines 13 to 24) with "-1 -23 -1 -4 0"
- replace EACH of the 3rd 12 (lines 25 to 36) with "4 -21 4 -2 0"
- replace EACH of the 4th 12 (lines 37 to 48) with "4 -18 3 0 1"

MAKE SURE YOU HAVE 48 LINES IN THIS FILE!

5) Now start a battle with a Byzantine VarangianGuard unit and look at the axe weapon the unit now carries whilst standing.

6) Finally DO'NT forget to backout all changes we have made in these 2 examples.


Examples summary
----------------

So, what weapon was our VarangianGuard unit carrying in example 2? Can you see where it came from (how we really defined it)?

Is this really 1 weapon or 2 weapons? Does it matter? No! These are only images. If you wish to represent a single weapon with several images that is possible - providing you get the positioning parameters for such images correct!

However, is it really desirable to create new weapons as per example 2? No, for 2 reasons -

a) it's a lot easier creating another weapon in the BIF than playing about with weapons positioning parameters
b) it 'wastes' a weapons definition for this generic-unit folder (using 2 weapons definitions for just 1 weapon image)


Still, this PART is about POSSIBILITIES and not DESIRABILITIES, and the 2 examples above should have provided a little food for thought!


Future/potential possibilities
------------------------------

What about faction colours on specific units? Well, in theory, there is an option within the crusader_prod11.txt file that appears to allow the possibility to NOT replace the colours on the BIF figure-images with faction specific colours (ie: leave the colours as drawn on the BIF images exactly as they are). Unfortunately, from what I've attempted, it does'nt appear to work.

Obviously, the ability to create new generic-unit folders would open up the potential exponentially. This would give unit modders great flexability, in that any existing generic-unit folder could be copied to a new named folder and then the BIF images amended slightly, not really in respect of figure-image positions in the frames but more in terms of the images accompanying details (ie: amend/remove the plumes/sashes/helmets/colours slightly - whilst retaining the general 'outline' of the figure images to ensure the weapons/shield positioning files are kept in-sync) generic-unit folders would also increase the potential to add/draw new shield and weapons images for units by 'splitting' the contents of a current overloaded folder (eg: Peasants) over 2 or more folders.

Also, if we had the ability to add new Facshield folders for new specific-units, we could then create new specific-units, based on existing elite units (eg: Gendarmes), and could either dispense with the shield 'transfer' or draw a new one for our new 'elite' unit. Hence, we then have a new specific-unit (eg: Gendarmes2') that has a completely different shield transfer - or none at all.

If any of these were NOT hard-coded within MTW they would give tremendous potential in terms of adding new specific-units.


Summary
-------

In conclusion we can see that even without the ability to create new generic-units, the possibilities outlined above (and other possibilities that I've undoubtedly not thought of) provide a plethora of potential for the creation of new specific units.

Ok, enough of possibilities. Let's move on to other important considerations when attempting to create a new specific-unit.

[Wellington]

Next 2 PARTs will be posted in the next 3/4 days.

[Axelthorpe]

Hi

I have a few plans for my 17th/18th-century units, especially the pikemen (even thou they weren't were usual), and I wonder if this is possible.

1. Walks whit their pikes strait up in the air (not forward, like it is now).
2. When they are idle, the front line should be kneeing, with their pikes pointed forward. The second row with pike forward, but standing. And the rest with their pikes up.
See my beautiful illustration:
http://m1.457.telia.com/~u45703849/bilder/pike.jpg
3.When they fight and charge they should use their swords instead of their pikes. This way it will look like they meet the charge with their pikes, but fights hand-to-hand fighting with their swords (just to get rid of the “pike-poking”).

[Lord Krazy]

Al,
the kneeling thing no:(

the rest yes:)



LK

[Axelthorpe]

Quote[/b] (Lord Krazy @ Nov. 08 2002,19:28)]Al,
the kneeling thing no:(

the rest yes:)



LK
That's to bad, but the Arquebusiers does this, why not the pikemen?
Just wondering

[Wellington]

Quote[/b] (Axelthorpe @ Nov. 09 2002,07:45)]
Quote[/b] (Lord Krazy @ Nov. 08 2002,19:28)]Al,
the kneeling thing no:(

the rest yes:)



LK
That's to bad, but the Arquebusiers does this, why not the pikemen?
Just wondering
The Pikemen can't perform a "kneeling action" if they have no missile weapon defined for them. There are 2 kneeling actions defined in MTW -

- kneeling_shoot
- kneeling_reload

If you really wanted to see your pikemen kneeling with a pike therfe are 2 ways to do it -

1) you would have to -

- define a missile weapon for pikemen in Prod11
- change the action and positioning parameters for the unit to ensure the pike weapon is displayed for kneeling actions
- ignore the fact that on the battlefield the MTW Engine would expect your "kneeling pikemen" to be actually firing some missile weapon

2) change the image-recatangles in the units ActionsPage definition to perform a kneeling action for some other action (eg: use the kneeling image-rectangles for 'stand' or 'fight' actions - again it requires weapon positioning to cater for a pike weapon in the hands of the kneeling unit)


Basically it CAN be done in terms of imaging/animation, but the MTW engine would only concern itself with the action being perfomed (as defined in the ActionsPage)irregardless of the Images/Animation that you chose to associate with that action.

Hhhmm ... hope that makes sense

[Axelthorpe]

Ok, no it's too much work for so little, I think I skip it and try to do the other things properly instead.

[Axelthorpe]

And if anyone cares, I've re-done my model:
http://m1.457.telia.com/~u45703849/Karo_v2.jpg

With 3d-adds like; collar, belt, arm lining and shoulder straps and I've added an ammo bag (with 3d strap), waistcoat and sword sheath.

[Lord Krazy]

Quote[/b] (Wellington @ Nov. 09 2002,12:32)]
Quote[/b] (Axelthorpe @ Nov. 09 2002,07:45)]
Quote[/b] (Lord Krazy @ Nov. 08 2002,19:28)]Al,
the kneeling thing no:(

the rest yes:)



LK
That's to bad, but the Arquebusiers does this, why not the pikemen?
Just wondering
The Pikemen can't perform a "kneeling action" if they have no missile weapon defined for them. There are 2 kneeling actions defined in MTW -

- kneeling_shoot
- kneeling_reload

If you really wanted to see your pikemen kneeling with a pike therfe are 2 ways to do it -

1) you would have to -

- define a missile weapon for pikemen in Prod11
- change the action and positioning parameters for the unit to ensure the pike weapon is displayed for kneeling actions
- ignore the fact that on the battlefield the MTW Engine would expect your "kneeling pikemen" to be actually firing some missile weapon

2) change the image-recatangles in the units ActionsPage definition to perform a kneeling action for some other action (eg: use the kneeling image-rectangles for 'stand' or 'fight' actions - again it requires weapon positioning to cater for a pike weapon in the hands of the kneeling unit)


Basically it CAN be done in terms of imaging/animation, but the MTW engine would only concern itself with the action being perfomed (as defined in the ActionsPage)irregardless of the Images/Animation that you chose to associate with that action.

Hhhmm ... hope that makes sense
On point 1 :

You also want to make sure you that
you change the default behaviour such as skirmish
as this would not be much good for pikemen.

On point 2:

Do you mean that because pike fight with
the first four rows that when they fight
you can't get the first row to do same thing
as the second row unless it's a shoot action
SEE ,I can be more vauge than you http://www.totalwar.org/forum/non-cgi/emoticons/tongue.gif

I should qualify my last no answere
to yes kind of but even this would
would confuse Welly never mind me.
LK;)

[Whitey]

this thread is 'the works' as far as these things go - some of it I knew, a good deal of it I didn't. I can't wait for the rest, and I am sure that others can't either.

[Wellington]

LK,

First congrats on your new 'status' as not only a modder but also a moderator A two-edged sword I suspect Minf you, I'll watch my 'p's and 'q's in future http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif

point 1 - true
point 2 - what I was trying to say was that IF you choose a generic BIF with kneeling images, and IF you define a new unit with a pike for this generic BIF then you can always associate the kneeling actions with any action defined that this bnew unit in the ActionsPage definition.

It does'nt matter if the 'stand' action is "normally" associated with BIF images that don't move - if you wish to define image rectangles depicting a running image with the 'stand' action then that's ok. The MTW engine will NOT move your unit as IT understand they are standing. The 'run' images, however, that you have associated with the 'stand' action will still be displayed. Hence, they will appear to run on the spot

Likewise, if you want to associate a unit (that does have kneeling images defined in the BIF) with a kneeling position for a 'stand' or 'fight' (or any other&#33http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif action, as defines int ActionsPage definition for that unit, you can do so. What you CAN'T do is control the manner in which the MTW engine uses your unit which depends on the action MTW considers that unit (or certain figures in that unit) are performing at any one time on the battlefield.

MTW will force your unit to perform some actions - regardless of the image-rectangles you chose to associate with that action.

Is that clearer After reading it again I can confirm it probably is'nt - sigh Such is life.

[Wellington]

WHitey,

Thanks for the feedback. The next PARTS are coming shortly - I promise. It's just a matter of finding the time to finish off the next 2 PARTS properly (I think the next 2 parts are probably the most important for modders as they are the parts pertaining to object and figure positioning - which is a bit of a pain).

Also as I'm learning other things as I go along I'm constantly adding, bit's and pieces to PARTS to ensure we have a "correct" guide for downloading when I actually manage to finish this

A bit slow coming, I know, but polease bear with me.

[Fearless]

Hi Wellington any chance of producing all your documentation in one hit to avoid all the editing of replies.

Thanks

[Fearless]

Let's keep this topic at the top it's important.

[Lord Krazy]

Fearless,
I think Welly is writing this as he confirms
it to a certain extent.It's kind of a running
commentry.This will be edited and compiled
when it's finished but in the mean time
I think it's best this way.
The different aspects that are been
covered here are not documented
so the quicker people can read and digest
it the quicker they can get up to
spec and join in.

Or do you just mean the non relevent posts
LK http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

[Fearless]

non relevent posts LK
http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

[Lord Krazy]

Here's another one http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif

I'll be removing all non relevent post
soon.Like this one http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

[Wellington]

Guys,

This thread was intended to allow ALL modders to offer advice/information in this "unit modding" area - read my 1st post in this thread. I am certainly NOT the "be all and end all" of this. I, personally, am only offering contributions to this thread as I "go along" and as I learn other things - as LK quite rightly pointed out in the previous post.

There are many contributers to this Modding forum who have some knowledge pertaining to unit modding/animations. I am only one such. I would welcome any offerings to this thread from other individuals.

OK. I am NOT a CA employee. I don't really know how some things work, as I don't have access to the MTW source code. I can only play around, in a trial and error mode, and observe the results of my "playing around". My conclusions may be true or they may be false It all depends on how much "playing around" I choose to perform in certain areas.

Some things become obvious, other's remain less obvious. I post PART's to this thread when, AND ONLY WHEN, I think I'm right - "think" being the operative word. Even now I'm still changing/correcting/re-wording PARTS (on my PC copy of my contributions to this thread) that I previously posted in this thread.

The whole intention of this thread was to provide information that could form the basis of a "Guide to Animations" that could be downloadable from The Org.

I understand some people are awaiting further details but, in the absence of any other contributions, they will just have to wait. I'm also learning things as I go along ... and I won't post another PART until I feel I have ascertained sufficient content to justify posting such info.

I have many paragraph's for the last 6 PART's already written but am still working on other issues pertaining to these PART's.

The content of such PART's, as far as I'm concerned, should offer both -

- a consistent and logical document for "newbies"
- varied/new content/ideas for "established modders"

In other words, I will post more PARTS's when, and only when, I am happy with them (and even then they may be subject to change&#33http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif.

Sorry ... but that's the way it goes.

regards,
Wellington

[Lord Krazy]

Welly,
I think there is enough here to keep
new commers happy for a while.
As for people who comprehend this already
they should get on with implementing
some of this stuff.
Until then I think this thread
will not need new imput.
Not to say it wont welcome it as is your
style and ours, but having implemented
everything here I know what it takes.

So no need to feel sorry
like you said ,your not CA,
but you and the other modders who are
writing ,or have writen manuals on this forum
are the next best thing http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
You wouldn't catch me doing it,
it's too hard http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

regards,
LK http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

[fenir]

Wellington, Please don't stop.

We missing some parts http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif



fenir

Hmmm 50 A4 pages of reading material.

[fenir]

never mind it's ok I found it http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif

it was in part 5. http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif

fenir

[WesW]

Hi guys. One thing I noticed. In the textures/men/items section, the 0 or 1 setting is different than what I remembered from the thread here. 0 means that the item will be placed before the man, and 1 means that it will be rendered after, or over, the man.
This may be exactly what you said, but I remembered it being the reverse, so I just thought I would mention it here.

[Wellington]

Hi WesW,

That may well be the case. Maybe I got the 0/1 parameters mixed up in the original post. Does'nt really matter - at least people know the purpose of that parameter now

I'm well aware that some aspects of my contributions to this thread may not be 100% correct. It does'nt matter too much (IMHO). Anyone interested in "Unit Modding" will be able to glean sufficient information from the contents and will quickly realise the occasional mistakes/typo's I've made.

Obviously, anyone who has ever attempted documenting their thoughts/opinions/knowledge (in any "area") to such an extent that I have attempted in this thread would be aware that such mistakes are inevitable.

I do have a different version of this writeup (on my PC) that is a little bit different to the content offered in this thread. Fenir has very graciously offered to writeup this "definitive version" as and when I finish it - and my apologies to Fenir for my being a bit slow in this respect.

The final version WILL be finished. It will be a little different to my content in this thread. It will incorporate ideas/thoughts/corrections/additions that I've gleaned since writing up some of these PARTS. It will include bit's I overlooked (that I've made aware of in other post's/threads subsequent to my writeup of these PART's). It will be as complete as I can make it. It will be downloadable from The Org. It will also most probably, alas ... sigh, also contain mistakes

Such is life WesW

[fenir]

Np wellington,
take your time, it's xmas after all. Well new years eve here now http://www.totalwar.org/forum/non-cgi/emoticons/tongue.gif

fenir http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[kataphraktoi]

Does anyone know how to make a Kataphraktoi shoot a bow and melee?

[Lord Krazy]

Kataphraktoi
I don't think it would be possible
in real life and impossilbe in the game.
How could you fire a bow and melee at the same time.
You would need three hands and maybe two heads.
Is this for a Jason and the Arganots mod.

I may have misunderstood but I could not resist http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

To be honest I'm not sure what you want exactly http://www.totalwar.org/forum/non-cgi/emoticons/confused.gif

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Lord Krazy]

Welly,
I,v added the shogun units
and the spear for the ashi is on the edge of the bif
and it shows in the game like a giant pencil
it's annoying while being funny http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
while in shogun it looks fine.
Why is this?

regards,

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Wellington]

Quote[/b] (Lord Krazy @ Feb. 03 2003,04:45)]Welly,
I,v added the shogun units
and the spear for the ashi is on the edge of the bif
and it shows in the game like a giant pencil
it's annoying while being funny http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
while in shogun it looks fine.
Why is this?

regards,

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif
No idea LK http://www.totalwar.org/forum/non-cgi/emoticons/confused.gif

E-mail me the Ashi stuff and I'll test it and try to puzzle out what's going wrong.

At a quick guess I'd suspect the last 2 numbers in the Weapons.txt may be wrong

Welly

[Lord Krazy]

Thats why I tried many combinations.
I could get the last number to take effect for the length.
The first number as 1, 2 or 3 still kept the same width.
I thought weapons coords might be doing it
so I gave them another it changed position but not width http://www.totalwar.org/forum/non-cgi/emoticons/confused.gif It's in the
test_LK_Shogun_mtw_units_v2

I'll send it later if can't download it http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif

Thanks

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Lord Krazy]

LBA has reminded that barocca may have mentioned this
before.Maybe he knows why?
It may have something to do with the image
being on the edge of the bif and the shading
but that's just conjecture.

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Lord Krazy]

BTW Welly,

I got the pistol to show when they shoot.
Well I didn't the computer did http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
I used the other shoot images in the bif.
I am sure beyond doubt that is what they are for.
As to why CA did not use them
I just don't know http://www.totalwar.org/forum/non-cgi/emoticons/confused.gif
I made the gun extra big to make sure I could
see what was happening.
I can only see it from the front
but it's a start.
They also point the wrong way http://www.totalwar.org/forum/non-cgi/emoticons/rolleyes.gif

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Wellington]

LK,

The Shogun unit Ashiguru weapon is too thick. It's 6 pixels which is not consistent with the width of similar weapons in MTW.

For Shogun CA started off drawing all weapons on the figure images in the BIF's. This was fine for swords/muskets but they (presumably) hit a problem with long weapons - spears and such like - in that they had no room in the BIF's to represent the image recatangles required for all images/actions/camera-angles with such a large weapon.

Therefore, for Shogun, CA incorporated a quick 'system' in the engine to position some weapons on the images prior to rendering the figure image on the terrain.

For MTW CA extended this system to incorporate all weapons for all units, and for shields as well. This had the added advantage of allowing the MTW 'mix and match' for different units. Ok, some units still have weapons drawn on (archers) but this is NOT a throwback to shogun. It's just symtomatic of the fact that a bow is difficult/complicated to represent using either the weapon or shield positioning systems in MTW.

Therefore the Shogun engine method of positioning (and scaling&#33http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif weapons is totally different to the MTW system.

For the Ashi's in MTW redefine the image-rectangle to be half the size (3 or 4 pixels thick). Either half it or skip the 1st and last lines of pixels. The MTW engine should be then be able to cope with this correctly, and it should look more realistic in MTW.

Welly

[Wellington]

Quote[/b] (Lord Krazy @ Feb. 04 2003,17:10)]BTW Welly,

I got the pistol to show when they shoot.
Well I didn't the computer did http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
I used the other shoot images in the bif.
I am sure beyond doubt that is what they are for.
As to why CA did not use them
I just don't know http://www.totalwar.org/forum/non-cgi/emoticons/confused.gif
I made the gun extra big to make sure I could
see what was happening.
I can only see it from the front
but it's a start.
They also point the wrong way http://www.totalwar.org/forum/non-cgi/emoticons/rolleyes.gif

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif
Hhmmm .. this says something. However, what exactly it says I'm not quite sure

It would be really nice to have the finished mounted muskets/carbines and pistoliers and have them working correctly.

Once LMM4v1 is released I want to get back into this area to resolve some of the outstanding problems. At present I have a 'list' of priorities -

1) The Lords Roman units
2) Mounted guns (muskets)
3) Mounted guns (pistoliers) - very different to 2)
4) musket rests for infantry

The 2 slinger units I was trying to crack are just too difficult. Pity. I really wanted to incorporate these in MTW as they would have been 'completely different' to any other unit. Problem is it takes too long to change the shield positioning numbers and as the slings are relatively thin it's very difficult to visualise the effect of any changes you've made to those positioning parameters.

I tried to automate some of the processes involved in weapon/shield positioning via software (remember MUMU&#33http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif. The results were not good. The idea in MUMU was to produce a table of xy-coordinates for the right and left hands of EVERY image in every frame. Then MUMU could position new weapons/shields relative to any units hand position. Problem was twofold -

1) producing an accurate table of hand positions was a nightmare
2) knowing the hand positions did'nt necessary solve all of the inherent positioning problems
3) the positioning of weapons was only partially successful for a few images in a few frames - shields screwed up big time.

Anyways, LK. Let me know what your priorities are for your new units and I'll get back to this ASAP.

Welly

[Lord Krazy]

Quote[/b] (Wellington @ Feb. 04 2003,17:26)]For the Ashi's in MTW redefine the image-rectangle to be half the size (3 or 4 pixels thick). Either half it or skip the 1st and last lines of pixels. The MTW engine should be then be able to cope with this correctly, and it should look more realistic in MTW.
In theory only http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif
I'v tried all that malarchy before I asked you.
It still looks like a big pencil that's why I'm confused
I'v tried all possible combinations of coords
all lines, top line, bottom line, middle line,
two lines, so far no lines works best http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

These peasants have no respect http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

In the closet for while I think with these guys.

Thanks for the confirmation and information http://www.totalwar.org/forum/non-cgi/emoticons/pat.gif

LK http://www.totalwar.org/forum/non-cgi/emoticons/smokin.gif

[Hendon]

Whats the best Bif reader if you want to make units of your own????




/ME http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

[Wellington]

Quote[/b] (Hendon @ Mar. 04 2003,04:07)]Whats the best Bif reader if you want to make units of your own????




/ME http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif
The latest version - 2.2a?

[MR EGG]

Hello Wellington I'm on the scrounge,would it be ok if I use your sheild and weapon placing tool http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif if this is ok I would be greatfull . could you please send it to issywhizzy@aol.com if its ok, thanks.just one more thing I want to make a defence action against cavalry etc for my ECW pikemen, how would this be achieved. http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif

[Wellington]

Quote[/b] (MR EGG @ Mar. 23 2003,20:59)]Hello Wellington I'm on the scrounge,would it be ok if I use your sheild and weapon placing tool http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif if this is ok I would be greatfull . could you please send it to issywhizzy@aol.com if its ok, thanks.just one more thing I want to make a defence action against cavalry etc for my ECW pikemen, how would this be achieved. http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif
No probs I'll send it you. One thing it ISN'T a weapon positioner - only for shields.

Whilst it's a lot harder to position shields (as opposed to weapons) by hand - the opposite is true if you have a program to automate it. The reason being for weapons you have to positions EXACTLY corrrect, for shields you have a bit of leeway 9don't have to be pixel-perfect)


You can't add new actions (and you won't be able to in VI either). However, theres no need. If you unit is attcked by cavalry they will automatically change action to defend themselves (eg - from 'stand' to 'fight&#39http://www.totalwar.org/forum/non-cgi/emoticons/wink.gif. Therefor there is a "defend" action built in to MTW - but we just see it as a fight action.

For example, when troops are routing and being chased individual figures sometimes stop and fight (and on occasion win). Is'nt this a "defend" action

Welly

[MR EGG]

Thanks Wellington I thought this might not be possible

[Baron von Beer]

me too me too... http://www.totalwar.org/forum/non-cgi/emoticons/biggrin.gif

pgrasham@charter.net

[RabidMonkey]

This is a fantastic thread All hail Wellington, and i hate to think how long it took to write it all up http://www.totalwar.org/forum/non-cgi/emoticons/tongue.gif

When will more be added as it seems a while since this thread was last updated? (I am NOT complaining because theres no point posting something that isnt finished, i just want to see more of the guide http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif )

[Wellington]

Quote[/b] (RabidMonkey @ April 30 2003,05:52)]This is a fantastic thread All hail Wellington, and i hate to think how long it took to write it all up http://www.totalwar.org/forum/non-cgi/emoticons/tongue.gif

When will more be added as it seems a while since this thread was last updated? (I am NOT complaining because theres no point posting something that isnt finished, i just want to see more of the guide http://www.totalwar.org/forum/non-cgi/emoticons/smile.gif )
Many thanks for your appreciative comments.

Unfortunately, whilst I have several half-completed additional PARTS on my hard drive (awaiting completion), I doubt whether any of these additional parts will be completed and posted in full in the near future.

The reason being there are many individuals who can now contribute to this area of MTW modding (LK, The Lords) who thoroughly understand the possibilities and implications - therefore this "area" of MTW modding is generally well covered by modders.

Ok, I appreciate that's of little consideration to new modders but the fact is that "Unit Modding" is generally well known now (albeit complicated somewhat with the addition of VI) and since writing this thread I moved on to areas that were less well understood.

However, if you have any specific questions/queries re- Unit modding for either MTW or VI please post them in this thread and either I or others will try to elucidate the area of confusion.

One final point - the info in this thread pertains to MTW only - NOT VI Therefore, if you have questions please indicate whether you are refering to MTW or the VI expansion.

[Duke John]

Since I made the completely new Uruk-Hai unit I discovered some things.

On the subject of the different camera angles. There are 8 angles, meaning 360/8=45 degrees difference per angle. Since there's no direct front angle and the angles are all mirrored, you can conclude for the semi-front angle: 45/2=22 degrees (since it's mirrored). This will get you the following angles for making new unit animations: 22, 67, 112 and 157 degrees.

About the x/y origin that are stated in the first two numbers per line per action in ActionPage\unitname.txt. They should have the value of the difference between the x,y coordinates of the image rectangle and the x,y coordinates of the bottom left of your model most of the time his right foot).

I hope I'm clear http://www.totalwar.org/forum/non-cgi/emoticons/wacko.gif

[Wellington]

Quote[/b] (Duke John @ May 20 2003,05:57)]
On the subject of the different camera angles. There are 8 angles, meaning 360/8=45 degrees difference per angle. Since there's no direct front angle and the angles are all mirrored, you can conclude for the semi-front angle: 45/2=22 degrees (since it's mirrored). This will get you the following angles for making new unit animations: 22, 67, 112 and 157 degrees.


Quite true I messed up the maths when starting this thread DJ's angles are far more correct.


About the x/y origin that are stated in the first two numbers per line per action in ActionPage\unitname.txt. They should have the value of the difference between the x,y coordinates of the image rectangle and the x,y coordinates of the bottom left of your model most of the time his right foot).

Er ... not true

The x/y origins are (IMHO) an arbitary value that represent a specific point that is useful for the rendering of other shapes/images that are relative to thge x/y origin of the orignal image

For example -

a) x/y origins for infantry are based on the positinng of shields and weapons.
b) x/y origins for cavalrymen are based on the positioning of the saddle area on the mount.
c) x/y origins for mounts are based on the relative proportion (between the mounts saddle area and the ground) between the mount and the terrain surface.

Believe me - it's true

If you require further examples (over and above those in this writeup) - let me know

[Duke John]

Let's first make clear that we both talk about the same. I mean the first 2 numbers in the lines concerning image rectangles that are under the different actions.

When I first edited those lines I had for example:
Stand
10 10 200 100 300 200
Where 10 10 is the x/y origin (or not if I misunderstood you)
This led to my Uruk-Hai legs disappearing into the ground if zoomed out enough. I concluded from this that my x/y was around the middle of the model where it should have been at his feet. So I changed it to:
Stand
10 40 200 100 300 200
Now the x/y was lower, namely at the Uruk-Hai feet and I had no further problems with the unit disappearing into the ground.

Note: if my explanation of x/y origin is different than yours than replace all the x/y origin with "x/y basepoint".

Edit: I looked up "arbitary" (can't we just speak dutch http://www.totalwar.org/forum/non-cgi/emoticons/rolleyes.gif ). And no it isn't. As I said it does make a difference on positioning the unit.
Consider this: the image rectangles for angle 112 may be very wide or high because of extended arms or weapons. But for angle 157 the image rectangle is pretty small. To avoid having the unit jump from one position to another when it changes angle MTW uses the x/y coordinates. This way the central axis of the model stays at the same point.

If I haven't made myself clear enough, I'll add pictures.

Further edit: I don't argue about your points considering positioning items or horses. Only that x/y coordinates is also used for holding the unit in the same place while the image rectangles changes in size in the animationcyclus.

[dclare4]

Is there any way to fast track those 12 pages of animation? I've been drawing over the originals and its taking forever to get even one figure done.

Lord de Clare