ffc->Misc[], etc.

[pkmnfrk]

If I understand this correctly, we now have a means of inter-object communication. This is awesome! This means we can create (for example) a boss with two heads that act independantly, but can create combo attacks, or something.

There is one tiny thing I would like to ask for, if I may. That is, the ffc->Script variable, which returns the script slot assigned to the FFC. This would allow us to identify an FFC, no matter what slot it's in. This is most useful for carry over FFCs, and FFCs that are "general purpose" (i.e. may be used on more than one screen).

So, we could do something like this:


ffc script Crystal {
int tog;
while(true) {
if(<Link hits me with the sword>) {
tog = (tog + 1) % 2
for(int i = 1; i <= 32; i++) {
ffc f = Screen->LoadFFC(i);
if(f->isValid() && f->Script == 24) {
f->Misc[0] = tog;
}
}
}
}
}

//this script is in slot 24
ffc script Barrier {
void run() {
while(true) {
if(this->Misc[0] == 0) {
//no barrier
} else if (this->Misc[0] == 1) {
//barrier
}
}
}
}

This is just off the top of my head, and the idea needs work, but yeah. It would be awesome.

[Joe123]

Yes. I don't know whether I'd be able to do that though.

The use I was thinking of was more along the lines of marking a weapon in the global script after you've loaded it, so you can check for it and load that one next frame and you don't need to keep it loaded in an array or something.
Although obviously you could do something like that, provided we have ffc->script in the future yeah.

[Gleeok]

Does each individual object have a seperate array, or are they shared for each type? Like ffc->Misc[] versus ffc1-32(this)->Misc[]?

[Joe123]

Each one has it's own array.
While it makes sense for the ffcs to have a linked one, it would be illogical for the weapons and items to have a linked one.

Besides, if it was linked like that you could just use a global variable.

[Joe123]

Ah, I've just realised that these actually don't work how I wanted them to...


EDIT: Or maybe I just wrote the code wrong.
Hrm.

EDIT2: Infact I did write the code wrong.
Bugger.

At least I know why it's wrong though, eh?


EDIT3: I wonder where it'd be a good place to initialize the variables I made. Hrm....

EDIT4: Aha, constructor.

[Joe123]

Hrm.
Looking at this, I think it might be useful to have the ffc's miscellaneous values save with the quest file. Obviously the other object's ones wouldn't.

Does that seem like a useful functionality?
Or should they re-set each time Link enters the screen?

[pkmnfrk]

There are arguments for and against that.

To use them like I proposed at the start of this thread, then I would definitely want them to be reset when the script starts.

However, if you want to just store miscellaneous data, then you probably want them to be saved.

As such, I think you should save them. It's possible for me to manually reset them at the beginning of my script, whereas it's not possible to manually save and restore them.

[Joe123]

Mm, that's the thought process I went through too.

You can reset them if you don't want them saved, but you can't save them if they're not being saved.


EDIT:
Actually I've decided they're not going to save with the file.
I think I'd rather avoid the chance of being to blame for making another save-file crippling build.
Adding one extra byte to the size of the save file was significantly easier than adding 32x8 longs to each screen saved.

[Joe123]

OK, they work now =)