MCG SPRITES extracted addon - Modding MechCommander

Visit EveryThingBattleTech forums for more modding information.

Bestia_Infernali, 2014 on NoGutsNoGalaxy boards:

INTRODUCTION

Objects sprite data PAKs contain object type PAKs, where each PAK contains object type sprites. It looks like this:

- OBJECTS_DATA.PAK --> OBJECT_TYPE.PAK --> OBJECT_TYPE sprites.

- CHASSIS_PART_DATA.PAK --> CHASSIS_PART_TYPE.PAK --> CHASSIS_PART_TYPE sprites.

Most of PAKs inside of SHAPES.PAK is simply empty (70-80% perhaps?). The reason behind trucktons of empty PAKs probably is: they're place-holders to keep the proper file order beacuse this is what game is looking for (see "Vehicle logic" below).

OBJECT_TYPE.PAK/CHASSIS_PART_TYPE.PAK contains one SHP per frame - it can be even > 700 files (empty ones too). Striker has 96 SHPs.

Non-objects sprite data PAKs like FEET.PAK don't have sub-PAKs, and have multiple-frame SHPs. The same goes for SHPs from SHAPES.FST (like smokes).

WHERE, WHAT

There's no sign of "where are you looking for the sprite?" in SPRITES.PAK, except Mechs:

Code:ul legFileNumber=18
ul torsoFileNumber=23
ul rightArmFileNumber=23
ul leftArmFileNumber=23
above must refer to file number in PAKs. There are 24 files in both torsos PAKs (first is 0, last is 23).

For non-Mechs you must look OBJECT2.PAK for:

Code:l Appearance = 0x05000031 // Striker
l Appearance = 0x05000175 // Artillery
(to get the file number in PAK you must change hex to dec: 31 = 49, 175 = 373).

Logic must looks like this then:

Mech: OBJECT2.PAK --> SPRITES.PAK --> CHASSIS_PART_DATA.PAKs.

Vehicle: OBJECT2.PAK --> SPRITES.PAK == SHAPES.PAK.

--> (reference to file number in PAK),
== (file number is the same in both PAKs).

SHAPES90.PAK contains buildings for sure. Other types are stored either in SHAPES.PAK or SHAPES90.PAK. The logic is probably the same as in case of Vehicles.


EDITING

It's possible to open/edit(?) SHP that starts with 1.10 in its header and that means:

- buildings,
- vehicles,
- feet,
- smokes,
- and some other stuff.

Mech SHPs are different - they have 1.10 too, but don't start with it - must be some modified version thus it's not possible to open it. I have no idea what files inside of MCG\DATA\TILES\*.PAK are - they don't look like PAKs, they don't look like SHPs. For example, result of unpaking TILES.PAK was 1100 empty files (1100 is max in batch I'm using).

NOTE: I know nothing about file format crackery, and probably I don't know what I'm talking about

Also, I have no idea how masking (for paint schemes) is handled, or how the game knows which frame is turret, destroyed shape, shadow to draw under building, etc.


TOOLS

Looks like there's a C++ source code for ShpEd (CTRL+F the "ShpEdSrc"). You can download binary too (just above the source).

If someone wants to fiddle around Mech's SHPs, or MC's sprites generally, I attached samples:

- \logistics.pal (load it into ShpEd),
- \SHAPES.PAK\0049.PAK\Striker,
- \SHAPES.PAK\0373.PAK\Artillery,
- \TORSOS.PAK\0001.PAK\?,
- \TILES90.PAK\?.

Quote from: Bestia Infernali on February 17, 2014, 10:32:57 AM

bbc_standard_quote wrote:

Mech SHPs are different - they have 1.10 too, but don't start with it - must be some modified version thus it's not possible to open it. I have no idea what files inside of MCG\DATA\TILES\*.PAK are - they don't look like PAKs, they don't look like SHPs. For example, result of unpaking TILES.PAK was 1100 empty files (1100 is max in batch I'm using).

I´ve have success extracting mech SHP. They are just modified shp. i don´t know why the difference but if you delete the first 6 bytes (to let the first data to have on the file to be 1.10) shped opens them just fine.



Huchback maybe??

I´m trying to compile SHPed to ignore those 6 bytes but no luck so far. It has some borland compiler dependencies.

I´m very happy i tried to find a way to extract those mech sprites for years..


BTW: i don´t know if it´s because of the palette but those striker from SHAPES looks way better than the torso of the mech you uploaded

Bestia_Infernali:

I took palette from screenshot (during mission) and then saved it into format ShpEd understands. Used IrfanView for this. IIRC palette(s) that are used by game are binary or something.

Some things can be messed up since ShpEd is designed to handle Panzer General SHPs. Opening MC's equivalent is kinda additional feature developer of ShpEd probably didn't even know about. Until someone will write specific tool for MC's SHP you must use this workaround.

As for the image with Tie Fighter: I think I've seen it in game files (misc.fst\data\palette\palettex.gif). Note Mech that wasn't included in final version of the game.

Also, nice that you figured out that "6 bytes" problem.

IronArthur:

Mmmm

I don't think ShpEd or ShpSym (newer program version that can extract every image in a shp, Wargamer.com) extracts MC shp files with error or something.

Shapes shp( striker) looks just fine but the main problem with mech it's palettes and quality/detail. Maybe the first it's source to the second problem.

I've tried Irfanview but how do you know the correct order of color lines (rgb) ?.

In MCG extracted data/palette files, most of them are binary and some other just FITini files.

i´ll look on Mech Index files if there is a clue for any of this.

Nice find on the sprites. I wish I had the time to work on some of this (I've literally had about 4-5 hours work done on trying to merge the original and expansion campaigns in the last few months).

Anyway, on the subject of palettes, it all depends on the type of palette data is being stored (and how it is used) since there is no real standard for color palettes.

First is to attempt to identify the palette type by looking at the size of the data. If it is divisible by 3, then it is likely independent RGB channel data (24 bit), if divisible by 2, then likely it is 16bit (which opens a whole new can of worms). Since palettes typically have 256 colors in them, this means that if the palette is 768 bytes long, it is 24bit, if 512 bytes long then it is 16 bit.

Assuming it has independent RGB channels, the order is most likely R, G, then B. If the colors come out wrong, then try B, G, R. Another potential problem is to look at the actual data bytes to see what the value range is. If values above 63 are present, then it is full RGB. If no values above 63 are present, then it is a VGA palette. VGA cards can only accept values from 0 to 63 (6 bits) on each channel, so you may need to rescale the values if trying to convert it to some other format.

If it is 16 bit palette data, well I'll explain that if needed.

IronArthur:

Seems 24bit
HB.PAL 772 bytes

I have jumped the first 4 bytes and take 1byte as R 1 byte as G 1byte as B, 256 times:
Code:63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 63 0
0 63 0
0 0 63
0 15 0
0 25 0
0 41 0
0 0 0
4 4 4
8 8 8
12 12 1
16 16 1
20 20 2
25 25 2
29 29 2
33 33 3
37 37 3
42 42 4
46 46 4
50 50 5
55 55 5
59 59 5
63 63 6
0 5 7
7 11 13
15 18 2
23 25 2
29 30 3
36 36 3
42 41 4
49 47 4
3 0 0
9 5 4
15 10 8
22 16 1
27 21 1
33 26 2
39 31 2
45 36 2
2 1 1
4 3 3
7 6 6
10 9 9
12 11 1
15 14 1
18 17 1
21 20 1
9 7 5
16 7 5
23 7 5
31 8 6
37 10 6
43 12 7
49 14 8
58 23 1
6 3 0
12 7 3
18 11 6
24 15 9
32 19 1
40 24 1
48 29 1
57 34 1
10 5 0
17 12 5
24 19 1
32 26 1
39 33 2
47 40 2
54 47 3
62 55 3
1 1 2
2 3 6
3 6 10
4 9 15
6 11 18
9 14 22
12 17 2
15 20 3
6 10 12
11 15 1
16 20 2
21 26 3
26 31 3
31 37 4
36 42 4
42 48 5
1 3 0
1 5 0
2 7 1
3 9 1
4 11 2
4 13 2
5 15 3
6 17 3
7 19 4
8 22 5
10 22 6
13 23 8
15 24 1
18 25 1
20 26 1
23 27 1
3 5 1
4 6 1
5 8 2
7 9 3
8 11 4
10 12 5
11 14 6
13 15 7
14 17 8
16 18 9
17 20 1
19 21 1
20 23 1
22 25 1
24 30 1
29 38 2
9 9 5
11 11 7
14 13 9
17 15 1
18 16 1
19 17 1
20 18 1
21 19 1
22 20 1
23 21 1
24 22 1
25 24 2
27 26 2
29 27 2
31 28 2
34 29 2
10 5 0
11 6 0
13 7 1
14 9 2
16 10 3
17 12 4
19 13 5
21 14 6
22 16 7
24 17 8
25 19 9
27 20 1
29 22 1
30 23 1
32 25 1
34 27 1
63 61 5
63 63 4
63 60 5
63 63 3
63 59 5
63 55 4
62 55 3
63 56 2
63 51 3
63 48 2
61 47 2
56 48 3
63 40 1
56 41 2
63 32 3
45 41 3
44 35 2
49 32 1
46 26 1
37 25 1
39 23 1
38 18 8
62 25 1
63 20 2
63 19 1
43 43 1
39 34 2
37 33 3
33 33 1
29 27 2
29 20 1
21 21 1
18 19 1
20 15 9
17 16 8
15 15 1
14 14 1
16 9 8
14 9 7
10 10 9
10 10 7
8 10 10
9 9 8
13 6 4
6 7 6
25 12 7
59 0 0
63 0 0
48 45 3
39 37 3
50 50 3
63 60 6
63 37 4
54 0 0
26 45 5
17 29 3
6 10 12
11 15 1
16 20 2
21 26 3
26 31 3
31 37 4
36 42 4
42 48 5
60 63 6
28 55 2
0 38 0
31 53 5
0 45 56
0 14 31
0 12 15
0 22 22
0 31 27
0 41 33
0 51 38
63 35 0
39 39 6
26 0 0
42 0 0
51 0 0
17 19 0
31 33 0
57 61 0
23 8 0
34 21 0
61 29 0
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
63 0 63
I´ve tried to make some shp to bmp with those palettes but i don´t think they are like that, they show mostly black.

The data seems good, though the values need to be scaled up since they are VGA values (all 63 or less).

For a quick and dirty scale up (inaccurate though), try mulitplying each value by 4. For a bit better conversion, try something like scaledvalue = (bytevalue * 255) / 63.

As for the sprite images themselves, they are likely not be refering to specific palette entries but merely giving color codes (I suspect this is the case, since the mechs and vehicles can have the color changed depeding on which side they are on and/or multiplayer mech colorings).

Lets say a sprite can have 8 colors with the following breakdown (this is just demonsrating the concept, I have not really looked at the sprite data).
0 = no pixel/transparent
1 = main color
2 = main color (in shadow)
3 = main color (lit)
4 = secondary color
5 = secondary color (in shadow)
6 = secondary color (lit)
7 = tertiary color (lets say black for outlining)

So all you could really do is map the colors manually to something on the palette and try to identify what image value is associated with what.

Given this information, new sprites could then be created (if a tool was made to convert things). In this case you would generate your new sprite(s) in a drawing/painting program (Paintshop, Gimp, etc) by using specific colors then the tools would generate the required sprite data by converting each color in the new sprite image to the appropriate sprite values needed.

Oh yeah, if you compare the RGB values you show with the color palette I show in my Creating New Mechwarriors guide and/or by loading one of the logistic map files in a paint program, you will see that they match up nicely. So the order appear good.

IronArthur:

I´ve scaled up the values from palette and extracted a MadCatTorso and the results are very similar to logistic.pal that Bestia Infernali uploaded on first post.

So the question now is:

• To figure what´s the process MCX is doing on painting a Sprite that results on a very detailed sprite like this Media.moddb.com
• Define the specification of a SHP-Mech file.

I´m trying to focus on the second thing that it´s just analyze the code from SHPed or SHPSym. Probably debuging the files we will get some clues to solve the first issue.

On the first issue the point is to figure where the paintSchemes are located.
Every Mechwarrior has scheme defined but who knows where are located. On Data/palette are some *.tbl files (ALLFADE.TBL) that probably are some fade tables for transparencies or something like that.

Code:// -------------------------------------------------------------------------
//
// MechWarrior: 3 Name: Frank Savage Callsign: MASTER
//
// Creation Date: 12/15/98 By: jon marcus
//
// -------------------------------------------------------------------------



[General]
st Name = "Frank Savage"
l Rank = 0
st Callsign = "MASTER"
ul ID = 3
l NameIndex = 1000
l DescIndex =
ul HeadIcon = 1000
l paintScheme = 17
st pilotAudio = "pilotd"
st pilotVideo = "plt1t001"
st Picture = "pilot00.TGA"

On MCG editor is there an option to load a pal file? i can´t install it because i´m on a Win7x64 and i use a compressed installation of MCG.

Edit: i´ve found another SHP tool Luis-guzman.com no source this time :/

Edit2: SHP Specification Luis-guzman.com(SHP) file

Bestia_Infernali:

I wonder if unique ground shadows for Mechs are present among trucktons of SHPs they made...


In game there's fugly looking "dot", the same for all Mechs (unless these gifs are done by someone other than devs).

btw, in alpha/beta/whatever version there are no unique shadows too, and "dot" seems to be larger:



Note something that looks like weapon placement that is present in UI (utterly broken/non-existent in final game), as well as heat indicator.



Speaking of shadows: during development of expansion they changed how shadows are handled in case of buildings:

- in original game they're solid,
- in expansion they're transparent,
- probably some other technical stuff.

The result of this change is that Editor doesn't support original shadows. Not to mention about lack of possibility to add mud around barns and stuff. See how ugly solo mission on Port Arthur is looking compared to original maps.

IronArthur:

Shadow.PAK is about 4KB so probably they are fugly looking "dots"

BTW, lack of quality of sprites it´s "my fault" they are two types of paks TORSO.PAK and TORSO90.PAK. I thought *90.PAK were something extra but they are the same sprites with extra quality.

So... BINGO!!



Who knows why they needed the low quality versions. I´m going to extract some of the *90.PAK to mount a nice looking MadCat..

Edit: something fast:

I´ve making some advances on the matter.

I´ve done an exe that uncompress an SHP to a series of BMP files with the specified palette (right now only in rgb form latter i´ll add to work in binary mode).

I´ve also made a viewer of sprites that animates them but with very rough edges.

I will try to merge some different shp type of files (torso,legs..) to show a complete mech. But for that i´m going to use MECH.FIT files that show the coordinates that builds the final image.

By the way the final sctructure of a Mech SHP file is:

Code:Bytes Read as Meaning
2 WORD Type of Mech Sprite ( Legs=00, Torso=01, Larm=02, Rarm=03
2 WORD Index of the Animation
2 WORD Always 00

4 DWORD eye catcher should be equal to "1.10"
4 DWORD number of icons included on SHP file

-------
Offsets #items x 8 bytes (there is a record for each icon included on the file)

Bytes Read as Meaning
4 DWORD offset for icon header
4 DWORD 00

Icon data there is a record for each icon included on the file

Bytes Read as Meaning
2 word Heigth
2 word Width
2 word CenterX
2 word CenterY
4 DWORD start X pixel
4 DWORD start Y pixel
4 DWORD end X pixels
4 DWORD end Y pixel
Variable byteS a stream of encoded data for this icon


Icon data is decoded this way:
The Start-position (upper left corner) is start X start Y fields.
Every paint-instruction starts with a "instruction-byte" followed by one or more data-bytes
(except when this first byte is 0 or 1) - see below
Color data is always a byte (0.255) meaning the index into the 256 colors palette.
Depending on the instruction-byte you should take this actions :

Instruction byte is ACTION
0 start new row
1 skip the number of pixels contained in the next byte.
example. "01 22" : means skip 22 pixels

an even number:
draw a line using the color in the next byte with a length equal to "instruction-byte"/ 2
example: "06 D5" : means Line: 0x06/2 = 3 pixels long, color RGB palette_index(0xD5)

an odd number subtract 1 from the "instruction-byte", divide it by 2, and you get the number of bytes, representing the color of the next "as many pixels as your result
example : 05 17 00 ' : next (0x05 - 1)/2 = 2 bytes should be the colors of the next 2 pixels in the row we are in, thats is RGB(palette_index(0x17) and RGB(palette_index(0x00)


@Cmunsta you could show me pakextract sourcecode? i´ve some issues replicating it because SHP bin data on a Torso-Mech.PAK seems to compressed but on your site you said that PAK files don´t come with compressed data.

Yeah, that's wrong. There is compressed data in some PAK files, and the source code I PM'd you does take it into account.

IronArthur:

I´ve made huge progress.

Finally i´ve found the logical way to build a complete mech sprite. I was tinkering with sprite offssets to build them but i´ve found shp mech files are built a lit bit different from Panzer general shp files.

MCG files have x,y coords with negative coords that need to be merged with centerx,centery variables (104,75) . And PG2 shp files dont use that (they are 0,0 centered).

So right now i generate a huge struct for each mech. I need to read them one mech each time so i dont get out of memory exceptions. I will try to optimize that.

It´s slow to load but it works.

A gif from a very alpha preview of Mechviewer:

Gfycat.com

Everything is loaded from original MCG files. I only need a Path to Data dir and optionally a palette file.

I´ve a lot of issues with legs-Torso combinations because legs sprites have half number of frames than torso/arms. Also i´ve storing sprites with a "KeyIndex" that show on shp header file (2 bytes) and on some mechs they get mixed.

I post a modified SHP file description with a correction of centerx,centery positions (they are reversed)
Code:

Bytes Read as Meaning
2 WORD Type of Mech Sprite ( Legs=00, Torso=01, Larm=02, Rarm=03)
2 WORD Index of the Animation (need to test further)
2 WORD Always 00

4 DWORD eye catcher should be equal to "1.10"
4 DWORD number of icons included on SHP file

-------
Offsets #items x 8 bytes (there is a record for each icon included on the file)

Bytes Read as Meaning
4 DWORD offset for icon header
4 DWORD 00

Icon data there is a record for each icon included on the file

Bytes Read as Meaning
2 word Heigth
2 word Width
2 word CenterY
2 word CenterX
4 DWORD start X pixel
4 DWORD start Y pixel
4 DWORD end X pixels
4 DWORD end Y pixel
Variable byteS a stream of encoded data for this icon


Icon data is decoded this way:
The Start-position (upper left corner) is start X start Y fields.
Every paint-instruction starts with a "instruction-byte" followed by one or more data-bytes
(except when this first byte is 0 or 1) - see below
Color data is always a byte (0.255) meaning the index into the 256 colors palette.
Depending on the instruction-byte you should take this actions :

Instruction byte is ACTION
0 start new row
1 skip the number of pixels contained in the next byte.
example. "01 22" : means skip 22 pixels

an even number:
draw a line using the color in the next byte with a length equal to "instruction-byte"/ 2
example: "06 D5" : means Line: 0x06/2 = 3 pixels long, color RGB palette_index(0xD5)

an odd number subtract 1 from the "instruction-byte", divide it by 2, and you get the number of bytes, representing the color of the next "as many pixels as your result
example : 05 17 00 ' : next (0x05 - 1)/2 = 2 bytes should be the colors of the next 2 pixels in the row we are in, thats is RGB(palette_index(0x17) and RGB(palette_index(0x00)


What can we do with this?

IronArthur:

Probably the question is, what do you want to do?

Because we can extract the full mech sprites. We can also compress them into games format.

i think we can´t add new mechs without removing some other mech out (Stiletto please). They seems hardcoded into exe. We can modify his appearence data on Sprites.pak and game data on OBJECTS.pak i think.

But what for? someone is going to make a new mech full animated? is a LOT of work. Every mech has like ~300 shp files with 1 to 35 images each for animation.

Probably the only option to insert a new mech is to use a 3d Mech full animated and capture the frames into images and then into shp-pak files.

My opinion, is better to use this sprites into other games or remakes or something like that. It was always my goal to extract the sprites to use them in other things. They are beautiful and probably with too many animation details.

Bestia_Infernali:

Just curious: are there any files in sprites' PAKs that hold some kind of animations info? There are many glitches with Mechs sprites "coordination" (especially from Expansion).



Quote from: IronArthur on March 05, 2015, 02:41:47 AM

bbc_standard_quote wrote: They are beautiful and probably with too many animation details.

True. Personally I think that MC's Madcat (it has ultra badass head cockpit), and Vulture are the best looking among all BT based 3d models.

Quote from: IronArthur on March 04, 2015, 08:25:21 AM

bbc_standard_quote wrote: I´ve a lot of issues with legs-Torso combinations because legs sprites have half number of frames than torso/arms.

Crippled leg anim is mirrored (how fugly is this?).

IronArthur:

If you extract SPRITES.PAK you get a lot of files. Some of them are mech files:

file17 : Madcat
file19 : Raven

Raven is the "typical" description file. Simetrical torso. Github.com

I don´t know why but Madcat,Vulture and Masakari had a big Table for Animation transitions:
Code:

[TransitionTable]
uc[810] Transiti /> -1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //0,0 From Park to Park (NULL)
1, 2,-1,-1,-1,-1,-1,-1,-1,-1, //0,1 From Park to Stand
1, 2, 3, 4,-1,-1,-1,-1,-1,-1, //0,2 From Park to Walk
1, 2, 3, 4, 6, 7,-1,-1,-1,-1, //0,3 From Park to Run
1, 2,10, 9,-1,-1,-1,-1,-1,-1, //0,4 From Park to Reverse
1, 2, 3,11,-1,-1,-1,-1,-1,-1, //0,5 From Park to Limp
1, 2,20, 2,-1,-1,-1,-1,-1,-1, //0,6 From Park to Jump
19,15,23,-1,-1,-1,-1,-1,-1,-1, //0,7 From Park to Fall Forward
18,14,24,-1,-1,-1,-1,-1,-1,-1, //0,8 From Park to Fall Backward
//--------------------------------------------------------------------------------
1, 0,-1,-1,-1,-1,-1,-1,-1,-1, //1,0 From Stand to Park
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //1,1 From Stand to Stand (NULL)
3, 4,-1,-1,-1,-1,-1,-1,-1,-1, //1,2 From Stand to Walk
3, 4, 6, 7,-1,-1,-1,-1,-1,-1, //1,3 From Stand to Run
10, 9,-1,-1,-1,-1,-1,-1,-1,-1, //1,4 From Stand to Reverse
3,11,-1,-1,-1,-1,-1,-1,-1,-1, //1,5 From Stand to Limp
20, 2,-1,-1,-1,-1,-1,-1,-1,-1, //1,6 From Stand to Jump
19,15,23,-1,-1,-1,-1,-1,-1,-1, //1,7 From Stand to Fall Forward
18,14,24,-1,-1,-1,-1,-1,-1,-1, //1,8 From Stand to Fall Backward
//--------------------------------------------------------------------------------
5, 2, 1, 0,-1,-1,-1,-1,-1,-1, //2,0 From Walk to Park
5, 2,-1,-1,-1,-1,-1,-1,-1,-1, //2,1 From Walk to Stand
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //2,2 From Walk to Walk (NULL)
6, 7,-1,-1,-1,-1,-1,-1,-1,-1, //2,3 From Walk to Run
5,10, 9,-1,-1,-1,-1,-1,-1,-1, //2,4 From Walk to Reverse
11,-1,-1,-1,-1,-1,-1,-1,-1,-1, //2,5 From Walk to Limp
5, 2,20, 2,-1,-1,-1,-1,-1,-1, //2,6 From Walk to Jump
15,23,-1,-1,-1,-1,-1,-1,-1,-1, //2,7 From Walk to Fall Forward
14,24,-1,-1,-1,-1,-1,-1,-1,-1, //2,8 From Walk to Fall Backward
//--------------------------------------------------------------------------------
8, 4, 5, 2, 1, 0,-1,-1,-1,-1, //3,0 From Run to Park
8, 4, 5, 2,-1,-1,-1,-1,-1,-1, //3,1 From Run to Stand
8, 4,-1,-1,-1,-1,-1,-1,-1,-1, //3,2 From Run to Walk
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //3,3 From Run to Run (NULL)
8, 5,10, 9,-1,-1,-1,-1,-1,-1, //3,4 From Run to Reverse
8,11,-1,-1,-1,-1,-1,-1,-1,-1, //3,5 From Run to Limp
8, 5,20, 2,-1,-1,-1,-1,-1,-1, //3,6 From Run to Jump
17,15,23,-1,-1,-1,-1,-1,-1,-1, //3,7 From Run to Fall Forward
16,14,24,-1,-1,-1,-1,-1,-1,-1, //3,8 From Run to Fall Backward
//--------------------------------------------------------------------------------
5, 2, 1, 0,-1,-1,-1,-1,-1,-1, //4,0 From Reverse to Park
5, 2,-1,-1,-1,-1,-1,-1,-1,-1, //4,1 From Reverse to Stand
5, 2, 3, 4,-1,-1,-1,-1,-1,-1, //4,2 From Reverse to Walk
5, 2, 3, 4, 6, 7,-1,-1,-1,-1, //4,3 From Reverse to Run
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //4,4 From Reverse to Reverse (NULL)
5, 3,11,-1,-1,-1,-1,-1,-1,-1, //4,5 From Reverse to Limp
5,20, 2,-1,-1,-1,-1,-1,-1,-1, //4,6 From Reverse to Jump
5, 3,15,23,-1,-1,-1,-1,-1,-1, //4,7 From Reverse to Fall Forward
5, 3,14,24,-1,-1,-1,-1,-1,-1, //4,8 From Reverse to Fall backward
//--------------------------------------------------------------------------------
5, 2, 1, 0,-1,-1,-1,-1,-1,-1, //5,0 From Limp to Park
5, 2,-1,-1,-1,-1,-1,-1,-1,-1, //5,1 From Limp to Stand
4,-1,-1,-1,-1,-1,-1,-1,-1,-1, //5,2 From Limp to Walk
6, 7,-1,-1,-1,-1,-1,-1,-1,-1, //5,3 From Limp to Run
5,10, 9,-1,-1,-1,-1,-1,-1,-1, //5,4 From Limp to Reverse
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //5,5 From Limp to Limp (NULL)
5, 2,20, 2,-1,-1,-1,-1,-1,-1, //5,6 From Limp to Jump
15,23,-1,-1,-1,-1,-1,-1,-1,-1, //5,7 From Limp to Fall Forward
14,24,-1,-1,-1,-1,-1,-1,-1,-1, //5,8 From Limp to Fall Backward
//--------------------------------------------------------------------------------
1, 0,-1,-1,-1,-1,-1,-1,-1,-1, //6,0 From Jump to Park
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //6,1 From Jump to Stand (NULL)
3, 4,-1,-1,-1,-1,-1,-1,-1,-1, //6,2 From Jump to Walk
3, 4, 6, 7,-1,-1,-1,-1,-1,-1, //6,3 From Jump to Run
10, 9,-1,-1,-1,-1,-1,-1,-1,-1, //6,4 From Jump to Reverse
3,11,-1,-1,-1,-1,-1,-1,-1,-1, //6,5 From Jump to Limp
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //6,6 From Jump to Jump (NULL)
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //6,7 From Jump to Fall Forward
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //6,8 From Jump to Fall Backward
//--------------------------------------------------------------------------------
21,22, 1, 0,-1,-1,-1,-1,-1,-1, //7,0 From Fall Forward to Park
21,22, 2,-1,-1,-1,-1,-1,-1,-1, //7,1 From Fall Forward to Stand
21,22, 3, 4,-1,-1,-1,-1,-1,-1, //7,2 From Fall Forward to Walk
21,22, 3, 4, 6, 7,-1,-1,-1,-1, //7,3 From Fall Forward to Run
21,22,10, 9,-1,-1,-1,-1,-1,-1, //7,4 From Fall Forward to Reverse
21,22, 3,11,-1,-1,-1,-1,-1,-1, //7,5 From Fall Forward to Limp
21,22,20, 2,-1,-1,-1,-1,-1,-1, //7,6 From Fall Forward to Jump
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //7,7 From Fall Forward to Fall Forward (NULL)
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //7,8 From Fall Forward to Fall Backward (NULL)
//--------------------------------------------------------------------------------
22, 1, 0,-1,-1,-1,-1,-1,-1,-1, //8,0 From Fall Backward to Park
22, 2,-1,-1,-1,-1,-1,-1,-1,-1, //8,1 From Fall Backward to Stand
22, 3, 4,-1,-1,-1,-1,-1,-1,-1, //8,2 From Fall Backward to Walk
22, 3, 4, 6, 7,-1,-1,-1,-1,-1, //8,3 From Fall Backward to Run
22,10, 9,-1,-1,-1,-1,-1,-1,-1, //8,4 From Fall Backward to Reverse
22, 3,11,-1,-1,-1,-1,-1,-1,-1, //8,5 From Fall Backward to Limp
22,20, 2,-1,-1,-1,-1,-1,-1,-1, //8,6 From Fall Backward to Jump
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, //8,7 From Fall Backward to Fall Forward
-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 //8,8 From Fall Backward to Fall Backward (NULL)

Other mechs doesn´t have this Table.

At first i thought thay those number where the Anim index thay are on SHP header bytes but on Madcat every animation number is not on that table.

22, 1, 0,-1,-1,-1,-1,-1,-1,-1, //8,0 From Fall Backward to Park

On Madcat shp files the animation for get up is 34, animation 22 is to fall forward and 1 is stand inactive ¿?¿?¿?¿ There is no 8,4... animation index

Mechs from expansion have "simplified" files i don´t know if optimized or made in a rush
Stiletto/Firefalcon: Github.com

Madcat: Github.com

btw, i thought i could get some info for building animations of those files, (like how many anims has on walking etc...) but i can´t find any correspondence
ul BasePacketNumber = 60 // Index into packet file for this gesture StandtoPark
ul BasePacketNumber = 720 // Index into packet file for this gesture FallenBack

there is no 60 or 720 index. I guess the build some huge general sprite index address table but who knows how is built.


Quote from: Bestia Infernali on March 05, 2015, 04:47:43 PM

bbc_standard_quote wrote:
Crippled leg anim is mirrored (how fugly is this?).

Torso/arms for a 360º turnaround has 32 positions so if mech is simetrical 17 sprites and the rest they are just a mirror.
On legs we have 16 positions for a 360º usually whith 9 sprites and the rest mirrors.

On asimetrical mechs it gets messy. We have mech with asimetrical torsos (32 real sprites) with simetrical arms (17 sprites + mirrors), asimetrical torsos+ arms (32 real sprites for everything), and finally simetrical torsos + asimetrical arms.

A question/petition for someone smarter than me.

i have problems mirroring images to get a full 360º. I don´t know how they do it but i can´t find a way to mirror an sprite and don't get totally desync animations with asymmetric sprites (that are 360º painted).


Gfycat.com

After the "looking north" position, the torso is mirrored, the legs are mirrorred at "eleven hour" position. In static Animations it´s works, but in animated.. well you see what happens.

In game it works perfect. If the mech tilts the head to left when moving right leg, on the mirror it works the same. I don´t know how to do that, if i just mirror the image the movement is reversed.

i´ve tried to delay the animation but i haven´t found a definite way to sync them.

Main problem is that are some harcoded tables on exe, i don´t know why because the rest of data is on external files.
To insert a Mech on a Map you need
PMnnntvv.FIT being nnn from this harcoded table
Table:
IS Mechs Clan Mechs
100 Commando 200 Uller
101 Firestarter 201 Cougar
102 Raven 203 Hunchback IIc
103 Hollander II 204 Vulture
104 Hunchback 205 Loki
105 Centurion 206 Thor
106 Catapult 207 Mad Cat
107 JagerMech 208 Masakari
108 Awesome 209 Shadow Cat
109 Atlas 210 Nova Cat
110 Fire Falcon 211 Turkina
111 Bushwacker
112 Mauler

ex:
PM109400.FIT -->Atlas-W
Page 41 of Cmunsta Mission Builder Guide Freewebs.com Campaign Builder's Guide I (Rev 1.1).pdf

After that you go to Objects.pak -> Sprites.pak -> Torso/legs/arms.pak . Every of them in external files so modifiable.


Edit: after looking again at game files, MAYBE if you add a new PMnnntvv.FIT file on data/mission and enter l NameIndex = to a new index on Objects.pak -> Sprites.pak -> Torso/legs/arms.pak in THEORY you could add a new mech/vehicle

Most of the mech animations are 15fps with 32 different orientations ( 17 with Symmetricals).

This is Thor Walk animation file:

[Build4] //this is used to build the sprite gesture
st Directory = "O:\thor\walk\pix\"
st MatteDir = "O:\thor\walk\mask\"
st HSDir = "O:\thor\hotspots\"
st SpriteGestureName = "walk"
st Name = "th.1"
ul TotalFrames = 41 // Total frames @ 30 fps
ul FrameRate = 15 // Intended Frame rate of Playback
f GammaLevel = 0.0
uc StartIndex = 0
uc RangeSize = 159
uc paletteNum = 1
ul HotSpotX = 75
ul HotSpotY = 104

They have 3 more directions between north and north-east





8 directional for a turn-based game is fine but for a rts seems very low. 16 was probably the usual for the time, 32 it´s masochistic for the artist.