So there really are gd0-gd255?
So there really are gd0-gd255?
Avatar: Just who the SPAAAACE do you think I am?
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?
Avatar: Just who the SPAAAACE do you think I am?
Anything declared within the script body, outside of any method, is automatically global. It can be referred to from another script using scriptName.variableName.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.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.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?
Avatar: Just who the SPAAAACE do you think I am?
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote