24 replies to this topic

[SpacemanDan]

Is it possible to have it so that when Link is hit with a fatal hit, he'll hang on by just 1 HP? I need something like that so that I can have battles where you're supposed to 'lose' then an event occurs, but it could also be used as an item to save Link from lethal attacks.

[lucas92]

Like the fairy in LTTP?

I think it's doable only with the newest betas since there are now 4 global scripts slot which one of these is executed when Link dies I think.

[SpacemanDan]

Something like that. But you wouldn't see the death animation. Say you have 10 HP and you get hit by something that does 11 damage. Instead of dying, Link would live with 1 HP, regardless. Though, next hit would result in a game over.

I never knew about the new global script slot. I'll have to check that out. Thanks!

[Joe123]

I'm afraid the new global slot doesn't work like that.
You could script it, the script would probably look something like this:

CODE

global script Slot2{
    void run(){
        int HP;
        while(true){
            HP = Link->HP;
            Link->HP = 1000;
            Waitdraw();
            
            int HPdiff = 1000-Link->HP;
            if(HP-HPdiff < 0) //Link has died, do whatever you want to do
            else Link->HP = HP-HPdiff;
        Waitframe();
        }
    }
}

I don't see why that shouldn't work, but you'd have to test it.

[Radien]

Suggestion: you could make a few "invisible" life gauge pieces and assign the first few hearts to them. Then, rather than create a script that "saves" Link under certain circumstances, make one that kills him if he his health dips into the invisible hearts... UNLESS certain requirements are met (e.g. he has a fairy).

Example: Link starts the game with 13 hearts, but ZC shows him as having 3 (the first 10 are invisible). If his life reaches 10 or below, the script does 10 hearts of damage to him, unless he has a fairy. If he has a fairy, the script instead removes the fairy and performs an animation.

Everyone, does this sound like something a script could do? It depends on whether ZScript lets you use certain criteria...

[Joe123]

Yeah, you can do that with ZScript; I already have.

I've just realised though that the code snippet that I just wrote should get round having to do that at all, if it works.

[SpacemanDan]

@Joe123: Thank you! I'll give it a test run when I get a chance.

@Radien: That's a really interesting idea, actually. Thanks for the advice!

[Radien]

Sure thing, Blaman.

If Joe's attempt succeeded, though, it'd be better to rely on his smarts than my sneakiness. Good luck, Joe.

[Joe123]

Just incase you're still interested, my method doesn't work.

[Beefster]

Radien's way it is... Reminds me of how I had to do my extended heart pieces.

Maybe you could add an onDeath Script slot sometime.

Edited by Beefster, 05 May 2009 - 06:23 PM.

[Joe123]

Yeah, bit of a pain to set up but it works without too much hassle after.

I'd love to but I think it'd require quite a lot of re-structuring the game loop, which I'm definately not up to doing at the moment.

[Fox]

Do you know why it doesn't work? Based on my limited understanding of scripts (and a quick lookup of what waitdraw() does), it seems like it should work, except that the if condition should read like this:

CODE

if(HP-HPdiff <= 0)

The condition should be true if Link's life would become zero, not only once it's less than zero. I imagine the reason it doesn't work would be more complicated than that, though.

The only other point I could see a problem is with putting waitframe after waitdraw, but that's only because I'm not completely sure how ZQuest handles scripts. The way I understand it, waitdraw allows ZQ to finish all calculations for the next frame, but doesn't draw it yet. Then waitframe advances the game to the beginning of the next frame. So the point I'm confused about is waitframe - does ZQuest execute scripts first before its own calculations, or are they executed "simultaneously"?

Probably not being at all clear about that - sorry if I don't make sense.

[Radien]

Probably not being at all clear about that - sorry if I don't make sense.

Makes sense to me. And if I can understand it, I'm sure an actual scripter could. Let's see whether Joe has tried that yet.

I hope it works, but if it doesn't, I guess you can always fall back on my idea to see if THAT works.

[Joe123]

Well, the real issue is that Link's hearts are drawn onto the screen during Waitdraw();.
So technically it does work, it just looks as though Link always has full HP, which is obviously just a little undesirable.

Executing simultaneously isn't possible at any level; as far as I understand a computer's processor can only work out one calculation at a time.
ZC works a little like this:

1. Item Scripts
2. FFC Scripts (starting at #32 and working down to #1 I think)
3. The Global Script
4. --Waitdraw()--
5. The system's functions run
6. The screen itself is drawn (and the subscreen, so it seems)
7. Global functions after Waitdraw
8. --Waitframe()--
9. Sprites and script primitives are drawn
10. Advance to the next frame

That list might not be quite right, but the general idea is there.


Your idea most definately does work though Radien; I've used it before and I started setting it up for aKttH yesterday.

[Fox]

That's why I put simultaneously in quotes. What I mean is that maybe ZC performs functions in an ababab manner, where a is a line of code from function A and b is a line of code from function B.

But yeah, I don't see any way to get this to work script-wise at the moment since there's no way to get between calculating the new Link->HP and drawing Link's life. So the invisible hearts method sounds good to me. And it allows you to do other stuff like fairies and custom game over screens anyway.