Doomsday Engine

Kurikai has helpfully uploaded this mod to files.dengine.net:

http://files.dengine.net/liquids-20060101.pk3

After some initial investigation the problem here is that this mod has been packaged in a way that depends upon the old approach used by Doomsday for handling the animated textures/flats.

In a nutshell:
DOOM.exe would animate all flats between e.g., SLIME01 and SLIME04 regardless of how many lumps the start/end flats bookend. This means that if a PWAD replaces those lumps they can change the number of frames in the sequence by simply adding new lumps named SLIME01 and SLIME04 and add as many new lumps between the two as they wish/require.
Doomsday instead requires that all frames in an animation sequence are named and the anim group constructed in order.

Due to the differences in the above, for beta6 I have removed the external default texture/flat group definitions and instead, implemented a new algorithm that will build the anim groups required by Doomsday, dynamically at runtime using logic that respects the behaviour of DOOM.exe - P_InitPicAnims()

However, this mod contains custom definitions for the IWAD animation sequences that add new frames. This means that by the time P_InitPicAnims() is called, there already exists a complete set of anim groups for these animations but the current logic does not consider this.

• The dynamically created anim groups created via P_InitPicAnims() should happen BEFORE those created using Group definitions.
• Group definitions should override anim groups created via P_InitPicAnims()

In addition, there is a bug in this mod -
The lumps SLIME01...SLIME04 are not in the correct order (SLIME04 appears before SLIME01) thus it will need updating in order to be used with beta6 anyway.

Step one of the solution to this has been fixed in svn rev #6215.

Next step; let user-created Group animation sequences completely override those generated automatically by P_InitPicAnims().

Fixed in branch ringzero+master for the upcoming 1.9.7 release.

Note that there remains a bug in Liquids.pk3 itself (explained in an earlier post) which should be addressed there, rather than in the engine.