I just wondered, so I could enhance my frog-finding system.(Like skulltullas)
I heard something like this from the developers, but I don't know if it has been implemented or anything.
I just wondered, so I could enhance my frog-finding system.(Like skulltullas)
I heard something like this from the developers, but I don't know if it has been implemented or anything.
Avatar: Just who the SPAAAACE do you think I am?
Yes.
Though this may change in the future, currently, to allocate a global register, just declare a variable in script scope:
Code:ffc script foo { int thisisglobal; } ffc script bar { void run() {foo.thisisglobal = 2;} }
Hrm. I wish there was a way to differentiate variables between hardcoded non-variables in those vBulletin code tags. For example, "void" and "run" aren't variables, but I'd bet that "foo" and "thisisglobal" are. You'd imagine that such variable names would be absolutely common sense that they're user-created variables, but then again, with me seeing so many variables called "this->" (That exact variable, "this" .. yes.) it's getting hard to tell. I'm no C++ programmer, and they can get rather technical sometimes.
... Wow, that's rather off topic. Sorry. XD Just thinking out loud.
So, any FF script can refer to a global variable if it's already been created by another somewhere else. What determines if a variable will be global or not though? How would you set one up to be global vs a single-script variable?
Technically, foo is the name of the script, which is different from a variable. It is user-defined, though, if that's what you mean.I wish there was a way to differentiate variables between hardcoded non-variables in those vBulletin code tags. For example, "void" and "run" aren't variables, but I'd bet that "foo" and "thisisglobal" are.
this isn't a variable; it's a pointer to the current FFC. Whenever you see this->anything, it's accessing the properties of the FFC that's running the script.You'd imagine that such variable names would be absolutely common sense that they're user-created variables, but then again, with me seeing so many variables called "this->" (That exact variable, "this" .. yes.) it's getting hard to tell.
If I'm not mistaken, the way it is now, any variables declared inside run() or outside of any function are automatically global.What determines if a variable will be global or not though? How would you set one up to be global vs a single-script variable?
Ah, yes, it is. :) Thank you Saffith, as always. ^^.It is user-defined, though, if that's what you mean.
... Aah, so it's hardcoded. So I can never use it to refer to anything but the FFC that's running the script. Stupid question, but can we make it refer to the script too? (I told you this was a stupid question. )this isn't a variable; it's a pointer to the current FFC. Whenever you see this->anything, it's accessing the properties of the FFC that's running the script.
... Hm. L_L' Why run() of all things though. ... I think this is one of those things where I'd have to study ZScript as a whole to understand this concept rather than asking one question at a time related to it. (Sort of like trying to put a puzzle together by randomly placing pieces on the board, hoping it'll form some semblance of a picture, rather than starting from the base piece and working off of that one. Naturally, the latter is better.)If I'm not mistaken, the way it is now, any variables declared inside run() or outside of any function are automatically global.
So... Zscript is object oriented. Will you, in fact, be able to change a user-defined variable at any time? Where is it stored?
Avatar: Just who the SPAAAACE do you think I am?
I'm not entirely sure what you mean. Do you mean, say, to change which script the FFC is running? Or to change the text of the script itself in some way?Originally Posted by ShadowTiger
Yeah, pretty much.Originally Posted by beefster09
Global variables are stored in the global registers (gd0-gd255).Where is it stored?
... Why is it that quotes are only italicized if the quotee's name is given? That's bizarre.
Variables declared inside run() should NOT be global; if they currently are it's a bug
They may not be global, but other FFCs on the screen using variables of the same name certainly like to change them.
Actually, it seems it's not quite as simple as I thought.
If you assign that to two FFCs on the same screen, it should set their X positions to the same value if temp is global. It doesn't do that.Code:ffc script foo { void run() { int temp; temp=this->X; Waitframe(); this->X=temp; } }
I'm pretty sure they're not entirely contained—that was the problem with multiple chaser traps, for example—but they're not simply global, either.
There are currently 1 users browsing this thread. (0 members and 1 guests)