ID:2758541
 
Not a bug
BYOND Version:514
Operating System:Windows 10 Pro
Web Browser:Firefox 95.0
Applies to:Dream Daemon
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
When you blend an animated sprite with another sprite, the animation is forced into a frame delay of 1 for every frame regardless of previous configuration.

Numbered Steps to Reproduce Problem:
Testcase: https://www.dropbox.com/s/dikugws4y0ocl27/ IconAnimationEditTestcase.zip?dl=1
- Compile and run the testcase project
- Activate the client verb
- Compare the animation speed to what's configured in the dmi

Expected Results:
A slowly pulsing box with a delay of 10

Actual Results:
A quickly pulsing box with a delay of 1

Does the problem occur:
Every time? Or how often? Yes
In other games? Tested both in sample case and ss13
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur? Never

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I'm unsure how far back this goes, at the very least it was an issue in 512 stable and I only now got around to making an example case for this report.

Workarounds:
Use only 1 delay frames and add a bunch of repeat frames. Though this is a very poor workaround in my particular case as it is more expensive to modify sprites with multiple frames like this.
We have a greyscaling system for making multilayered sprites that get colored in during runtime and I can't use it properly for animated sprites until it's possible to blend animated sprites with frame delays other than 1.
I thought I had the test case for this but it seems I don't. The download link doesn't currently work. Do you still have the test case available?
I've updated the link in the op as it seems to have expired.
Thanks.
Bump, this is still an issue and I would really like for animated sprites to work in the greyscaling system mentioned previously.
I've finally had a chance to look at this, and although I found some undesirable behavior on the backend to change, this isn't actually a bug.

You're blending an icon with its own delay information over one that has existing delay info. The source icon is the one that has the fast delay, whereas the one you're overlaying has the slow delay you want. In order for this to work the way you expect, you'd have to do the blending in the opposite order.

There's also a bug in your test case, as you're using a blend_mode value in Blend() instead of one of the ICON_ constants. It should be ICON_OVERLAY, not BLEND_OVERLAY.
Lummox JR resolved issue (Not a bug)
That blending order matters for animated sprites is helpful to know and should really be in the blend documentation. There are still a couple issues here though.

The other icon with its own delay information is a single frame non animated icon that can't have its delay information modified within the editor. Additionally, there's no way to read delay information from dm so I can't write a check to make sure blends are in the right order.