46 replies to this topic

[Joe123]

Well, you don't have to everything exactly my way at all. It'll just get really messy and very hard to update and things if you keep your code so spread out and whatnot.

No, your item action functions go like this:

CODE

global script Slot2
{
     void run()
     {
          while(true)
          {
               Item1();
               //etc.
               Subscreen();
               Waitframe();
           }
     }
     void Item1()
     {
          //All of item code goes here
     }
}

Well, it stays up until Link presses 'R'. 'Link->Input*' is valid while the button is held, and 'Link->Press*' is valid only on the frame it is pressed.

[Master Maniac]

Ah. So I'd use Link->PressR to close it again?

EDIT: Erm... I need a scripted hookshot now... >.> Apparently the Hookshot can't be created like everything else can.

EDIT2: Alright. I tossed it together and tested it. Got it cleaned of the dumb mistakes. I'm using a Bool value to trigger the subscreen.

Unfortunately, it won't set the value to true, which would cause the subscreen to show up. BUT, one line above the value change, the wavy intro thing does trigger...

CODE

        if(Link->PressR && !Subscreen){   //if Link presses R and subscreen isn't already up...
            WaveOut(1, true);   //This runs without color
            Subscreen=true;     //this doesn't run at all
            FreezeScreen();      //this runs perfectly fine.
        }

Edited by Master Maniac, 27 July 2010 - 09:48 PM.

[Joe123]

Well it looked like you were using the 'R' button to bring up the subscreen in your code?
What that while loop does is it says 'keep running this code, unless Link presses R, in which case stop it'. Which basically says, keep the subscreen up till Link presses R. All of the subscreen code is intended to go inside the while loop.

Using a boolean it'd work a bit like this (might seem more obvious to you?):

CODE

bool done = false;
while(!done)
{
     //Subscreen drawing and things go here
     if(Link->PressR)
          done = true;
     Waitframe();
}

They're basically equivalent.

I thought you were using the kludge thing and moving the items equipped to the B button around?

I think you'll have to post a bit more than those 5 lines if you want me to work out what's wrong.

EDIT:
Oh, and you asked about how to deal with items that upgrade. I'm roughing out some code to make writing subscreens a bit easier for people, and I'm going to include it in that.
It involves using the itemdata pointer which I've never used before.

[Master Maniac]

Here is my basic control code for it all:

CODE

    void Subscreen(){

        SUB_ItemTile[hcpieces]=35329+ Game->Generic[GEN_HEARTPIECES];

        Link->InputStart=false;
        if(!Link->PressR){
            return;
        }
        if(Link->PressR && !Subscreen){   //if Link presses R and subscreen isn't already up...
            WaveOut(1, true);
            Subscreen=true;
            FreezeScreen();
        }
        if(Link->PressR && Subscreen){   //if Link presses R and subscreen is up...
            WaveIn(1,true);
            Subscreen=false;
            UnFreeze();
        }

        if(Subscreen){
//subscreen code goes here

(sorry too early in the morning for me to think properly. I'll try to rewrite it all after I get home from work)

[Joe123]

Hrm ok.
The approach you're taking is the only real way to script custom items properly; lots of 'if' checks that allow the rest of the global script to run every frame. You really need to do this with custom items because other parts of your global script might also want to be running.

However, when you put up a subscreen you generally freeze the rest of the game, so it's actually preferable if the other parts of the global script code doesn't run.
That's why I put the subscreen inside a while loop in the subscreen function; only the subscreen-related code will run at that point and not the other game code. When I have some more time I'll post up some example code explaining what I mean about control flow and things, but I'm just about to go and get my hair cut =P

[Master Maniac]

Hrm ok.
The approach you're taking is the only real way to script custom items properly; lots of 'if' checks that allow the rest of the global script to run every frame. You really need to do this with custom items because other parts of your global script might also want to be running.

However, when you put up a subscreen you generally freeze the rest of the game, so it's actually preferable if the other parts of the global script code doesn't run.
That's why I put the subscreen inside a while loop in the subscreen function; only the subscreen-related code will run at that point and not the other game code. When I have some more time I'll post up some example code explaining what I mean about control flow and things, but I'm just about to go and get my hair cut =P

So wait... if I change the if(Subscreen) to while(Subscreen) it should work?

>.>
*scurries off to test my scripts again*

[Joe123]

Kind of, but that's not exactly what I mean.

[Master Maniac]

Wow. I just figured out what the problem was

Just a bad variable. Anyway... I still can't get anything other than the wave-effect from those WaveIn() and WaveOut() functions, but I think that's because I don't know how to set numbers to colors... >.>

EDIT: also, my pointer is now broken as well... Was working fine before the rewrite though.

Edited by Master Maniac, 28 July 2010 - 04:33 PM.

[Joe123]

Which problem?
Urm...
Look at your palette. The first colour in the top left is 0x00. The next one is 0x01. The first colour in the second column is 0x10, then 0x11. The one at the end of the second column is 0x1F, and the bottom right corner is 0xFF. It works like map screens.

Which pointer is broken?

[Master Maniac]

My pointer function. The selector thing. >.< One sec and I'll post it. Also, thanks for all the help

EDIT: said my post was too long >.> so here, a link to my QPF (which has all of my quest info visible only to admins :3) http://qpf.yuku.com/topic/14/master/1/

Link has my code in it.

Alright. So this is all handled with a drawtile, which goes over xpos, and ypos. Being updated every frame, it SHOULD stay at its assigned position, but...

if the position is 1 and I press left, it sets the position to 3 for one frame, and then to 2. >.<
Same for a few other places. I might just change them to Link->Input though, and add a "Cooldown timer" or something, like what I originally had.

[Joe123]

Ohhh you mean a cursor, 'pointer' has a rather more specific meaning once you move out of ZScript and into C.

Interesting that that would happen, the 'Press' functions are usually pretty good. I am working on some kind of 'template' or 'library' for subscreen scripts at the moment though, so it should make what you're doing a million times easier (/more compact and easier to read).

[Master Maniac]

Ohhh you mean a cursor, 'pointer' has a rather more specific meaning once you move out of ZScript and into C.

Interesting that that would happen, the 'Press' functions are usually pretty good. I am working on some kind of 'template' or 'library' for subscreen scripts at the moment though, so it should make what you're doing a million times easier (/more compact and easier to read).

:O

Will I be able to simply add it into my std.zh? I quite like build 1266... >.>

[Joe123]

No no, just import it as a second header I imagine.

[Master Maniac]

No no, just import it as a second header I imagine.

Even better

Also, changing the Link->Press to Link->Input fixed it. Might be an issue with my current build.
EDIT: Nope. It was adding the cooldown timer that fixed it.

also, selecting the colors like you showed me still doesn't display them, no matter what color I select.

Edited by Master Maniac, 28 July 2010 - 06:01 PM.

[Joe123]

Really? That's weird, it works for me...