So there really are gd0-gd255?
Printable View
So there really are gd0-gd255?
Yeah. You can access them using precisely those names in ZASM. In ZScript, you can't access them directly; you just create a global variable, and the compiler will find a place for it. Since you don't know what it'll pick, it can be dangerous to mix ZASM and ZScript in a single quest.
So how do you declare a global variable? Will it save when you save your game? Can you access local variables directly using ZScript?
Anything declared within the script body, outside of any method, is automatically global. It can be referred to from another script using scriptName.variableName.Quote:
So how do you declare a global variable?
This may change, though.
... I think so, yeah. I'll have to check and make sure, but I think they're saved.Quote:
Will it save when you save your game?
I'm not sure I know what you mean... That's pretty much the only way you would access them.Quote:
Can you access local variables directly using ZScript?
I'm very interested in this bug. When Saffith's sample script is compiled, temp will be stored on foo's stack. Since each script SHOULD have a separate stack, that two script's local variables are interfering with each other indicates something has gone horribly wrong at runtime.
Could somebody take two scripts which are known to interfere with each other, and pare them down to a minimal set of scripts that still exhibit the bug? As soon as we get two SMALL scripts that illustrate the bug, we need to look at the ASM dumps and determine if the bug is both a compile-time and runtime bug or just runtime.
This is about as small as I can manage.
I'm fairly certain it has something to do with this. If I avoid it, there's never a problem.
I compile those, attach foo to FFC #1 and bar to FFC #2, and it prints the position of #1 twice.Code:ffc script foo
{
void run()
{
int var=this->X;
Trace(var);
}
}
ffc script bar
{
void run()
{
int var=this->X;
Trace(var);
}
}
Also, if I only use one of those and attach it to both FFCs, I get the same output.Code:foo
SETV d2,0
SETR d3,REFFFC
PUSHR d3
PUSHR d2
SETR d4,SP
PUSHR d4
SETV d2,14
PUSHR d2
SETR d6,d4
ADDV d6,0
LOADI d2,d6
PUSHR d2
GOTO 34
POP d4
SETR d6,d4
ADDV d6,1
STOREI d2,d6
PUSHR d4
SETV d2,26
PUSHR d2
SETR d6,d4
ADDV d6,1
LOADI d2,d6
PUSHR d2
GOTO 30
POP d4
SETV d3,0
POP d3
QUIT
POP d3
TRACER d3
POP d3
GOTOR d3
POP d3
SETR REFFFC,d3
SETR d2,X
POP d3
GOTOR d3
bar
SETV d2,0
SETR d3,REFFFC
PUSHR d3
PUSHR d2
SETR d4,SP
PUSHR d4
SETV d2,14
PUSHR d2
SETR d6,d4
ADDV d6,0
LOADI d2,d6
PUSHR d2
GOTO 34
POP d4
SETR d6,d4
ADDV d6,1
STOREI d2,d6
PUSHR d4
SETV d2,26
PUSHR d2
SETR d6,d4
ADDV d6,1
LOADI d2,d6
PUSHR d2
GOTO 30
POP d4
SETV d3,0
POP d3
QUIT
POP d3
TRACER d3
POP d3
GOTOR d3
POP d3
SETR REFFFC,d3
SETR d2,X
POP d3
GOTOR d3
Same ol' ASM.Code:ffc script foo
{
void run()
{
int var=this->X;
Trace(var);
}
}
Code:foo
SETV d2,0
SETR d3,REFFFC
PUSHR d3
PUSHR d2
SETR d4,SP
PUSHR d4
SETV d2,14
PUSHR d2
SETR d6,d4
ADDV d6,0
LOADI d2,d6
PUSHR d2
GOTO 34
POP d4
SETR d6,d4
ADDV d6,1
STOREI d2,d6
PUSHR d4
SETV d2,26
PUSHR d2
SETR d6,d4
ADDV d6,1
LOADI d2,d6
PUSHR d2
GOTO 30
POP d4
SETV d3,0
POP d3
QUIT
POP d3
TRACER d3
POP d3
GOTOR d3
POP d3
SETR REFFFC,d3
SETR d2,X
POP d3
GOTOR d3
Saffith, do you want to forward that quest file I emailed you on to DarkDragon? If he wanders around that quest for awhile (normal cheats enabled) he'll find some examples of the bizzare FFC behavior first hand.
I've added line numbers, some commentary, and split the subroutines off of your ASM dump; if there's a bug in the ASM I don't see it.Code:1 SETV d2,0 ; placeholder
2 SETR d3,REFFFC ; value of the this pointer
3 PUSHR d3
4 PUSHR d2
5 SETR d4,SP
6 PUSHR d4 ; stack is now: 0, this, 254
7 SETV d2,14 ; return value
8 PUSHR d2
9 SETR d6,d4
10 ADDV d6,0
11 LOADI d2,d6 ; d2 is now this
12 PUSHR d2 ; stack is now 0, this, 254, 14, this
13 GOTO 34
14 POP d4 ; SP is popped off of the stack. Stack is now 0, this. d2 holds X.
15 SETR d6,d4
16 ADDV d6,1
17 STOREI d2,d6 ; Stack is now X, this.
18 PUSHR d4 ; Stack is now X, this, 254
19 SETV d2,26 ; return value
20 PUSHR d2 ; stack is now X, this, 254, 26
21 SETR d6,d4
22 ADDV d6,1
23 LOADI d2,d6 ; d2 now holds X
24 PUSHR d2 ; stack is now X, this, 254, 26, X
25 GOTO 30
26 POP d4 ; pops SP off of the stack. Stack is now X, this
27 SETV d3,0 ; NOP
28 POP d3
29 QUIT
30 POP d3 ; pops X off of the stack
31 TRACER d3
32 POP d3 ; pops return value 26 off of the stack
33 GOTOR d3
34 POP d3 ; this is popped off of the stack
35 SETR REFFFC,d3
36 SETR d2,X ; d2 is now X
37 POP d3 ; 14 is popped off of the stack
38 GOTOR d3
What happens if you run two FFCs on the same screen with the following ZASM script:
Code:LOADR d3, REFFFC
TRACER d3
QUIT
You meant SETR, not LOADR, right?
I attached it to eight different FFCs. For the first two, the output isn't entirely predictable. One of them prints #1's X position, and the other one prints 0. It seems as if the order of those two somehow depends on their positions.
For FFCs #3-8, however, it simply prints the numbers 2-7 in order.
Yes, but how do you declare a global variable that can be acessed anywhere in the game?