15 replies to this topic

[justin]

As the title suggests I'm having difficulties with using Screen->SetSideWarp.

Which directions do the warp argument point to?

Or does 0=A, 1=B, etc?

If the latter is correct then does the Side Warp need to be already set for SetSideWarp function to work? In that it can only change a side warp?

 

 

edit to add:

i see a lot of scripts use the function to set the sidewarp, and then immediately trigger the side warp by placing an Auto Side Warp combo on the screen.  My purpose of using the function is to change the sidewarp of the screen for when the player goes that way off the screen.  The side warp isn't set previously, if the script doesn't run the player would just walk to the next screen, but when the script runs the player walks off screen to a different screen.

Edited by justin, 12 November 2014 - 10:44 PM.

[Jamian]

Yes, 0=A, 1=B, etc.

 

I have something like that set up the way you want and it's working fine. However, I do already have a sidewarp there anyway, so it doesn't create a sidewarp, it changes it. The problem is likely that if you didn't set up sidewarps then you also didn't tell ZC which exit was A, which one was B, etc.

 

Try setting up an original sidewarp so it does what ZC would do anyway (a scrolling warp to the next screen) and see if that solves the problem, it should.

Edited by Jamian, 13 November 2014 - 07:15 AM.

[justin]

Ya, I did some playing around and figured that was how it worked. My script works just fine when the side warps are pre set, and it just needs to change them.

I've been trying to modify a Day/Night script by Moosh (basically totally rewritten by now), so that the time change happens when you change screens, not instantly as his script did with a pit warp. I don't like the respawning of enemies with his method. The solution of selecting sprites carry over in warps on every screen is tedious, and I'm sure not without some other issue. Plus things like cut tall grass suddenly are no longer cut.

Then again, setting side warps for every screen is equally (if not more) tedious.

Would be cool if SetSideWarp could actually set the side warp instead of just changing it...

[MoscowModder]

Actually you don't need to set up side warps beforehand. Technically they are all "set up" by default.

[justin]

Actually you don't need to set up side warps beforehand. Technically they are all "set up" by default.

Please explain...

[MoscowModder]

SetSideWarp() does everything necessary to make a side warp work. It makes no difference what's set up in ZQuest beforehand.

 

Now, if you want to trigger the side warp, you'll need to place an Auto Side Warp A (or B, C, D, or Random) on the screen (or on an FFC). You can easily do that by script, though. For example, an FFC script can do this->Data = CMB_AUTOWARPA (with a constant you set beforehand).

[justin]

but i don't want to autotrigger the sidewarp.  i want the sidewarp to change for when the player walks off the screen.  it doesn't seem that this is possible.

[MoscowModder]

Oh, I see what you mean. I guess I'd never even thought about that.

 

It does seem strange that ZScript doesn't have a function to apply a side warp to a screen side.

[justin]

would it be possible to detect when the player is about to walk off the screen, and which "side warp" they'd be triggering, and in that moment place an AutoSideWarp combo down to trigger that same sidewarp?

 

i'm thinking that is possible, i'm just not good enough with scripting to know the best way to do it...

[MoscowModder]

With a scrolling warp, this becomes really difficult. With a non-scrolling warp, you could do something like this

if(Link->Y == 0 && Link->InputUp && warpSet)
{
    myFFC->Data = CMB_AUTOWARPA;
    Link->Y = SCREEN_HEIGHT - 16;
    Waitframe();
}
// Ditto for each other direction

[Jamian]

Here's an untested idea for you, justin: have something in the global script to detect if the screen is scrolling (is Link's action LA_SCROLLING?) and if so, and if it happens on a dmap which takes the day/night cycle into account, then do the switch.

[justin]

Here's an untested idea for you, justin: have something in the global script to detect if the screen is scrolling (is Link's action LA_SCROLLING?) and if so, and if it happens on a dmap which takes the day/night cycle into account, then do the switch.

 

ya, that's kinda the idea of the little code snippet MM wrote in the post above yours.  he was just detecting being on the screen edge, and keyboard input in the direction of the edge, then triggering an autowarp combo for that direction.

 

would detecting LA_SCROLLING still allow placing and triggering an autowarp combo, or would it already be too late?

[MoscowModder]

Well, if you go the LA_SCROLLING route, you could wait for the scrolling to finish then use Link->PitWarp(destinationDMap, currentScreen) for instantaneous transition. I think that's probably a much better way to go.

[justin]

Well, if you go the LA_SCROLLING route, you could wait for the scrolling to finish then use Link->PitWarp(destinationDMap, currentScreen) for instantaneous transition. I think that's probably a much better way to go.

 

i like that idea, it solves a lot of problems with the other methods as far as i can see.

 

how would I detect when the scrolling is done?

[MoscowModder]

if(Link->Action == LA_SCROLLING)
{
    while(Link->Action == LA_SCROLLING)
        Waitframe();
    
    Link->PitWarp(getDestDMap(), Game->GetCurDmapScreen());
}

int getDestDMap()
{
    // However you determine destination DMap
}