94 replies to this topic

[Anthus]

Oh, ComboX() and ComboY() are in std.zh. You probably aren't importing it. The code looks fine.

Huh, I'm not sure why that wouldn't just work. Do you have the "Old-Style Warp Detection" quest rule enabled, maybe? It's in the combo rules.

 

Yeah, that was it, I was trying to import it by itself. It compiles fine with std.zh. I think I'm going to stick with the X,Y method after all though, cause the combo position doesn't seem to work quite as well. I shows Link for one frame on the warp, then he falls into that position. But since the X, Y one works, I can use that.

 

As for the rule, old-style warp detection is off, but I'm using 8-way movement so I'm not sure if that matters. I'd like to use 8-way movement, but if I have to go back to 4, I can, since I'd rather have warps always work without too much trouble. EDIT: Hm, the rule doesn't seem to matter either way, with either movement type. I'm currently testing some stuff, so I might figure it out, lol

[Saffith]

I shows Link for one frame on the warp, then he falls into that position.

It shouldn't make any difference. Did you test it without the run at screen init flag?

I think I know why the warp detection isn't working, now that I think about it. Link will ignore a warp if he starts the screen standing on it, because it might be a cave or stairway he just exited. If you move Link off the warp for a single frame, he'll stop ignoring it. I reworked the script a bit...

Spoiler

ffc script FallIntoScreen
{
    void run(int x1, int y1, int x2, int y2, int x3, int y3, int x4, int y4)
    {
        if(Link->X==x1 && Link->Y==y1)
            return;
        if(Link->X==x2 && Link->Y==y2)
            return;
        if(Link->X==x3 && Link->Y==y3)
            return;
        if(Link->X==x4 && Link->Y==y4)
            return;
        if(Link->X<=0 || Link->X>=240 || Link->Y<=0 && Link->Y>=160)
            return;
        
        Link->Z=128;
        
        int tempX=Link->X;
        Link->X=240-Link->X; // Guaranteed to be a different position onscreen
        Link->DrawXOffset=tempX-Link->X; // Keep his shadow in place
        WaitNoAction(); // And don't let him move that frame
        Link->DrawXOffset=0;
        Link->X=tempX;
    }
}

By the way, looking at your map, it looks like it's possible for Link to fall at the edge of the screen. If that happens, it won't be detected, but it looks like there's another way you could check. If Link didn't fall, he'll always start out standing on stairs, right?
 

int combo=Screen->ComboD[ComboAt(Link->X, Link->Y)];
if(combo==C_STAIRS_UP || combo==C_STAIRS_DOWN)
    return;

Well, except for that first screen, maybe. One special case isn't so bad, though.

[Anthus]

It shouldn't make any difference. Did you test it without the run at screen init flag?

 

I have not.

 

 

I think I know why the warp detection isn't working, now that I think about it. Link will ignore a warp if he starts the screen standing on it, because it might be a cave or stairway he just exited. If you move Link off the warp for a single frame, he'll stop ignoring it. I reworked the script a bit...

 

Hmm, that makes sense. I haven't tried this yet, but I will hopefully later today, or tomorrow. If this fully works, then that will be a huge help, and make it feel a lot more solid, cause a lot of ZC players could probably find that exploit pretty quickly, and break the vertical areas. Using rapidly cycling conveyors was a way to get Link to move with no input onto a direct warp, but like I said, it only worked a little bit, and could still be gotten around. It seems like Link can move in any increment that is less than 8 pixels before triggering a direct warp. Keeping your movement below eight pixels per input would allow you to jump around freely on direct warps, albeit very slowly. What I'm wondering is, does that new script move Link more then 8 pixels, if that actually matters.

 

 

By the way, looking at your map, it looks like it's possible for Link to fall at the edge of the screen. If that happens, it won't be detected, but it looks like there's another way you could check. If Link didn't fall, he'll always start out standing on stairs, right?

 

I noticed that too, in my own testing. I was wondering if there was a way to get around that, since it does look broken for Link to just insta-warp if he falls off of the edge on the edge of the screen lol.

 

Link can enter the screens in 3 ways:

• "Falling" i.e., Direct warping.
• Walking, as in, enter from the side from another screen. 
• Stairs. If Link enters stairs he will be moved up, or down, accordingly. These are the X,Y coordinates used in canceling the fall animation.

[Saffith]

What I'm wondering is, does that new script move Link more then 8 pixels, if that actually matters.

Y'know, now that you mention it, it's not guaranteed to. Really didn't think that through.

This is kind of tricky, actually. Is each floor a separate DMap? A single FFC that carries over between screens could detect if a screen change was a warp or a scroll.

[Anthus]

In the example, they are all on one d-map, but in a real quest, each floor would be its own d-map so they can each have a minimap that shows the floor you're on, and the other rooms on the same floor. The areas in the same region not on the same floor, or level will be grayed out. Lotsa mini-maps to make.

If you want to, you can check out the quest file (Or if anyone wants to check it out). Link will start out in the area with the multiple floors. I don't want you to have to go through too much trouble though, but any help on getting Link to fall correctly through multiple screens is greatly appreciated. Ex1 is jump, I recommend a controller, personally.


EDIT: Since it is not set in stone, I could design the rooms so you simply can't fall at the edge. Placing a tile on the edge of the platforms on the edge of each screen would almost certainly prevent it from happening accidentally. You could, however, still jump from past the barrier back onto a screen, let up, and be on the edge and fall, but you would have to know that was exploitable to be able to use it in a game breaking way.

But as for the direct warp pitfalls, that's a bigger deal, but I'm sure there is some way around it. I also tried replacing the direct warps with a step->next (all) combo, which turns them into sensitive warps (which, iirc, trigger if Link is on them regardless of input*), but this also doesn't work, cause if Link has no input upon entering the screen, he can't trigger step->next combos either. The plot thickens...


*But, I can't use these cause they instantly make Link warp if his shadow touches them.


EDIT 2: Actually, maybe there is a way to make it so Sensitive warps ignore Link if his Z>0. I just want to make doubly sure that even sensitive warps work without input if you fall onto one. I could still use step->next combos on the immediate edge so you don't fall if one of Link's pixels touches the edge of the tile though

[Saffith]

All right, this is kind of weird, but I think it'll work...

Spoiler

ffc script FallIntoScreen
{
    void run()
    {
        int flags=Screen->Flags[SF_MISC];
        
        while(true)
        {
            if(Screen->Flags[SF_MISC]==flags)
            {
                // Still on the same screen
                Waitframe();
                continue;
            }
            
            // Warped
            flags=Screen->Flags[SF_MISC];
            
            int combo=Screen->ComboT[ComboAt(Link->X, Link->Y)];
            if(combo==CT_STAIR || combo==CT_STAIRB || combo==CT_STAIRC ||
              combo==CT_STAIRD || combo==CT_STAIRR)
            {
                // Took the stairs
                Waitframe();
                continue;
            }
            
            // Fell
            Link->Z=128;
            
            int tempX=Link->X;
            if(Link->X>120)
                Link->X=48;
            else
                Link->X=192;
            Link->DrawXOffset=tempX-Link->X;
            WaitNoAction();
            Link->DrawXOffset=0;
            Link->X=tempX;
        }
    }
}

Set up the FFC in the first and last rooms of the area, using the same FFC number for both. Set the carry over and run at screen init flags. In each room, set any number of the script screen flags. It doesn't matter which ones; just make sure every screen on a given floor uses the same flag(s), and that it's different than the floors above and below. The idea is that when it sees the misc. screen flags change, it assumes you've moved to a new floor. On the screens before and after the vertical area, set the no FFC carryover flag to kill the script. It also needs to be set on any screens Link can warp to from that area (not counting warping with F6).

It's a bit convoluted, but I think it'll work perfectly. Unless the player happens to hit F6 in the single frame that Link's HitXOffset is adjusted, but we can worry about that if everything else is good.

[Anthus]

Yes, it works flawlessly, and unless some TASers want to see what frame it offsets Link's X, I think we're good to go

The set-up is also virtually non-existent compared to setting up an FFC on every single scree (which is 16 screen just for this small area) so that is also a huge plus. It works for falling on any position, and always puts Link on the stairs if he used them. Thanks again, this should be submitted to the DB, since it is pretty easy to set up, you can call it something like "ALttP-style falling" or something.

[Saffith]

The offset thing's easy to fix, really. Just stick Link->DrawXOffset=0; at the start of the active global script. It's worth doing; if someone ran into that accidentally, it would be pretty confusing.

[Anthus]

I almost forgot I made this thread. There's a lot of helpful, good stuff in here. Thanks again to the community members who take the time to explain this stuff to a scripting amateur such as myself.

 

I have a few questions about the creation of a few more item modifying scripts. I'll try to make it short, and simple, but, knowing me, we'll see how that goes.

• Can the candle be easily modified to make fire even if there are already 2 fires on screen?
• The same goes for sword beams, and magic wand magic, though this is less important.
• Can the boomerang be made to hover in place as long as the button is held?
• How hard is it to make larger lweapons? If I want an arrow that covers 2, or 3 tiles instead of one, is that a huge pain in the ass?
• What about for other items, like wands (magic), and sword beams?

I have graphics for all of these (but some are rather crude placeholders) so I'd really only need scripts. Any further questions will be gladly answered.

 

I know all of these are possible, so I guess what I'm really asking is, would this be something that someone would be willing to do, if I can give more concise descriptions? Or at least, point me in the right direction if it is simple scripting? The reason I'm being fairly vague is cause I want to gauge if this is something I can put together with help, or if it needs to be reworked. I've been working on something on and off now for about a year, and I'm at the point where I need to consider these things before further planning.

 

Thanks again, for your valuable help.

[Anthus]

Is there a way to have an FCC script remove certain items from your inventory? In my scenario, this would be after getting shipwrecked essentially, and you'd lose a few items. The amount of items taken will be small (less than 8) so I was also wondering if a D0 could be used instead of an array within the script (i.e., D0-D7 are item numbers)?

 

Thanks again. 

[Russ]

That'd be ridiculously easy.

ffc script ItemRemover{
	void run(int item1, int item2){
		Link->Item[item1] = false;
		Link->Item[item2] = false;
		//Repeat as necessary
	}
}

[Anthus]

Thanks so much, I was hoping it was something simple like that.

[Anthus]

This is something I've been kind of hung up on in a project I'm working on. Let's say I have two different maps representing two different times. Think along the lines of the rainy intro in LttP vs the rest of the time. Let's say I have a cave with an item I only want the player to get once, but this cave can be accessed from both (or more) maps. Is there a way to make Link always warp back to the map he came from? This would make it so I wouldn't need multiple versions of the same room to account for different times the player enters it. I always thought this was what "Return Warps" are for, but I seem to not understand how those work entirely.

 

(edit: Alternately, if it is not possible this way, could a script check to see if an item was grabbed from a screen ID, and if so, remove it from other screens marked as D0 values in an FFC script on that screen?)

 

To make it simpler, I just need a way to make sure Link always goes back to the map he warped from, especially if two or more maps warp to the same d-map/ room. I'm not sure if it matters, but it would apply to tile warps, and side warps. If that can't work, then a way to remove items from duplicate rooms (ideally as screen IDs in a D0 thing) would suffice, even if it isn't as clean. (My lack of ZC script knowledge is probably showing )

 

Thanks in advance.

[Saffith]

Either of those would be possible. How about this?

int PrevDMap;

ffc script RememberDMap
{
    void run()
    {
        PrevDMap=Game->GetCurDMap();
    }
}

ffc script ReturnWarp
{
    void run()
    {
        for(int i=0; i<4; i++)
        {
            if(Screen->GetSideWarpDMap(i)==511)
            {
                Screen->SetSideWarp(i,
                  Screen->GetSideWarpScreen(i),
                  PrevDMap,
                  Screen->GetSideWarpType(i));
            }
            if(Screen->GetTileWarpDMap(i)==511)
            {
                Screen->SetTileWarp(i,
                  Screen->GetTileWarpScreen(i),
                  PrevDMap,
                  Screen->GetTileWarpType(i));
            }
        }
    }
}

Place RememberDMap outside the entrance on the DMap you want to warp back to. Place ReturnWarp on the screen with the return warps and set those warps to DMap 511.
As long as you only ever need to remember one previous DMap at a time, you should be able to use it in as many places as you want.

[Anthus]

That should work, you'll never need to keep track of more than one d-map. I'll test it out after work. Thanks again, Saffith .