FFCs don't carryover with FFCs that are ouside the screen.

15 replies · 3,272 views · Started 21 May 2008

Gleeok 21 May 2008, 21:22

Aaah! I just spent 3 hours trying to figure this one out. 😞

this->Flags[FFCF_CARRYOVER]=true; works fine, as does carry over, so long as the FFC is inside the screen it seems. Only explanation I could find using Trace(); and changing some integers to global.

Here's how my FFC works;

It runs along -16y to 0y, then repeats...with some -X action also.
I changed instances of 't' with MOON_TILE to see if it was simply restarting on carry over, but no.

Now that I know what it is it's easy to devise a fix for it,

1) replace this->X,Y with integers, or
2) don't allow it to carry over and make all variables within it global,

but It could be a headache for someone else who runs into this problem.


int MOON_TILE = 39820;
ffc script Bg_moon{
	void run(){
	int delay = 0;int cset = 2;int horiz_delay=0;
	this->X = 0; this->Y = -16;bool shift;
	int t = 39820;
		while(true){
			Waitframe();
			int tx = this->X; int ty = this->Y;
			Screen->DrawTile(1,tx,ty,MOON_TILE,20,13,cset,1,0,0,0,0,true,128);			delay++;horiz_delay++;
			if(delay >= 16){ this->Y++; delay=0;}
			if(horiz_delay >= 32){
				if(this->X > -64 && !shift)this->X--;
				else { 
					this->X++; 
					if(this->X>0){
						this->X=0;shift=false;
					}
					else shift=true;
				}
				horiz_delay=0;
			}
			if(this->Y >= 0){this->Y = -16; MOON_TILE -= 20;}
			if(MOON_TILE < 38740)MOON_TILE=39820;
		}
	}
}

Gleeok 21 May 2008, 21:53

I just realized this may have been intended behavior, perhaps before the ff->Flags[] were added. Also it seems that staying within 16 or so pixels from the screens border works, just not much more than than.

Anyway, just wanted to add getting rid of the this->X 0 to -64 bit got it to carry over just fine.

I'm not really sure it's a bug anymore... >_<

_L_ 24 May 2008, 07:25

Idea: does Carryover work if the destination screen has "FFCs wrap around"?

Gleeok 25 May 2008, 07:01

I'm not sure. :P Having my ffcs 'wrap around' would certainly lead to many more problems as they were explicitly designed to be allowed to leave the borders of the screen. Having "pac man" screens would not only be bad for this game, it would require a complete re-write...and yeah, that's not gonna happen. 😉

Also after re-evaluating this I do think it's a bug. It seems that the script attached to that ffc will just turn itself off, even if it re-enters.
...well I really can't definitavely prove this untill I try a Trace(this->X); but if it looks like a duck...

_L_ 25 May 2008, 13:23

Hmm....

Well, I tried it out with a simple script that loops and is attached to an FFC that has Y=-16 and X=-16... and it still carried over.

So, a test quest is necessary.

Gleeok 27 May 2008, 12:36

Sure thing. One quest coming up;

...

http://fast.filespace.org/Tiamat_AD/p_1s_FFC_CARRYOVERt.qst

The two scripts used are thus;

import "std.zh"
global script test{
	void run(){
		ffc F=Screen->LoadFFC(1);
		F->X=0;F->Y=0;
		while(true){
			Waitframes(20);
			F->X--;Trace(F->X);
			if(F->X<-120){F->X=376;F->Y=-16;Trace(F->Y);}
		}
	}
}ffc script bug_test{
	void run(){
		while(true){
			Waitframes(20);
			Game->PlaySound(Rand(58)+1);
		}
	}
}

Also some very odd buggy points of interest:

-FFCs outside the screen continue to run, but their Data becomes 0...so when they re-enter the screen they are not seen. Not fun when coding a custom patra, or other such effect using Sin, Cos. And,

-The carry-over thing.

Also kind of limits the usage of large ffcs on the left side of the screen.....(wow, I just realised what was wrong with a script I made like 6 months ago..)

EDIT: oops, the =-16 is supposed to be -=16....>_< ...not that it matters, It stopped carrying over way before I got to the Y axis.

C-Dawg 28 May 2008, 18:18

You're reinventing the wheel. I've got a thread on this ... somewhere. FFCs do not carryover if:

1. The FFC is assigned to combo 0;
2. The FFC is outside of the visible screen; or
3. Link changes screens as the result of a windrobe / wallmaster.

Gleeok 28 May 2008, 22:53

C-Dawg wrote:You're reinventing the wheel. I've got a thread on this ... somewhere. FFCs do not carryover if:
1. The FFC is assigned to combo 0;
2. The FFC is outside of the visible screen; or
3. Link changes screens as the result of a windrobe / wallmaster.

You know now that you mention it, I do remember something like this a while back. But the thread seems to be long gone.

Anyway, what if the problem is much simpler than all this? The ffc isn't carrying over not because it's too far off the screen, but because there is a bug that turns that ffcs data to 0 when it leaves the screens boundary, therefor causing the 'null' effect on the carryover state. So even if the ffc re-enters the screen and its data restored to > 1, it still won't carry over. It makes sense.

C-Dawg 28 May 2008, 23:21

What I do is "catch" the FFC when it gets within 8 pixels of the side of the screen and reset it's velocity to 0, it's combo to 1 (invisible) and stick it at (1, 1). Works fine as long as you catch it.

_L_ 29 May 2008, 04:04

Gleeok wrote:http://fast.filespace.org/Tiamat_AD/p_1s_FFC_CARRYOVERt.qst

The FFC continued assailing my aural senses even after it had vanished off the left of the screen... and even after I changed screens.

Gleeok 29 May 2008, 05:24

_L_ wrote:The FFC continued assailing my aural senses even after it had vanished off the left of the screen... and even after I changed screens.

*smacks forehead*

Sorry, I was just able to test out my ffc->Data 0 theory. It seems I am a few minutes late, I apologize. But I have the whole scoop this time! No more cat and mouse, again, I thought the last test quest was enough, but not quite.

Anyway, I give you pudding:

And again going the other direction,

The 7 represents the Data, the other, X location. At -34, or +289, the data switches, and from there stops the carry over.

So that's why the script runs fine outside the screen, but doesn't carry over even when brought back inside the screen or given new data. So you see, Roger Podacter didn't commit suicide....he was m-m-murdered.

I also can't help but wonder if there's some reason why this happens. Doesn't the screen really extend way past 0,256-0,176 anyway, by about that same amount of pixels?

_L_ 01 Jun 2008, 03:48

Gleeok wrote:I also can't help but wonder if there's some reason why this happens. Doesn't the screen really extend way past 0,256-0,176 anyway, by about that same amount of pixels?

Hmm... now that I check the code, it turns out that, no, unless the screen allows wraparound FFCs, they will be deactivated when they proceed 32 pixels off the screen in any direction. My apologies for not realising this earlier.

So... that's it, then?

C-Dawg 01 Jun 2008, 04:11

Is this a bug, or a feature? I've just been scripting around this and I don't see a huge reason to change it if the feature is doing something important.

jman2050 01 Jun 2008, 16:54

It was done intentionally so that FFCs with acceleration/velocity information don't go flying into infinite space. 32 pixels seems much too short though, seeing as at the time I hadn't anticipated FFCs being used the way they're used now.

Also note that the wraparound occurs at this 32 pixel boundary as well.

Gleeok 02 Jun 2008, 04:45

jman2050 wrote:
Also note that the wraparound occurs at this 32 pixel boundary as well.

Ahh...So this might give enough leeway for some workarounds then. It just might work. Thanks.

Also the term "ffcs wrap around" is kind of misleading at first. I had thought that meant instantly when one leaves the screen.

zcAmazing 12 Aug 2008, 04:06

'Not A Bug' thread moved from quarantined to exterminated. Dark Nation (or other developer), how am I doing? Reply only in one of the threads I moved.