Consider this:
ffc script One {
void run(int data) {
while(true) {Waitframe(); Screen->ComboD[90]=data;}
}
}
Attach it to a Carry-Over FFC, and then set data to some value. (I tried it with values >100 and >10000). When the FFC is carried over to different screens, the value of "data" (and thus the combo it produces) changes to something undesirable.
Experimenting with some traces, I obtained some data:
Before carry-over:
Arg 0: 11115. [Only argument used by the script]
Arg 1: 11119.
Arg 2: 11099.
Arg 3: 11103.
Arg 4: 1.
Arg 5: 0.
Arg 6: 0.
Arg 7: 0.After carry-over:
Arg 0: 90.
Arg 1: 11119.
Arg 2: 14.
Arg 3: 29.
Arg 4: 254.
Arg 5: 0.
Arg 6: 255.
Arg 7: 0.
Hmmm... Interesting that the value becomes 90, the subscript for ComboD used in the function.
Hey, is this fixed yet? Because I've got a LttP Red/Blue Gate script in the works that requires this bug to not be present.
I'm having trouble reproducing this bug. L, are you still seeing it?
EDIT: Umm... ah. Based on your comment, I've identified the problem as being caused by the "Script Restarts when Carried Over" flag of mine. A solution is in progress...
P.S: Could you give me some hints as to how to do this? I thought that setting "tmpscr[tmp].pc[i] =0;" during loadscr() would be enough to make the script start over, but it seems to cause this bug as well...
Okay! I forgot to post the conclusion: this isn't so much a bug as a misinterpretation of ZScript variables vs. FFC variables. Bug over!