eComponent < NUM_COMPONENTS... SOLVED!!! :)

[Alkalund]

Ok people, I tested this only once so feel free to test it yourselves and see if there are any problems with the method.

Many thanks go to Isolde, Paul Siramy and Myhrginoc, in fact all I'm doing here is using the info they provided to solve our problem.

Now lets get to business; this is our feared assertion:

Code: Select all

Assertion Failure 
Location : C:\Projects\Diablo2\Source\D2Client\Engine\GfxUtil.cpp, line #1352 
Expression : eComponent < NUM_COMPONENTS

We first thought it had to do with incorrect framecount editing in animdata.d2. Of course that was not the only problem, for even with correct hexediting of animdata.d2 the problem persisted.

We then suspected it had something to do with the .cof files, but no solution could be given. Finally, Isolde enlightened us:

The blinking is probably due to incorrect frame counts in animdata.d2

Could you give me the exact assertion you get for the components thing?

Assertion provided:

Sure, here it is:

Code: Select all

Assertion Failure 
Location : C:\Projects\Diablo2\Source\D2Client\Engine\GfxUtil.cpp, line #1352 
Expression : eComponent < NUM_COMPONENTS 

In this thread there is info on how we currently edit the framecount in animdata.d2:

viewtopic.php?t=1919

Even with supposedly correct framecount editing the blinking can appear sometimes. That's why I thought maybe editing .cof files is also required for framecount editing.

And the confirmation:

you're right about the cof files. you're getting that assertion because of a cof error.

Still, the fix would be more than just editing cof files. There are other .d2 files we hadn't messed with until that point, and Paul Siramy discussed about them in the following thread:

chars_cof.d2 & cmncof_a*.cof format, & stats

Again Isolde provided crucial information here:

The cof records in these files are pre loaded every time the game starts, so if you're changing a cof that is listed in one of these files, you should change it in the cmncof file, otherwise change the individual file.

Ok, so here's how to get rid of this error:
1 - If the cof file corresponding to your animation is not listed in the cmncof_a#.d2 files (or chars_cof.d2, if you're working with character animations), edit the .cof file itself (I'll explain how later).
2 - If the cof file corresponding to your animation is is listed in the cmncof_a#.d2 files (or chars_cof.d2, if you're working with character animations), edit all cmncof_a#.d2 files that contain entries of this cof (or chars_cof.d2).

Animdata.d2 still must be edited in this method, in all cases. Also notice that for the expansion the chars_cof.d2 used is the one found in d2exp.mpq.

To show how I fixed the error, I'll give as an example my test with the walking animation of the Yeti: grab a 160-frame animation to use as the new Yeti walk animation. If you edit only animdata.d2, you will crash with our feared assertion. Ok, now open cmncof_a1.d2, and do a string search for yewlhth (and yes, it is lowercase ). You will find it. You will also find this string in cmncof_a2.d2 and cmncof_a3.d2, which means you will have to modify these 3 files.

Paul Siramy detailed the structure of the cmncof_a#.d2 files in the thread I mentioned above. I'll paste here the entry corresponding to the cof file in question, yewlhth.cof, color coding the important stuff for the fix:

EDIT: ignore the rest of this post, for it is incomplete. Read the rest of the explanation here.

FF FF FF FF 00 00 00 00 91 00 00 00 79 65 77 6C 68 74 68 00 FF FF FF FF 01 0C 08 14 01 F0 FD 7F 95 FF FF FF 37 00 00 00 9F FF FF FF 15 00 00 00 00 01 00 00 01 01 01 00 00 68 74 68 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

The violet byte contains the size (in bytes) of the cof file. The red byte contains the number of frames per direction of your animation. The blue section I'm not really sure how it works, it is related to layer information of your animation. In our example, we have a monster composed only of a torso, so it is going to be easy (basicaly we have the 01 byte repeated 96 times, which is the original framecount of the animation, as can be seen in the red byte).

We want the Yeti's walk animation to have 160 frames, so replace the red byte with a 14 (20 in hexadecimal), and change the blue section so it has 160 bytes in the end (again, this is only because we have a 1-part moster, for multiple part monster the number of bytes in the blue section is (total frames)*(number of parts)). Finally, you must change the violet byte so it contains the correct size for this entry; we added 64 bytes to this entry (we had 96 bytes in the blue section, wanted 160, so 160 - 96 = 64). Simply add 64 to the size entry, this should give you D1 (D1 = 91 (original) + 40 (64 in hex)). The whole changed section looks like

FF FF FF FF 00 00 00 00 D1 00 00 00 79 65 77 6C 68 74 68 00 FF FF FF FF 01 14 08 14 01 F0 FD 7F 95 FF FF FF 37 00 00 00 9F FF FF FF 15 00 00 00 00 01 00 00 01 01 01 00 00 68 74 68 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

This is all there is to it. If your cof file isn't mentioned in the .d2 files, edit the cof file itself.

I'm sorry if any of this sounds confusing, its 2am here and I wanted to post this before going to sleep... feel free to comment/add/correct anything

Oh, and this should fix the blinking problems as well. It is too good to believe, being able to solve both problems, after carrying them for over six months 8)

EDIT: this fix is INCOMPLETE and will NOT work. See one of my posts below for the correct solution.

[Incandescent One]

This is very encouraging, i can remember not too long ago i made a post detailing this very same error, hexing the framecount for the yeti still provided this error even after swapping cof files around and double checking the animdata code. So a big thanks to all those involved in this lil' breakthrough, should open up a few more possibilities, and nicely written Alkalund

[Joel]

eheh no frame reframing stuffs

Alkalund can I add this stufff to my animation tutorial ?

[Baz]

now I can finally get nice monster and character animations instead of animations that are so fast that I can almost not see them thnx a lot

[Myhrginoc]

Nice piece of work, Alkalund! You certainly chased it quite a distance.

Here is more propeller-head stuff associated with the error. There are a lot of eComponent < NUM_COMPONENTS errors in the game, but each one gets its own number. This one pops up a lot because the root function gets called a lot, and there are several checks in the code which, if failed, call the assertion. That function from D2Client (v1.09b) is below, note the assertion is at the end (548 hex = 1352).

Code: Select all

6FB5E260  /$  83EC 54           SUB ESP,54
6FB5E263  |.  53                PUSH EBX
6FB5E264  |.  55                PUSH EBP
6FB5E265  |.  56                PUSH ESI
6FB5E266  |.  8BF2              MOV ESI,EDX
6FB5E268  |.  33DB              XOR EBX,EBX
6FB5E26A  |.  57                PUSH EDI
6FB5E26B  |.  8A06              MOV AL,[BYTE DS:ESI]
6FB5E26D  |.  897424 14         MOV [DWORD SS:ESP+14],ESI
6FB5E271  |.  84C0              TEST AL,AL
6FB5E273  |.  8BE9              MOV EBP,ECX
6FB5E275  |.  895C24 10         MOV [DWORD SS:ESP+10],EBX
6FB5E279  |.  0F86 A2000000     JBE D2Client.6FB5E321
6FB5E27F  |>  8B4424 68         /MOV EAX,[DWORD SS:ESP+68]
6FB5E283  |.  33D2              |XOR EDX,EDX
6FB5E285  |.  8A1403            |MOV DL,[BYTE DS:EBX+EAX]
6FB5E288  |.  83FA 10           |CMP EDX,10
6FB5E28B  |.  0F8D 9E000000     |JGE D2Client.6FB5E32F
6FB5E291  |.  B9 12000000       |MOV ECX,12
6FB5E296  |.  33C0              |XOR EAX,EAX
6FB5E298  |.  8D7C24 1C         |LEA EDI,[DWORD SS:ESP+1C]
6FB5E29C  |.  6A FF             |PUSH -1                          ; /Arg2 = FFFFFFFF
6FB5E29E  |.  F3:AB             |REP STOS [DWORD ES:EDI]          ; |
6FB5E2A0  |.  8B4C24 74         |MOV ECX,[DWORD SS:ESP+74]        ; |
6FB5E2A4  |.  894424 24         |MOV [DWORD SS:ESP+24],EAX        ; |
6FB5E2A8  |.  8B4424 78         |MOV EAX,[DWORD SS:ESP+78]        ; |
6FB5E2AC  |.  894C24 2C         |MOV [DWORD SS:ESP+2C],ECX        ; |
6FB5E2B0  |.  8D4C24 1C         |LEA ECX,[DWORD SS:ESP+1C]        ; |
6FB5E2B4  |.  885424 3D         |MOV [BYTE SS:ESP+3D],DL          ; |
6FB5E2B8  |.  51                |PUSH ECX                         ; |Arg1
6FB5E2B9  |.  8D5424 24         |LEA EDX,[DWORD SS:ESP+24]        ; |
6FB5E2BD  |.  8BCD              |MOV ECX,EBP                      ; |
6FB5E2BF  |.  894424 2C         |MOV [DWORD SS:ESP+2C],EAX        ; |
6FB5E2C3  |.  E8 98EBFFFF       |CALL D2Client.6FB5CE60           ; \D2Client.6FB5CE60
6FB5E2C8  |.  85C0              |TEST EAX,EAX
6FB5E2CA  |.  74 48             |JE SHORT D2Client.6FB5E314
6FB5E2CC  |.  6A 01             |PUSH 1
6FB5E2CE  |.  8D5424 20         |LEA EDX,[DWORD SS:ESP+20]
6FB5E2D2  |.  6A 00             |PUSH 0
6FB5E2D4  |.  52                |PUSH EDX
6FB5E2D5  |.  E8 F80D0000       |CALL <JMP.&D2CMP.#10055>
6FB5E2DA  |.  85C0              |TEST EAX,EAX
6FB5E2DC  |.  74 36             |JE SHORT D2Client.6FB5E314
6FB5E2DE  |.  8B4424 1C         |MOV EAX,[DWORD SS:ESP+1C]
6FB5E2E2  |.  85C0              |TEST EAX,EAX
6FB5E2E4  |.  74 2E             |JE SHORT D2Client.6FB5E314
6FB5E2E6  |.  50                |PUSH EAX
6FB5E2E7  |.  E8 EC0D0000       |CALL <JMP.&D2CMP.#10040>
6FB5E2EC  |.  8BF0              |MOV ESI,EAX
6FB5E2EE  |.  E8 7D68F5FF       |CALL D2Client.6FAB4B70
6FB5E2F3  |.  2BF0              |SUB ESI,EAX
6FB5E2F5  |.  55                |PUSH EBP
6FB5E2F6  |.  E8 D90E0000       |CALL <JMP.&D2Common.#10334>
6FB5E2FB  |.  03F0              |ADD ESI,EAX
6FB5E2FD  |.  8B4424 6C         |MOV EAX,[DWORD SS:ESP+6C]
6FB5E301  |.  3B30              |CMP ESI,[DWORD DS:EAX]
6FB5E303  |.  7E 02             |JLE SHORT D2Client.6FB5E307
6FB5E305  |.  8930              |MOV [DWORD DS:EAX],ESI
6FB5E307  |>  8B4424 10         |MOV EAX,[DWORD SS:ESP+10]
6FB5E30B  |.  8B7424 14         |MOV ESI,[DWORD SS:ESP+14]
6FB5E30F  |.  40                |INC EAX
6FB5E310  |.  894424 10         |MOV [DWORD SS:ESP+10],EAX
6FB5E314  |>  33C0              |XOR EAX,EAX
6FB5E316  |.  43                |INC EBX
6FB5E317  |.  8A06              |MOV AL,[BYTE DS:ESI]
6FB5E319  |.  3BD8              |CMP EBX,EAX
6FB5E31B  |.^ 0F8C 5EFFFFFF     \JL D2Client.6FB5E27F
6FB5E321  |>  8B4424 10         MOV EAX,[DWORD SS:ESP+10]
6FB5E325  |.  5F                POP EDI
6FB5E326  |.  5E                POP ESI
6FB5E327  |.  5D                POP EBP
6FB5E328  |.  5B                POP EBX
6FB5E329  |.  83C4 54           ADD ESP,54
6FB5E32C  |.  C2 1000           RETN 10
6FB5E32F  |>  68 48050000       PUSH 548
6FB5E334  |.  68 D813BA6F       PUSH D2Client.6FBA13D8                  ;  ASCII "C:\Projects\Diablo2\Source\D2Client\Engine\GfxUtil.cpp"
6FB5E339  |.  68 0812BA6F       PUSH D2Client.6FBA1208                  ;  ASCII
"eComponent < NUM_COMPONENTS"
6FB5E33E  |.  E8 D3250000       CALL <JMP.&Fog.#10023>
6FB5E343  |.  83C4 0C           ADD ESP,0C
6FB5E346  |.  6A FF             PUSH -1
6FB5E348  |.  E8 562C0000       CALL D2Client.6FB60FA3
6FB5E34D      90                NOP
6FB5E34E      90                NOP
6FB5E34F      90                NOP

D2CMP.10055 is a function that I see a lot of problems with in Unhandled Exceptions related to monster animations, when we do one of these swaps. Jeff Bouley had this with his Unique World Corrupters in SiC v2.0, but not the normal ones (now why would that make a difference). Maybe not totally related to the 1352 error, but it does seem to be a display function for DCC files.

[Alkalund]

Bad news folks

Did you try testing this? Because I tried to apply the same changes to the other animations of the yeti and, guess what...

Code: Select all

Assertion Failure
Location : C:\Projects\Diablo2\Source\D2Client\Engine\GfxUtil.cpp, line #1352
Expression : eComponent < NUM_COMPONENTS

And the worst part is, when I tried to do the fix again for the walk animation, it didn't work

So it appears that:
a) I forgot something I did (possibly, I was sleeping in the cpter chair already...)
b) The bastard assertion decided not to show in my tests just to tease me
c) I don't know how to use -direct -txt anymore

So the problem is not 100% fixed yet folks. I urge you to help solving this problem, it has been around for far too long

I honestly don't know what could possibly be missing here... the only part I'm not sure how it works is the layer information block, but this simple change should be correct.

Oh man, it was sooo close

[Alkalund]

Heheh, NOW it is solved

I indeed forgot to add something in my post yesterday I'll redo the example, this time with the correct fix:

We want yetrlitwlhth with 160 frames; this is the original entry in cmncof_a1.d2 for the yewlhth cof file:

FF FF FF FF 00 00 00 00 91 00 00 00 79 65 77 6C 68 74 68 00 FF FF FF FF 01 0C 08 14 01 F0 FD 7F 95 FF FF FF 37 00 00 00 9F FF FF FF 15 00 00 00 00 01 00 00 01 01 01 00 00 68 74 68 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0101 01 01 01 01 01 01 01

As explained before, the violet byte contains the byte size of the cof file. The red byte contains the number of frames per direction of the corresponding animation. The blue section contains layer information.

I forgot to mention the orange section you can now see highlighted in the byte sequence The size in bytes of the orange section MUST be the number of frames per direction of the corresponding animation (except in a very special case where if the cof entry has 1 layer AND 1 frame per direction AND 1 direction AND the size of this cof entry is 42 bytes (the size in its header), then there are not 1 byte but 4 in this data... thanks a lot Paul Siramy for pointing this ); from what I could observe, it contains some sort of flags to tell the game in which frame to compute an effect or something of the sort. This is what was missing in the previous fix.

Ok so we originally had 12 (0C) frames per direction, that's 12 bytes in the orange section. We want 20 frames per direction, so we need to add 8 bytes in this section to make it have a size of 20 bytes.

We also need to add 8*8 = 64 bytes in the blue section, as explained before. Now, we must be careful when changing the violet byte. In total, we added 8 + 64 = 72 bytes to the cof entry, so the new value in the violet byte will be 91 (original value) + 48 (72 in hex) = D9. The new cof entry will look like this:

FF FF FF FF 00 00 00 00 D9 00 00 00 79 65 77 6C 68 74 68 00 FF FF FF FF 01 14 08 14 01 F0 FD 7F 95 FF FF FF 37 00 00 00 9F FF FF FF 15 00 00 00 00 01 00 00 01 01 01 00 00 68 74 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01

I tested the fix with the walking, attack1 and attack2 animations; all of them worked perfectly AND this also solved the blinking problem.

Begone, nasty bug!!!! I banish thee!!!!

[MikeTheGreat]

Alkalund, I have to give you mad props. This is an awesome discovery - finally being annoyed by these damn animation bugs will cease! I'm writing all this down right now

[Alkalund]

Thanks MikeTheGreat. The days of animation conversion bugs are hopefully behind us now

Even though I did only 3 tests, I'm pretty confident in the method.

@Joel: feel free to add this to your animation tutorial, as it would surely not be complete without it; let me know if you need any clarifications

[Incandescent One]

Nice work Alkalund, i know you're only mentioning the Yeti's walk anim as an example but this error had stopped several projects in their tracks before...... before now anyway
Time for me to start sifting through all those anim projects that i 'put on the shelf' till i could work out where the errors were coming from

[Joel]

So will people be happy if little applicatino that scan cof files for searchign entries, either if in comncof or single cof and allow cof edition ???

[mrelfire]

I will follow your idea.
It will be good to have a little applciation which generate all the cof files from the dcc files,
What do you think, is it a crazy idea ?

[Alkalund]

So will people be happy if little applicatino that scan cof files for searchign entries, either if in comncof or single cof and allow cof edition ???

You are reading my mind here Joel, if I had decent programming skills I would have made a program that would do just that already

@Incandescent One: yeah, this nasty assertion bugged lots of projects in the past, not anymore now hopefully

[Myhrginoc]

Didn't Paul have a COF viewer or editor in the works? Or that whole-animation system proposed a month back?

[Paul Siramy]

I didn't made an editor, but a viewer. It's more of a "dumper", which produce a text log of the infos in a cof.

This multi-sprite editor is not even start to code, and as we said it'll be a huge investisment the way we see it. As for me, I'm almost able to load a dcc correctly (Bilian Belchev was of course of an unvaluable help here) : I can load the 1st frame of all directions ok, but the others may have some problems.

I can make a quick & very-dirty ms-dos based COF editor as soon as I'll be able to read the dcc format 100% correctly, which is not the case right now (around 99%), so don't expect too much from us on that tool. Right now I'm completly stuck tough.

BTW, the easiest way to don't have any blinking with new animations is to make them match the dcc you are going to replace : same directions, same frames per direction.

[Alkalund]

BTW, the easiest way to don't have any blinking with new animations is to make them match the dcc you are going to replace : same directions, same frames per direction.

Correct, this is the way we've been doing all along, because it was the only way that was 100% fail-proof. It is not practical though, because with this method you can't use the same set of dccs to multiple tokens... you would have to edit several copies to match the framecounts of each token. Besides, some animations don't look good if you remove too many frames from it to make it match the framecount of the animation you're going to replace... but I'm sure you know all of this already

EDIT, just to make a little addition to this post: the time it takes to do the changes above in the cof entries is not too much compared to the time it would take to manually edit the framecount of the dcc files, plus with the new method you only have to mess with the dcc files once, when creating them. Two reasons for people try using this new method, and not just stick to the old method waiting until cof editing tools are available

[Joel]

For me new method all the way

Now i'm converting my anim with full frames, turn into dcc and find offset.
Once it's done, cof let's gooooo ...

Paul, could resend me the cof stuff, I'll handle it on my own.

I was thinking of something that produce working file called cmf :
- Cof Modification File - that are injected into the appropriate d2 or cof file by the application.

So now when you'll release an animation, drop the dcc, the palshift if any adn the cmf. Then use the COF-Editor to patch you existing animdata.d2, cof file etc ...
People will be able to use multiple anim plug-in at once

[Baz]

I've got my first problems : I've made a VERY nice new blood golem summoning animation, BUT, it has got 33 frames per direction!
I looked for g2s1hth in animdata, and found it, and changed the framecount to 21, and I didn't get any crashes I also looked in all cmncof_a#.d2 files, but I couldn't find anything, so animdata was the only thing I changed.
And now my problem: When I summon the blood golem, I only see a few frames of my animation (each time different frames, sometimes even no frames!)
Does somebody know what could cause these problems?

[Paul Siramy]

it has got 33 frames per direction! ... and changed the framecount to 21

Just to be sure, you change it to 21 decimal or 21 hexa (33 in decimal) ? Try to edit the cof as well : a cof have a table of priority for all layers of an animation. You have a new animation that have *more* frames per direction than the original one, so this table have to be bigger. If you new animation have less frames per direction, the table is bigger than needed, but that is not a problem. Since you have more frames, you need a bigger table.

That's the only problems I can see. When I made the clay golem transparent, I made my changes in all its cof, nothing in a .d2 and it worked, so the cof are really processed by the game, that's why I think your problem is in your g2s1hth.cof

The yeti animation in the exemple of this topic have a copy of its cof in a cmncof.d2, so in this case you don't need to hexedit the cof but the cmncof.d2. Since your bloody golem isn't in a cmncof.d2, you have to edit the cof itself. In both case you have to edit a cof, that's just the location that change, either a .d2 (if it's already in there), or the cof itself, but you still need to edit a cof.

Ok, so here's how to get rid of this error:
1 - If the cof file corresponding to your animation is not listed in the .d2 files, edit the .cof file itself (I'll explain how later).
2 - If the cof file corresponding to your animation is is listed in the .d2 files, edit all .d2 files that contain entries of this cof.

That's what Isolde told about chars_cof.d2 & cmncof_a*.cof, NOT animdata.d2. You have found a bloody golem in animdata.d2, but NOT in a cmn_cof, so you have to edit the cof.

[Alkalund]

Ok, so here's how to get rid of this error:
1 - If the cof file corresponding to your animation is not listed in the .d2 files, edit the .cof file itself (I'll explain how later).
2 - If the cof file corresponding to your animation is is listed in the .d2 files, edit all .d2 files that contain entries of this cof.

That's what Isolde told about chars_cof.d2 & cmncof_a*.cof, NOT animdata.d2. You have found a bloody golem in animdata.d2, but NOT in a cmn_cof, so you have to edit the cof.

Paul Siramy is right, sorry if I wasn't clear enough. You ALWAYS have to edit animdata.d2. In my quote above I was talking about the cmncof_a#.d2 files. If you can't find the blood golem in the cmncof_a#.d2 files, then edit the cof files themselves.

EDIT: edited a bit the first post, to avoid any confusions... sorry again.

[Paul Siramy]

Not only cmncof_a#.d2, but also chars_cof.d2, since our modmakers not only convert monsters, but also characters nowadays

animdata.d2 is in itw own format, but cmn_cof_a#.d2 and chars_cof.d2 are in another format (but chars_cof.d2 is in the same format than cmncof_a#.d2).

[Alkalund]

Oops right you are again Paul.... thanks a lot, let me hand you a beer

Off I go to edit the posts again

EDIT: ok posts edited, please let me know if any further clarification is needed.

[Paul Siramy]

I forgot to mention the orange section you can now see highlighted in the byte sequence The size in bytes of the orange section MUST be the number of frames per direction of the corresponding animation

To be very exhaustive, this number of bytes it not always the frames per direction. In my post about the format of the cmncof_a#.d2 I said

In a cof this data is always (frames per direction) bytes size. Not always here, there's a very special case. If the cof have 1 layer AND 1 frame per direction AND 1 direction AND the size of the cof is 42 bytes (the size in its header), then there are not 1 byte but 4 in this data !

So, in this very special case, you won't put 1 byte but 4. But as you see this case is very unlikely to happen. I have repeated it here in the case someone want to use one of the token that has this problem, which can lead to a complete mess of the file.

This is the kind of problems that let us feel the need of a animation (dcc/cof/d2) editor

[Alkalund]

Thanks a lot Paul, I forgot to mention this after coming up with the fix to the method. One more editing may be worth it then...

[Myhrginoc]

Now you need to wrap all of this up in tutorial form and submit it to the File Center.