A couple of questions

[Saffith]

A few things I'm wondering about...

What are the data that pointers point to (Link->X, etc.) called? I've seen them called "arguments," but that's sort of an odd name for them...

Are there any plans to implement continue and break, with or without labels? And what about ?: and switch?

Will it be possible in the future to define numbers in hexadecimal or binary? Seems like it'd be useful, what with the bitwise operators. Speaking of which, are those all as one would expect? I noticed they're present, but I haven't exactly tested them yet.

[DarkDragon]

I call them data members, as per C++. They are converted to arguments when compiled into assembly, so that also makes some sense.

The bitwise operators work, but in a quirky way: since the fixed point numbers have a fixed number of DECIMAL digits, and not BINARY digits, there is no way to implement bitwise operators that work as expected for both fixed-point numbers and integers. Thus, currently, they operate as expected on the integer part of a number, and ignore the fractional part. Thus 3.5 & 2.2 = 2.

I'll address your suggestions in decreasing order of my enthusiasm to implemented them:

Hexadecimal and binary numbers are easy to implement and will be included next time I update the language (which may or may not be before b13.)

Continue and break are slightly pain in the ass since they are context-sensitive, but will probably also be included. I'm not sure what you mean when you say "with labels."

Switch is a pain in the ass because, thanks to fall-through, scoping is a nightmare. It also requires two passes to generate code for it. I'll include it some day when I'm feeling ambitious.

The ternary operator is a royal pain in the ass. Consider the following three uses of it, where b is some bool:
1. int x = (b ? 0 : 3);
Here ?: is being used as an rval, and this case is easy to implement.
2. (b ? Link->X : this->X) = 3;
Here ?: is being used as an lval, which is trickier to implement, but not terribly so.
3. (b ? Link : this)->X = 3;
This is the killer: in this case ?: is introducing type ambiguity and would require me to reimplement large parts of the type system to implement.

Thus ?: will probably not be added in the near future.

[Saffith]

All right, thanks. Good to know.

Continue and break are slightly pain in the ass since they are context-sensitive, but will probably also be included. I'm not sure what you mean when you say "with labels."

It's a Java thing. Not used very often, but convenient when you need it. In this code:

breakHere: for(int i=0; i<5; i++)
{
    for(int j=0; j<5; j++)
    {
        break breakHere;
    }
}

The break statement would break out of the outer loop rather than the inner one.

[DarkDragon]

Ah, I see. For now break and continue will emulate their C counterparts, as I'm hesitant to add labels to the language.

[Saffith]

One more thing: is there a way to pass data from one FFC to another using either registers or functions? ffc2->d[0]=5 or ffc2->init(x, y, z) or something like that?

[DarkDragon]

You can call another ffc's functions, no problem. I'm not sure what you mean by passing data... could you give me an example of what you're trying to do?

[Saffith]

Well, it's about like this...
One FFC is an enemy, and the other is a projectile it fires. When the enemy decides to fire, it needs to give the projectile some information on how it should move. It's much harder for the projectile to figure this out on its own, and controlling its movement from the enemy's script would also be difficult.
I can think of a couple of ways to fake it, but I'd rather not if I don't have to.

[DarkDragon]

For now, use a global variable or (better) a screen variable. I'll think about the problem but it boils down to a limitation in the ASM - though you can change FFC-specific variables of another FFC, it's not currently possible to set generic script variables like D0 of another script.
For good reason:
[begin technical ASM discussion]
Each script currently has variables FFCREF and ITEMREF, which contain an integer used to index into the screen's list of ffcs and items, respectively, whenever an ffc or item variable is to be read or modified. For instance, the code

SETV FFCREF, 1
SETV X, 20

would set the screen's second ffc's x position to 20. ZScript uses these REF variables internally to support item and ffc "pointers" when using LoadItem, LoadFFC, CreateItem, etc. They're also used to support the "this" pointer.
But what would happen if we added a SCRIPTREF variable too? We could then switch to using a different script's D0 registers, stack, etc, which sounds great until you realize there's now no way to go back... when using FFCREF, you can back up the old value of FFCREF into a register or the stack, change to the FFC you want to modify, then restore FFCREF to point to your own FFC; with SCRIPTREF you'd have no way of doing this.
[/end technical ASM discussion]

Here's how I would design a solution to your problem:

ffc script shooter {
//The first parameter is the screen data register reserved by this script. All instances 
//of this script can share this index.
//The second parameter is this particular instance's unique integral ID.
   void run(int index, int id)
   {
      //stuff...
      //now it's time to shoot a projectile
      Screen->D[index] = Screen->D[index] | (1<<id);
   }
}

ffc script projectile {
   void run(int index, int id)
   {
      while(true)
      {
         while(!(Screen->D[index] & (1<<id)))
            Waitframe();
         //fire away!
         //now reset the projectile
         Screen->D[index] = Screen->D[index] ^ (1<<id);
      }
   }
}

[Saffith]

All right. I can get by with screen variables. Thanks.

[jman2050]

Do remember that the order of the FFCs is important. FFC 1's script will be run before the second, and so on and so forth. Just keep that in mind.