Afterimage issue.

[RagingRowen]

KarmaCharmeleon's Rugal's God Lane is missing afterimages when moving. This works fine in vanilla MUGEN.
DivineWolf's Akuma's Ashura Senkuu doesn't have this issue.

KarmaCharmeleon's God Rugal: https://streamable.com/ojp61d
DivineAkuma, in contrast: https://streamable.com/srozsi

[K4thos]

here is what is happening:

1. Rugal in state 2000, Time = 0 uses this code

[State 2000, Movement AfterImage]
type = AfterImage
trigger1 = !Time
time = 2
timeGap = 1
frameGap = 10
length = 21
palBright = 0, 0, 0
palAdd = 0, 0, 0
palMul = 0.9, 0.9, 0.9
palContrast = 160, 160, 160
palPostBright = 0, 0, 0
trans = Add1

2. In next frame, Time = 1 following code is called from negative state

[State -3, AfterImage Persist]
type = AfterImageTime
trigger1 = StateNo = 50 || (StateNo = [600,699])
trigger1 = (var(3) = 2 || var(3) = 3) && vel y < -1
trigger2 = var(20)
trigger3 = (StateNo = [700, 715])
trigger4 = (StateNo = [2000, 2010])
trigger5 = (StateNo = [3000, 4999])
trigger5 = StateNo != 3810
time = 2

[State -3, AfterImage Off]
type = AfterImageTime
triggerAll = Time <= 1
trigger1 = StateNo = 2000 || StateNo = 2010 || StateNo = 3000 || StateNo = 3050 || StateNo = 3100 || StateNo = 3150
trigger2 = StateNo = 3200 || StateNo = 3250 || StateNo = 3300 || StateNo = 3350 || StateNo = 3400 || StateNo = 3450
trigger3 = StateNo = 3500 || StateNo = 3600 || StateNo = 3700 || StateNo = 3800 || StateNo = 3810
time = 0

First one is repeated each frame to extend AfterImage time. Second block only on Time = 1 in order to disable previous AfterImage (I think).

I think Ikemen behaviour is logical since in this case second block overwrites time = 2 value of the previous block to 0, which at the same time results in AfterImage being completely removed in the current frame (after all states code is executed). Mugen behaviour seems buggy to me. Probably not worth implementing backward compatibility with behaviour like this (additional delay in execution and who knows if not related to some specific AfterImage parameters combination like is the case with another AfterImageTime bug mentioned in MFG class).

I don't have any experience with working with AfterImage / AfterImageTime sctrls, so maybe I'm missing something.