From my earlier testing with snake demons, I had surmised that COF controled the # of components to be displayed, if the slot allowed for it. For example, snake gfx in the mishappen slot do not display that "Charge-up" lightning animation before the missile is shot. But if you put a mishappen COF into the snake gfx, they do show the lightning animation. The problem is my COFs do not seem to be affecting the bat demons' lightning attack (for the attack2 and dying animations there is a bit of lightning, and this is a seperate component) I had thought that a 1-layer COF for the animation would disable this S8 animation.

quote:

---

FileReadError
Location: D2Hell\SRC\Archive.cpp, line #59
Expression: DATA\GLOBAL\MONSTERS\77\COF\77RNhth.COF

---

But there are a quite a few structures in a COF file, between the frame info bytes up front and the first DCC call, that I have not derived a pattern for yet. Also it turns out there is something of a pattern for the bytes that appear after the frames/direction byte in the AnimData.D2 records. For the discussion following, I refer to offsets from the first byte of the COF string, that first byte being Offset 0.

Almost all animation records have a nonzero entry at offset 12 or offset 13. Since offset 13's value is always 1, I suspect those two locations are the low-order bytes of a dword. The only records without a value here are two modes of an unused object and the DD mode of...the Compelling Orb???

Many times, but not always, the GH mode has a 1 at offset 16.

There are always additional nonzero bytes for the offensive modes (A1, A2, SC, S#, etc.). Most of these bytes are between offset 20 and offset 25, but the range is from 16 to 34. Some monster and many character records have more than one such nonzero byte. I saw no such values for passive modes (DD,DT,NU,WL).

I will need to keep looking for what these patterns might represent.