[Beta 18] Carryover FFCs that quit still occupy their slot?

[Colossal]

If an FFC is set to carry over and it quits, either by reaching the end of the script or by calling Quit(), FFCs that use that slot will not instantiate at all. One effect of this is that such an FFC will not respawn if it has already quit upon reentering the screen with the FFC unless a screen is entered with the No FFC Carryover flag set or the player F6 -> Continues.

This test quest has a simple placeholder script on the center screen and a carryover FFC that spawns on the north screen, both using the same slot in order to demonstrate this. The other screens terminate the FFC in various ways. Also, Level 4 cheats are automatically enabled upon loading the quest.

Test quest. (http://dl.dropbox.com/u/13242284/carryovertest.qst)

[Gleeok]

Yeah, that is the design flaw for ffcs, being static that is. The rest is actually how they're supposed to work. "carryover" will always override other ffcs even if the other is carryover, or, oddly enough: themselves. :) This is why people usually put carryover ffcs last ie; slots 28+, so they don't mess up other ffc scripts.
If you rely on always continuing with the ffc script on that screen, the here is a trick to not have to manually set up that ffc on every continue screen: Set the global script to automatically warp you to a 'setup' screen for 1 frame then warp back. The ffc will carry over.

..At least unless there is another issue present in the test quest. I didn't look at it.


edit: Forgot to mention, instead of just Quit(); in the ffc script, use this->flags[ FFC_CARRYOVER ] = false; then Quit().

[Colossal]

The main issue is indeed that running an FFC, carrying it over, quitting it, then trying to run it again will fail (unless one of the previously mentioned conditions are met). I know about being unable to use the same slot for FFCs when carryovers are involved and set that up only as a demonstration.

More trouble though: as soon as i tried to add what you mentioned in your edit, ZC started crashing when I hit the transition to the FFC's screen. All I did was edit the script and recompile.

EDIT: Moved the crash report to another thread.

EDIT 2: I tried the workaround you posted and it appears to fix the problem I was having, so it'll do for now. Thanks for that.

[Saffith]

I'm not sure this should be changed. FFC flags are separate from scripts, so it seems to me this is logically correct, even if it's something you're unlikely to do intentionally.

[Colossal]

Since this issue did turn out to have a workaround involving only 1 line of code, it is very minor at most. If it is decided that this behavior won't be changed (understandable), perhaps adding a mention of this behavior and workaround in ZC's documentation would be a good idea? (I wasn't able to find anything about this myself anyway, granted, the wiki isn't complete...)

[Gleeok]

What is confusing about the ffc flags though is the ambiguity of states they represent. Are they screen states, or ffc states, ..or what? If you think of them as an object state then this isn't how you'd expect them to work, but if you think of them as a interconnected network of screen states, then they do. Go figure.
..Remember thouest must recite the works exactly... :P