242 replies to this topic

[Lejes]

I know already that it is possible to put projectiles above overlayers through scripting, might it be an alternate solution to script instead player, item and enemysprites to be below (layer 4) depending on their screenposition?

Yes. You can move any weapon, enemy, or Link's draw offset somewhere offscreen, read their current tile, and then draw it to whatever layer on their actual position. The script isn't hard to write, but you'll have to be very exact with your parameters if you want someone to write this for you. You'd need to think about exactly what "depending on their screenposition" means, possible exceptions, etc.

Also, it is possible to create block-flags to only block projectiles coming from the back? This would perfect the "behind the tree" expirience. I also am back to the block-idea a bit. Is it possible to change the block in a way that wand-magic/candle-flame create a Flame on beeing blocked.

You could read a weapon's direction and block it if it's going the wrong way.

Also if you walk near an edge of a solid combo, Link's position is slightly corrected, is it possible to make this correction for complete quarter-solid combos like diagonal walls? I know this is totally unneeded but it is annoying me. Also of course I want this not to work as global script.

So you want to slide along diagonal walls, Zelda 3 style? An initial draft of this wouldn't be hard, but I don't know what bugs might pop up or how hard they'd be to fix.

A script that makes only certain pits crossable with the ladder and disables the ladder to work otherwise? The Ladder-item can be soo annoying sometimes. Also I have certain problems with solid combos above water, since Link will just ignore them.

You can disable the ladder on a per screen or per DMap basis already, without scripts. There are also Ladder Only combos. I don't know too much about the ladder, really, because I don't like it and don't use it.

I searched for the secret-script ywkls spoke about and could not find anything that woul include my needs. Is there something that works like triggering a secret on activating step 1 and reseting this on activating step 2 to be triggerable again by step 1 and so on? And this should work completly independent from other secrets. Maybe through putting a FFC on a Layer so only this Layer is affected by the trigger?

I think you can do that already with combinations of step->next combos. If you want the combos triggered this way to remember which toggle state they're in when you leave the screen, that would need some kind of script.

[C-Dawg]

Y-sorting ffcs, items, and enemies is something that ZC could do without /too much trouble I think. The only weird thing is this probably doesn't work as intended at a global level, so maybe screen flags or something. Not sure. It's certainly possible though.

 

Well, even if you did, that wouldn't really make much of a difference for those of us who have abandoned the ZQuest engine's method of drawing sprites in favor of using DrawTile for everything anyway

[C-Dawg]

So, I made a script that uses the DrawTile function but respects Y coordinates of layer 3.  Like, you draw the tile in front of trees if the bottom of the tile you're drawing is in front of it.

 

However, you should never use this script because HOLY TITS you get some slowdown.  I don't know what ZQuest is doing here (maybe reading map data from the hard drive or something equally hilarious) but as currently written this script crushes my processor to a teeny tiny crawl!  Perhaps someone wants to efficient it up?

 

EDIT: Newp, it's not ZQuest.  A similar function I just wrote to get solidity from layer 2 (so FFCs can see it) doesn't give me this slowdown.  I probably did a bad when I coded this, somehow...

void DrawTileYAxis(int layer, int x, int y, int tile, int blockw, int blockh, int cset, int xscale, int yscale, int rx, int ry, int rangle, int flip, bool transparency, int opacity){

    // This function draws a tile using the ZScript DrawTile function, but before it does, it compares
    // the area covered by the drawn tile to layer 3 of the current screen.  You have to tell the script
    // which Map in Zquest is being used as layer 3 explcitly.
    // It next checks the bottom side of the tile you're trying to draw.  So, like, for a 2x2 tile
    // it will check the Y coordinates at +32 from where you start drawing.  If there is nothing but 0 combos at
    // that position, the script assumes the tile is IN FRONT OF the layer 3 object, and so it
    // will draw the tiles on layer 4.  If there is a non-0 combo along the bottom edge of the combo, the
    // script assumes that the tile is BEHIND the layer and will draw it on layer 2.
    //
    // Also note that you want this to care about other layers, just point it to what you use for those
    // layers.  I want to preserve other layers for things that are truly above the player always, like
    // foilage in LttP style Lost Woods or whatever.  The idea is to use this script for stuff you can
    // go in front of or behind, like beds, chairs, trees, whatever.

    int layer_3_map_offset = 2;        // Tell the script which maps you use for layer 3 relative
                                    // to the layer 0 map.  I always set layer 2 to be the +1 Map,
                                    // layer 3 to be the +2 Map, and so on.  So, I set this to 2.
                                    // The script assumes that the screen on that map you use for
                                    // layer 3 matches the current screen.

    int layer_3_map = Game->GetCurMap() + layer_3_map_offset;
    int current_combo;
    bool behind_layer_3 = false;

    for(int cur_x = x; cur_x <= cur_x+(16*blockw); cur_x += 8){
        
        current_combo = Game->GetComboData(layer_3_map, Game->GetCurScreen(), ComboAt(cur_x, (y+(blockh*16)-1)));
        if (current_combo != 0) behind_layer_3 = true;
    }

    if(behind_layer_3) Screen->DrawTile(layer, x, y, tile, blockw, blockh, cset, xscale, yscale, rx, ry, rangle, flip, transparency, opacity);
                      else Screen->DrawTile(4, x, y, tile, blockw, blockh, cset, xscale, yscale, rx, ry, rangle, flip, transparency, opacity);
    

}

Edited by C-Dawg, 30 December 2015 - 08:35 PM.

[Gleeok]

Did you mean:

for(int cur_x = x; cur_x <= x+(16*blockw); cur_x += 16){

?

[C-Dawg]

Ooohhh yeah.  With that fix, the code works great!  If someone wants the final version, lemme know.

 

Say, given that logic error, why did the loop EVER terminate?  Did it repeat until it maxed out the int variable type or something?

Edited by C-Dawg, 31 December 2015 - 10:51 AM.

[Saffith]

Yep. If numbers get too big, they wrap around and become negative, so the condition will become false when cur_x is within 16*blockw of the max.

[Naru]

Hey there again, at first a big thank you for all the information. A short question in general, how far can I combine multiple scripts? Can I pretty much just collect them all or are there certain types that contradict each other or kill my PC if used together.

Also I am back to my Layer-Problem... I finally realized that working with layers and the screen position alone won't solve much since a tree is still 32x32 and my former idea would mean to still have the clipping issue while standing on the same position like the lower part of the tree (if this sounds like bad english and should make no sense, I'm sry...)
Now my last idea how this could be solved is to combine FFCs > 16x16 and the position check (I would prefer scrolling being still possible). I use a tree as example so my brain can keep up with explaining. If Link (or an Enemy - just in case I mentioned this not before, the game has to check independent for each sprite) has a position below or next to the lower tree, the whole 32x32 Tree-FFC will be drawn below Link, but the moment Link is completly on the same hight as the upper part (bottom to top 17-32, not touching 1-16), the complete 32x32 tree is drawn overhead.

Is something like this possible? I don't know if such a Thing is makeable, but since my problem is that the positioncheck shall be useable with objects bigger than 16x16 maybe instead of FFCs a non-moving and non-interacing 32x32 foe posetioned through a flag?

Edited by Naru, 17 January 2016 - 12:06 AM.

[Lejes]

FFCs can be bigger than one tile, and they even already have a flag that lets them be drawn over most sprites, that you can freely set and unset with scripts. This should be very easy to do if you just want it to have proper layering with respect to Link, but if you want it to react to enemies and weapons in the room too, it's harder to imagine the logistics of that. Combos and tiles don't operate in a 3D space, so if there's a conflict (like Link being behind the tree, but an enemy is in front of it), you'd have to redraw all three of them so their layers are properly laid out, and that seems tough to figure out how it would even work.

[Naru]

Hmm, bad news, but feared so. Maybe I should limit it to link (since weapons stabbing, slashing like sword are the main-problem with the clipping issue) and just make projectiles always overhead, though I really dislike sprites popping out if you stand behind an object and cannot be seen yourself. Is it at least possible to make the FFC overhead depending on Links Position only for Link and let it be always non-overhead or always overhead for everyone else?

[Edit] Is it possible to also make the sprites for swords and other non-projectil weapons to be always overhead while Links Sprite still is below Layer 3/4 ? This might look odd, but is at least better than clipping trees.

Edited by Naru, 17 January 2016 - 07:11 AM.

[ywkls]

Is it at least possible to make the FFC overhead depending on Links Position only for Link and let it be always non-overhead or always overhead for everyone else?

Like Lejes said, that flag for drawing the ffc can be switched off at your discretion. The problem comes in whenever you have two or more things near the ffc in question. Since there really isn't a way to prevent that without scripting absolutely everything, keeping the ffc where it is always either overhead or not is really not a good solution to the clipping issue.

 

 

[Edit] Is it possible to also make the sprites for swords and other non-projectil weapons to be always overhead while Links Sprite still is below Layer 3/4 ? This might look odd, but is at least better than clipping trees.

 

You can use scripts to create graphics, but lweapons have certain limitations. There are some lweapons that simply can't be made via script. For those, most people use other scripted weapons to fake the interaction of the item and other stuff. But, this would again mean scripting a way for the graphic to be drawn every time an lweapon was generated. Doable, just don't necessarily expect to be able to duplicate the appearance of all the lweapons on your first try.

 

 

Hey there again, at first a big thank you for all the information. A short question in general, how far can I combine multiple scripts? Can I pretty much just collect them all or are there certain types that contradict each other or kill my PC if used together.

 

The only general limitation to using scripts together is if they use the same variables. And even then, there are ways around that. A lot of scripts have to be designed to work together, or bad things happen. The best way to keep such contradictions from happening is to learn scripting. Or create a topic asking for help with a particular script.

 

I'm not sure whether you can kill your computer, though I have heard tales of scripts that can corrupt your Zc.sav file. I don't know what any of those are myself.

 

My best advice is this... the layering issue would take more time to solve than it is worth. Kind of like some other things that can be scripted like Z3 scrolling, solid ffcs and true 3d graphics; they can be done but not easily. I'd advise you to start with something smaller like creating an item, enemy, puzzle mechanic or special effect and work from there.

[C-Dawg]

Hey there again, at first a big thank you for all the information. A short question in general, how far can I combine multiple scripts? Can I pretty much just collect them all or are there certain types that contradict each other or kill my PC if used together.

Also I am back to my Layer-Problem... I finally realized that working with layers and the screen position alone won't solve much since a tree is still 32x32 and my former idea would mean to still have the clipping issue while standing on the same position like the lower part of the tree (if this sounds like bad english and should make no sense, I'm sry...)

 

It makes sense, but I posted a global function that fixes this problem for you on this page.  I had one logic error, since corrected.  If you use this code, then calling "DrawTileYAxis" instead of "Screen->Drawtile" will give you the behavior you need.   Note the comments about how you need to set up the function in ZScript.  Also note that this only works when you're using scripts to draw things, and has no effect on how the game renders LWeapons and so forth.  But, using the engine's built-in capabilities is for chumps anyway, right?

void DrawTileYAxis(int layer, int x, int y, int tile, int blockw, int blockh, int cset, int xscale, int yscale, int rx, int ry, int rangle, int flip, bool transparency, int opacity){

    // This function draws a tile using the ZScript DrawTile function, but before it does, it compares
    // the area covered by the drawn tile to layer 3 of the current screen.  You have to tell the script
    // which Map in Zquest is being used as layer 3 explcitly.
    // It next checks the bottom side of the tile you're trying to draw.  So, like, for a 2x2 tile
    // it will check the Y coordinates at +32 from where you start drawing.  If there is nothing but 0 combos at
    // that position, the script assumes the tile is IN FRONT OF the layer 3 object, and so it
    // will draw the tiles on layer 4.  If there is a non-0 combo along the bottom edge of the combo, the
    // script assumes that the tile is BEHIND the layer and will draw it on the layer you specified in the function call.
    //
    // Also note that you want this to care about other layers, just point it to what you use for those
    // layers.  I want to preserve other layers for things that are truly above the player always, like
    // foilage in LttP style Lost Woods or whatever.  The idea is to use this script for stuff you can
    // go in front of or behind, like beds, chairs, trees, whatever.

    int layer_3_map_offset = 2;        // Tell the script which maps you use for layer 3 relative
                                    // to the layer 0 map.  I always set layer 2 to be the +1 Map,
                                    // layer 3 to be the +2 Map, and so on.  So, I set this to 2.
                                    // The script assumes that the screen on that map you use for
                                    // layer 3 matches the current screen.

    int layer_3_map = Game->GetCurMap() + layer_3_map_offset;
    int current_combo;
    bool behind_layer_3 = false;

    for(int cur_x = x; cur_x <= x+(16*blockw); cur_x += 8){
        
        current_combo = Game->GetComboData(layer_3_map, Game->GetCurScreen(), ComboAt(cur_x, (y+(blockh*16)-1)));
        if (current_combo != 0) behind_layer_3 = true;
    }

    if(behind_layer_3) Screen->DrawTile(layer, x, y, tile, blockw, blockh, cset, xscale, yscale, rx, ry, rangle, flip, transparency, opacity);
                      else Screen->DrawTile(4, x, y, tile, blockw, blockh, cset, xscale, yscale, rx, ry, rangle, flip, transparency, opacity);
    

}

Edited by C-Dawg, 18 January 2016 - 05:02 PM.

[C-Dawg]

And if you want to draw different FFCs this way, here's a function that does that, too.  Note that I haven't compiled this yet; just coded it up over break at work.  Might work, might not!

 

int DrawTileYAxis_FFCs(ffc this_ffc, int layer, int x, int y, int tile, int blockw, int blockh, int cset, int xscale, int yscale, int rx, int ry, int rangle, int flip, bool transparency, int opacity){ 
 
// This function draws a tile using the Zscript Drawtile function, but before it does, it
// compares the Y location of the ffc you specify to all other ffcs.  It will try to adjust
// the layer so that the DrawTile gets drawn on a layer above nearby ffcs that have
// lower Y axis, i.e. are further “up” the screen.  
//
// This code assumes that all the FFCs you use are not displaying combos, but instead
// are using DrawTileYAxis_FFC() themselves -- and all calling the same layer -- so that
// the function can sort out who is drawn where.  So, for example, you could have all
// your FFCs call this function to layer 1 or 2 and then up to 6 of them should be able to 
// overlay in the right way.
 
int TOLERENCE = 32; // The proximity of the square, in pixels, around each
// FFC that you want to use to check for collisions using
// this code.
 
// Note that you could use one of the FFC script variable fields to identify the size
// of each FFC's collision box instead ofimposing a default tolerence.  Might be better.
// This would require very complicated set-up, though, so I leave this to you to look at.
 
// Look at the other ffcs and consider whether the squares defined by
// the TOLERENCE variable around them intersect.
 
int number_of_ffcs_behind_this = 0;
 
for(int i = 0; i <= 32; i++){
 
current_ffc = Screen->LoadFFC(i);
if(current_ffc != this_ffc){
 
// Calculate size of areas to check for collision.
 
int first_x1 = (this_ffc->X + 8 - TOLERENCE/2);
int first_y1 = (this_ffc->Y + 8 - TOLERENCE/2);
int first_x2 = (this_ffc->X + 8 + TOLERENCE/2);
int first_y2 = (this_ffc->Y + 8 + TOLERENCE/2);
 
int second_x1 = (current_ffc->X + 8 - TOLERENCE/2);
int second_y1 = (current_ffc->Y + 8 - TOLERENCE/2);
int second_x2 = (current_ffc->X + 8 + TOLERENCE/2);
int second_y2 = (current_ffc->Y + 8 + TOLERENCE/2);
 
// Check for collision
if( first_x1 < second_x2 && 
first_y1 < second_y2 &&
first_x2 > second_x1 &&
first_y2 > second_y1 
 
){
 
// Increase variable for layer if the FFC is behind it.
if(this_ffc->Y > current_ffc->Y) 
number_of_ffcs_behind_this++;
 
} // end of collision check
 
} // end of if(current_ffc != this_ffc)
 
} // end of for loop
 
// At this point, number_of_ffcs_behind_this should contain exactly what it 
// says.  So, the code will increment the layer that this FFC is drawn on 
// accordingly.
 
layer += number_of_ffcs_behind_this;
if(layer>6) layer = 6; // Let's not draw this above layer 6 
// so we can still control what it is drawn
// below in the editor to some extent.
 
Screen->DrawTile(layer, x, y, tile, blockw, blockh, cset, xscale, yscale, rx, ry, rangle, flip, transparency, opacity);
 
 
}

[Naru]

Thank you, will test them out, though not before my tests/exams "schriftliche Prüfungen" are over.

BTW, is it possible to make the subscreen pop up immediately? I prefer using the active subscreen to change weapons but it takes forever to scroll up and down.

[cavthena]

Only with scripts as far as I'm aware. Subscreens freeze all scripts while open so you would have to make your own from scratch.

[Naru]

Short Question, since I am far away from finishing anything and 3.0 is announced, would it be wise for me (complete newbe also regarding scripting) to just drop the whole scripting stuff for the time and just wait till the new version is out?