Merged Timer Applies on Last Frame

[Enthalpy]

A triplet bug of #33 and #43.

When a merged block of frames is tied, the timer only activates on the start of the last frame, instead of the start of the merged block. That is, if A and B are merged, and B is a on a timer, that timer will only start once A is done and B is being read.

[Enthalpy]

I can't reproduce this, and inspection of the code suggests that this bug shouldn't be possible.

As such, closed as a mistaken report.

[Enthalpy]

This bug is active after all. The error was in how I was attempting to reproduce this - this bug won't appear in v5 trials because the timer is on the first frame. In v6 native trials, the timer is on the last frame, so of course the bug appears.

[ThePaSch]

Shouldn’t this be classified as intended behavior? I certainly assumed all this time that it was - and it seems like the most intuitive/expected behavior to me; quite honestly, I’ve never even considered it might be a bug, or that it might work differently.

[Enthalpy]

I'm fairly confident that I found this bug by seeing that v5 and v6 behaved differently. I'll want hard proof of that fact before marking this as "open" again...

[ThePaSch]

Judging by your comments, timers on merged frames are defined differently in V5 as well; while in V5, timers are defined on the first frame of a merged set, in V6, they are defined on the last frame. Looked at in isolation, both respective behaviors seem sensible and intuitive.