What good is Link->Z?

[Gleeok]

This doesn't seem to do anything useful. I tried setting it in a global script every frame to see if projectiles would 'miss' Link because he was above the sprites, but all that happened was it created two images of Link where the top one was jumping up and down. Adding 1 to Z seems to be the same as subtracting 4 from Y.. :odd: Is there any use for Z in an overhead-view screen?

[_L_]

What do you mean?


while(true) { Link->Z=5; Waitframe(); }

This fixes Link in midair.

Note that replacing the 5 with a 1 will fail miserably, as Link will simply land on the ground in the same frame that it is set.


In closing: conduct experiments with a wide variety of values. Also consider setting Link->Jump while you're at it.

[Nimono]

Well, this ruins an idea I had of using Link->Z to make higher areas of a screen where Link can't be hurt by enemies OR weapons of a lower Z. Why did it have to be this way.... Also, it doesn't make sense for Link->Z to make Link "jump" or be any higher on the screen- Shouldn't that be what Link->Jump does? .-.

[The_Amaster]

I actually had an interesting idea for thru-floor falls, in which upon arriving at the new screen his Z is set rather high, and he falls down onto the destination.
A fairly simple modification of Joe or Matthew's pit/water scripts in which you warp to a different screen and set the Z, while beyond me, is certainly feasable
*nudge nudge*

[_L_]

That's a good idea, but to replicate L to the P's behaviour you'll need to stop Link from moving until he lands.

[Gleeok]

I have to agree with Pikaguy. I messed with it for a while untill Link was over enemies but still was getting hit by projectiles..? But it also decremented Link's Y to acheive those results (there is still a duplicate Link..bug maybe?). I think I'm getting alot of conflicting code in the process too. It's making it hard to utilize Z in a way that I would like.

Basically what I'm trying to do is make Link higher than eweapons ( eweapon->Damage=0; doesn't work :( ) without moving his x,y or making him 'jump'. ...Possible?

[_L_]

Didn't a jman2050 add some Link hitbox variables in build 776? Maybe those will do.

[Gleeok]

Didn't a jman2050 add some Link hitbox variables in build 776? Maybe those will do.

Aaah, yes That's what I've been trying to do! but I can't get a peep out of him about the commands to access these variables. ...You wouldn't happen to know a little somethin' somethin' about how to go about doing this, would you?

[_L_]

Well, I might.

(clicky-clicky)

...Well, it looks to be some variables called Link->ColWidth ("collision width") and Link->ColHeight ("collision height"). Y'know, I think I might rename them to HitWidth et. al. in the next build, because "Col" is a bit ambiguous.

Also, Link->ColDepth, which controls, ahem, Z-axis collisions. Normally that's 12, which is just high enough for Z-axis flying Peahats to hit him, but just low enough for his sword (Z-axis depth 8) to not hit them in return.

[Gleeok]

Oh yeah, that's the stuff. Thank you.


Y'know, I think I might rename them to HitWidth et. al. in the next build, because "Col" is a bit ambiguous.

That makes sense to me.

This is sort of odd, in an obvious sort of way, but what exactly does Link->Col do? I mean Link doesn't collide with enemies or sprites, it's the other way around. eweap->Col works fantastic, and as far as enemy hit detection goes; when Link collides with an npc it is Link that gets damage, not vice-versa. So setting Link->Col doesn't seem to do anything when set to a lower number, which makes sense in this case, assuming you have smaller sized sprites in play, which are likely to lead to undesired results when combined. I guess It's mainly for future use.

In any case, I've got the entire hit detection grid set up just how I wanted it. Thanks again.

..And jman: friggin awesome man.