Are there any global registers?

[beefster09]

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.

[DarkDragon]

Yes.
Though this may change in the future, currently, to allocate a global register, just declare a variable in script scope:

ffc script foo {
  int thisisglobal;
}

ffc script bar {
  void run() {foo.thisisglobal = 2;}
}

[ShadowTiger]

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?

[Saffith]

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.

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.

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.

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.

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?

If I'm not mistaken, the way it is now, any variables declared inside run() or outside of any function are automatically global.

[ShadowTiger]

It is user-defined, though, if that's what you mean.

Ah, yes, it is. :) Thank you Saffith, as always. ^^.

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.

... 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. )

If I'm not mistaken, the way it is now, any variables declared inside run() or outside of any function are automatically global.

... 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.)

[beefster09]

So... Zscript is object oriented. Will you, in fact, be able to change a user-defined variable at any time? Where is it stored?

[Saffith]

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'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?

Will you, in fact, be able to change a user-defined variable at any time?

Yeah, pretty much.

Where is it stored?

Global variables are stored in the global registers (gd0-gd255).


... Why is it that quotes are only italicized if the quotee's name is given? That's bizarre.

[DarkDragon]

Variables declared inside run() should NOT be global; if they currently are it's a bug

[C-Dawg]

They may not be global, but other FFCs on the screen using variables of the same name certainly like to change them.

[Saffith]

Actually, it seems it's not quite as simple as I thought.

ffc script foo
{
	void run()
	{
		int temp;
		temp=this->X;
		Waitframe();
		this->X=temp;
	}
}

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.
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.