I doubt waiting will have any benefit. It'll likely be a couple of years, and then who knows how long in Beta, and Gamma phases.
I'm certainly not going to abandon my projects simply because a new version was announced. Beyond that, ZScript will likely retain support from outside sources (in ZC forks). Plus, if the assembly-level stuff is maintained, your codebase will still work, if you play the quest that included it in a newer version of ZC.
I'm going to say at least one, or two years, before '2.60' even reaches a beta, and then more time for '3.0' to be real. We might actually have several 2.5x things in the interim, depending on how things turn out.
On 3.0, while it will eventually come out; there's no firm date as to when. Could be next week, could be 3 years from now. (Or longer.)
On whether to learn scripting now or wait, I'd say you would probably be better off learning now if you intend to learn later. While Zscript has a lot of quirks and limitations; the basic rules of programming are pretty much the same in any language. And since the new language is supposed to be similar to Zscript, learning Zscript would make learning the new one easier.
@C-Dawg- I was looking over your DrawTileYAxis code and trying to figure out how exactly it is different than using another screen to create a layer? Also, not everyone uses tile zero as a blank tile. As far as I can tell, what Naru was trying to accomplish was to make a layer that shifted which layer it was on when Link and the enemies moved above or below it. I don't think your code would do that.
Combo zero should
always be blank with no properties. If tile zero is not blank, that is a design flaw too. Far too many things depend on that, and anyone making a tileset that doesn't, should get a poor rating as a result. I'm actually in favour of making combo 0, and tile 0 forced-blank, and uneditable. I know of one or two tilesets where this is not the case, and every time I use one, I need to edit it to change this problem.
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?
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.
Sure. You can kill a weapon on collision, based on its direction.
//Returns collision between an lweapon and a combo, only if its direction is DIR_DOWN.
//Set checkcoldetection true if you wish weapons without collision to automatically return false.
bool CollisionDown(int cmb, lweapon l, bool checkcoldetection) {
int c[8];
c[0] = ComboX(cmb);
c[1] = ComboY(cmb);
c[2] = ComboX(cmb)+16;
c[3] = ComboY(cmb)+16;
c[4] = (l->X)+l->HitXOffset+l->DrawXOffset;
c[5] = (l->Y)+l->HitYOffset+l->DrawYOffset;
c[6] = c[4]+l->HitWidth;
c[7] = c[5]+l->HitHeight;
if ( checkcoldetection && !l->CollDetection ) return false;
if ( l->Dir != DIR_DOWN ) return false;
return RectCollision( c[0], c[1], c[2], c[3], c[4], c[5], c[6], c[7] );
}
//Returns collision between an lweapon and a combo, only if its direction is 'dir'.
//Set checkcoldetection true if you wish weapons without collision to automatically return false.
bool CollisionDir(int cmb, lweapon l, int dir, bool checkcoldetection) {
int c[8];
c[0] = ComboX(cmb);
c[1] = ComboY(cmb);
c[2] = ComboX(cmb)+16;
c[3] = ComboY(cmb)+16;
c[4] = (l->X)+l->HitXOffset+l->DrawXOffset;
c[5] = (l->Y)+l->HitYOffset+l->DrawYOffset;
c[6] = c[4]+l->HitWidth;
c[7] = c[5]+l->HitHeight;
if ( checkcoldetection && !l->CollDetection ) return false;
if ( l->Dir != dir ) return false;
return RectCollision( c[0], c[1], c[2], c[3], c[4], c[5], c[6], c[7] );
}
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.
I have no idea why you'd want this not to be global. That's the most efficient, and logistically feasible way to handle it, especially if you want to avoid glitches. Other than that, I'll wait to see what other people churn out for this, and I might adapt it, or expand on it.
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.
Sure.
Try this:
I renamed ProximityX/Y to CheckProximityX/Y here, as I have those in the std.zh update pack, but until that's in use, I don't want to post functions from it (so that I can avoid compiler / naming duplication errors).
I presume that you want it to ignore water, too?
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'm going to need to page up through the thread for this. Do you want custom step triggers?
I have an assortment of secret trigger scripts in my files... Send me a PM if you wish.
Again this is mostly to have the background-info what is possible and what not. To really use scripts is actually no something I am able with my actual knowledge...
Hmm.. Implementing them is silly easy, but you can always pester one of us if you want shyte added to a quest.
Edited by ZoriaRPG, 25 January 2016 - 05:04 AM.
)
