-
Notifications
You must be signed in to change notification settings - Fork 128
Skirk: .skirk.void_rifts appears stale immediately after charge, allowing an impossible second charge branch #2588
Description
I found what looks like a bug in Skirk's Void Rift handling.
After skirk charge;, the field .skirk.void_rifts does not appear to update immediately. Because of that, the script can enter the charge branch again on the very next loop iteration, which should be impossible in-game.
In practice, this means the simulator can allow two consecutive CHARGE branches based on stale void_rifts state.
A simplified pattern is:
while 1 {
if .skirk.void_rifts >= 2 {
print("CHARGE", " frame=", f(), " vr=", .skirk.void_rifts);
skirk charge;
continue;
}
# other actions
}Expected behavior
After skirk charge;, Void Rifts should be consumed immediately for subsequent script logic.
So on the next loop iteration, .skirk.void_rifts should reflect the consumed state and should not still satisfy the same void_rifts >= ... condition.
Actual behavior
Immediately after skirk charge;, .skirk.void_rifts still seems to have the old value for script branching purposes.
As a result, this can happen:
CHARGEat frame 1055 vr=3CHARGEagain at frame 1085 vr=3
This second charge branch appears to be caused by .skirk.void_rifts still being seen as high enough right after the first charge.
Why this looks incorrect
My understanding is that Skirk's charge attack consumes Void Rifts.
So after skirk charge;, it should not be possible for .skirk.void_rifts to still remain above the threshold required for another immediate charge branch, unless a new rift had already been generated — and even then it should not remain at the previous multi-rift value.
Minimal reproduction idea
The issue can be reproduced with a loop that:
- checks
.skirk.void_rifts - does
skirk charge;when the threshold is reached - immediately re-checks
.skirk.void_riftson the next loop iteration