Brainstorming around a problem

[pkmnfrk]

Ok, so, like, I've made a custom block-trigger script that will trigger only if the "right" block is placed upon it. If it's right one, then the block is made un-movable, regular block trigger style. If not, then nothing happens, and you can keep pushing. (The ideal behaviour would be that it won't let you push it on to the wrong one at all, but I haven't figured out how to do that yet)

http://zctut.com/zelda006.png

However, my problem is this:

http://zctut.com/zelda007.pnghttp://zctut.com/zelda008.png
http://zctut.com/zelda009.pnghttp://zctut.com/zelda010.png

That's right, the combo that represents the trigger (actually an invisible ffc) is being over written by the under combo!

This isn't an issue for normal block-triggers, since any push-block will do.

The first thing I started with was having the block-trigger graphics be on the FFC itself, instead of a normal combo. This worked fine, except that the FFC covered up the block when it wasn't moving (moving blocks are on Layer 2.5, yes?).

So, then I changed it to what we have now. Different problem, results as described above.

So, I thought about scripting solutions. The script itself is this:


ffc script BlockTrigger {
void run(int cmb, int D, int v) {
int o = 0;
while(true) {
if(Screen->ComboD[ComboAt(this->X, this->Y)] == cmb) {
Screen->D[D] = v;
Screen->ComboF[ComboAt(this->X, this->Y)] = 0;
Screen->ComboI[ComboAt(this->X, this->Y)] = 0;
} else {
Screen->D[D] = o;
}
Waitframe();
}
}
}

I could make it so that it constantly writes the trigger combo to its position until the right block is pushed, but then that would erase incorrect blocks.

So, I guess that I either need to figure out how to prevent the wrong block being pushed onto it, or how to restore the tile to its former glory.

Or, I guess, how to make FFCs appear on Layer 1.

[Gleeok]

Okay, this reply is going to probably a messed up mash of random thoughts..anyway;

What if instead of placing the ffcs at the block triggers location, you placed them at 0,0, then used arg3-4 to assign the x,y of the trigger. ..or, maybe use a drawcombo to use as trigger graphics? Say, if there are no blocks within 16 pixels of a trigger then you drawcombo on layer 1 over the stupid way in which zc handles block undercombos.

Perhaps placing the colored squares on layer 1, and using each ffc (or DrawCombos) to attach themselves to each block's x,y every frame so it appears the block is on layer 2.5.

Or simply check each layer 0 square, store it in an array, then if it changed via undercombo then change it back if it is U_COMBO_NULL, or something...

Well did that help?

[pkmnfrk]

I think I will use the DrawCombo option, since it's the easiest to implement. Although, I can't help but think that this could easily be solved by giving us the option to choose which layer an FFC is drawn on. Or, by giving us the ability to read the combos on other layers.

Hmm. Crazy thought. If we use Game->SetComboData to change (say) the first layer's combos, will that be reflected immediately, or only on the next screen load? If so, then that might be the best solution.