User Tag List

Results 1 to 3 of 3

Thread: Brainstorming around a problem

  1. #1
    Lynel
    ZC Developer
    pkmnfrk's Avatar
    Join Date
    Jan 2004
    Location
    Toronto
    Age
    37
    Posts
    1,248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    3,146
    Level
    18
    vBActivity - Bars
    Lv. Percent
    11.37%

    Brainstorming around a problem

    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)



    However, my problem is this:




    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:

    Code:
    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.
    Tale of the Cave - a web comic - Updates Monday, Wednesday, Friday
    ZC Tutorials - Tutorials and Script Library - Updated July 30, 2008
    ZeldaGuard - Corruption in my save files? It's more likely than you think!
    I do script requests!

  2. #2
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,826
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,962
    Level
    33
    vBActivity - Bars
    Lv. Percent
    26.56%

    Re: Brainstorming around a problem

    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?
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #3
    Lynel
    ZC Developer
    pkmnfrk's Avatar
    Join Date
    Jan 2004
    Location
    Toronto
    Age
    37
    Posts
    1,248
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    3,146
    Level
    18
    vBActivity - Bars
    Lv. Percent
    11.37%

    Re: Brainstorming around a problem

    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.
    Tale of the Cave - a web comic - Updates Monday, Wednesday, Friday
    ZC Tutorials - Tutorials and Script Library - Updated July 30, 2008
    ZeldaGuard - Corruption in my save files? It's more likely than you think!
    I do script requests!

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social