A new target logic is needed?

[LostTemple1990]

in patch 9.15 the spell 125 was set to

[125]={
        {type="nuke", target="random-enemy", damageATK=60},
        {type="aura", target="random-enemy", modDamageDealt=-50, duration=1},
    },

though it works well in sim but there is a problem this spell select a random-enemy and deal the effect 1 and 2 to the same target which is selected but in sim,it seems to run twice for this spell when it casts (first for the first effect,and second for the next) It seems that a new target logic is needed if keep dividing spell effects by effect index in real log Perhaps it may change to

[125]={    target="random-enemy",
        [1]={type="nuke", damageATK=60},
        [2]={type="aura", modDamageDealt=-50, duration=1},
    },

which target is the key of the original table like the key firstTurn does

[LostTemple1990]

after checking out all the random-target effect, it seems that only this spell causes two effects on a random target

[zealvurte]

As I changed things as stated in https://github.com/LostTemple1990/Issues-of-self-debugged-VenturePlan/issues/8#issuecomment-915915975, I have the following outcomes:

1. When using a forklimit of 1 with no oracle, the random targets could be wrong and thus incorrect regardless of this.
2. When using a forklimit of 0 with no oracle, the range of the checkpoints across all forks will be correct, but it will be inefficient and inaccurate due to the quantity of incorrect forks.
3. When using an oracle, the oracle will always gets the right target for each effect, so will be correct.

I had wondered about how such a scenario would work when I was working through the data, as it never came up before. For the sake of scenario 2, I agree that the target logic should be adjusted to reuse the same random target across all effects for a spell, which will drastically reduce the number of forks needed.

Off the top of my head, implementation could be as simple as:

1. In mu:cast, do self.randomTargets[sourceIndex..'-'..sid] = nil or similar, to reset any saved target.
2. In mu:qcast (where I've already rewritten a lot), add a new condition after the forkTargets checking that is similar to if self.randomTargets[sourceIndex..'-'..sid] then forkTarget = self.randomTargets[sourceIndex..'-'..sid] end, to use an earlier effect's target if it already exists.
3. In mu:qcast (again), change some conditions for forkTarget to only use it if the forkTarget is truthy but not true, to handle cases where there was no valid target on the earlier effect, so it should still skip trying to get a new target and forking.
4. In mu:qcast (still), do self.randomTargets[sourceIndex..'-'..sid] = tt or true or similar within the forkTarget handling, to save the target even if there was no valid targets.