242 replies to this topic

[ywkls]

@grayswandir- Your idea works... mostly. Here's the current form of the code.

 

Continue Switching Code

const int TS_NUM_TIMEPERIODS = 4;     //Set this to the number of time periods.  I.e. Past/Present/Future = 3
 
int TS_DMaps[3] = {0, 4,32};   //This array tells the script which DMaps are involved in the Time System. 
                            //Put the first DMap of every set of time periods separated by a comma inside the {}. 
                            //Put the number of things inside the {} inside the []. 
                            //****You'll want to make a new save file every time you change this.
 
int TS_CurrentState = 0;  //tracks which time period you are in
const int TS_ARRAY_START = 71;//Start of continue Dmap array.
const int TS_ARRAY_END = 98;//End of continue Dmap array.
//Array of next continue Dmapa.
int TS_NextDMap[28] = {74,75,76,77,78,79,80,81,82,	
		       71,72,73,86,87,88,89,90,91,
		       92,93,94,83,84,85,96,97,98,95};

 
// handles actually changing the Time Period dmap 
void TS_CheckandWarp(){
   int curDMap = Game->GetCurDMap();
   //Dmap is between array start and end.
   if(LastContinueDMap>=TS_ARRAY_START && LastContinueDMap<=TS_ARRAY_END)
		LastContinueDMap = TS_NextDMap[LastContinueDMap - TS_ARRAY_START];
   for(int i=0; i<SizeOfArray(TS_DMaps); i++){
      if(curDMap >= TS_DMaps[i] && curDMap < TS_DMaps[i]+TS_NUM_TIMEPERIODS){
         if(TS_DMaps[i] + TS_CurrentState != curDMap)
            Link->PitWarp(TS_DMaps[i] + TS_CurrentState, Game->GetCurDMapScreen());
      }
   }
}

 

I've tested the Dmaps associated with the first four elements of the array and elements 13-16. I'm reasonably certain it works for all elements... except the last four. For some strange reason, those are sending me to the wrong Dmap. I did the math and this shouldn't be so, which begs the question of what in the world is going on?

 

I'm also having to add a conditional to the script which runs setting the continue point to exclude 4 Dmaps which can't follow the same rules as the others when it comes to continue points.

[ywkls]

Update on the continue script- I ran traces on it to see what the value of the continue was before and after the change and discovered that things are being set correctly; yet I am still ending up on the wrong Dmap.

 

Due to this strange behavior that I can't account for, I'm temporarily scrapping the continue script; since it seems to have caused more trouble than it was worth. Maybe later I can figure out what was going on, but right now I'd rather be able to let people play my quest without running into game-breaking bugs.

[ywkls]

New script! A controllable boomerang I'm tentatively calling a Super Boomerang. At the moment, it doesn't collect items, but I'm working on that. Also, it seems to return to you instantly rather than showing the animation for it returning to you. Anyways, here's the script.

Super Boomerang

import "std.zh"
import "ffcscript.zh"

bool RangActive = false;//Tells the game whether the boomerang is active.

const int BOOMERANG_COMBO = 32637;//Combo for boomerang animation.
const int SPRITE_NULL = 93;//Blank sprite used by boomerang Lweapon.

//D0- Blank so other scripts can use it.
//D1- Script number for Boomerang.
//D2- Damage it does.
//D3- Sound it makes.
//D4- Speed of boomerang. Should be slow.
//D5- How long it will stay thrown.
//D6- Flag triggered by boomerang.

item script SuperRang{
	void run(int dummy, int script_slot, int damage, int sound, float speed, int throwtime, int flaglevel){
		if(!RangActive){
			RangActive = true;
		}
		else RangActive = false;
		int Args[8] = {Link->Dir,damage,sound,speed, throwtime, flaglevel};
		RunFFCScript(script_slot, Args);
	}
}

//A boomerang that can be controlled by the player.
//D0: Direction Link was facing when he launched the boomerang.
//D1: Damage.
//D2: Sound.
//D3: Flight speed.
//D4: How long it is thrown for.
//D5: What flag it triggers.


ffc script SuperBoomerang{
	void run (int direction, int dam, int sound, float speed, int throwtime, int flaglevel){
		this->Data=BOOMERANG_COMBO;
		this->X = Link->X;
		this->Y = Link->Y;
		int sfxTimer;//Timer for sound effects.
		while (RangActive && throwtime>0){
			//Move ffc to match input.
			if(Link->InputUp && this->Y >1){
				Link->InputUp = false;
				this->Y-=speed;
			}
			else if(Link->InputDown && this->Y <170){
				Link->InputDown = false;
				this->Y+=speed;
			}
			else if(Link->InputRight && this->X<255){
				Link->InputRight = false;
				this->X+=speed;
			}
			else if(Link->InputLeft && this->X>1){
				Link->InputLeft = false;
				this->X-=speed;
			}
			//Keep Link in place.
			else{
				Link->InputUp = false;
				Link->InputDown = false;
				Link->InputRight = false;
				Link->InputLeft = false;
			}
			if(this->X<Link->X){
				if(this->Y< 40)Link->Dir = DIR_UP;
				else if(this->Y>40 && this->Y<120)Link->Dir = DIR_LEFT;
				else if(this->Y>120)Link->Dir = DIR_DOWN;
			}
			else if(this->X>Link->X){
				if(this->Y< 40)Link->Dir = DIR_UP;
				else if(this->Y>40 && this->Y<120)Link->Dir = DIR_RIGHT;
				else if(this->Y>120)Link->Dir = DIR_DOWN;
			}	
			lweapon boomerang = LoadLWeaponOf(LW_BRANG);
			if(!boomerang->isValid()){
				boomerang= Screen->CreateLWeapon(LW_BRANG);
				boomerang->Damage = dam;
				boomerang->UseSprite(SPRITE_NULL);
				boomerang->X = this->X;
				boomerang->Y = this->Y;
				ItemPickup(boomerang,false);
				for(int i = 0; i < 176; i++){
					if(ComboFI(i,flaglevel) && Abs(boomerang->X-ComboX(i))<8 && Abs(boomerang->Y-ComboY(i))<8){
						Screen->TriggerSecrets();
						Screen->State[ST_SECRET] = true;
					}
				}
			}
			else{
				boomerang = LoadLWeaponOf(LW_BRANG);
				Remove(boomerang);
			}
			//Create sound every sixty seconds.
			if ( sfxTimer == 0 ) Game->PlaySound(sound);
			sfxTimer = (sfxTimer+1)% 60;
			throwtime--;
			Waitframe();
		}
		RangActive = false;
		while(true){
			Link->InputUp = false;
			Link->InputDown = false;
			Link->InputRight = false;
			Link->InputLeft = false;
			if(this->X<Link->X)this->X++;
			else this->X--;
        	if(this->Y>Link->Y)this->Y--;
			else this->Y++;
			lweapon boomerang = LoadLWeaponOf(LW_BRANG);
			if(!boomerang->isValid()){
				boomerang= Screen->CreateLWeapon(LW_BRANG);
				boomerang->Damage = dam;
				boomerang->UseSprite(SPRITE_NULL);
				boomerang->X = this->X;
				boomerang->Y = this->Y;
				ItemPickup(boomerang,true);
			}
			else{
				boomerang = LoadLWeaponOf(LW_BRANG);
				Remove(boomerang);
			}
			if ( sfxTimer == 0 ) Game->PlaySound(sound);
			sfxTimer = (sfxTimer+1)% 60;
			if(this->X == Link->X || this->Y == Link->Y)break;
			Waitframe();
		}
		lweapon boomerang = LoadLWeaponOf(LW_BRANG);
		Remove(boomerang);
		this->Data = 0;
	}
}

//Causes Lweapon to drag dropped items around or instantly deliver items straight to Link.
//Called automatically on LweaponWaitframe, if LWF_CAN_PICKUP_ITEMS or 
//LWF_CAN_INSTADELIVER_ITEMS lweapon flag is set.
void ItemPickup (lweapon l, bool instant){
	for (int i=1; i<= Screen->NumItems(); i++){
		item it = Screen->LoadItem(i);
		if ((it->Pickup&0x806)==0){
			if (Collision(l,it)){
				if (instant){
					it->X = Link->X;
					it->Y = Link->Y;
				}
				else{
					int lwx = l->X + l->HitXOffset;
					int lwy = l->Y + l->HitYOffset;
					it->X = lwx;
					it->Y = lwy;
				}
			}
		}
	}
}

That item pickup script is from stdWeapons, but I couldn't get it to work for me and I'm not sure exactly why. Still, it is something I've never done before.

Edited by ywkls, 30 November 2015 - 03:31 PM.

[Naru]

Uhhm, I really tried to read the thread from beginning to end, but my brain is already burning after 1/3 of it. I just want to know if certain things are possible (some answers I already got from the part I did read). Also still not really expirienced with FFCs, so maybe some of the problems can be solved with them...

 

Overhead-layers, that are only overhead if your y-coordinates are above the combo. I have an unhealthy perfectionism and I just can stand neither to have half overhead objects (like trees in most games, which result in sprites and such cut in two parts were the overhead-square ends, also really ugly with foes like pols voice) nor solid objects, that block the way though they do not look like they do (like trees in the GBC-games). Also something like "block melee-weapons" and a block, that results in an early flame instead of negating it completly?

 

Is it possible to add multiple inherent triggers, since these only work on layer 0 normally? Also something like "step/trigger A", "step/trigger B" (...) inherent flags (including "reset A", that trigger only flags of the same type (effecting any secret (all layers) on the square and are saved individually would be great to make it able to bound certain secrets to certain triggers.

 

Could there be a way to simplify the disabeling process of items via Dmaps? Similiar to the mask-idea I have a lot of ideas that could be handeled by Dmaps with different subscreens and disabeling certain items, but since such a system (especially for passive items) would include a lot of disabeling on each D-map and especially effects not that obvious (invisible effects like from peril-ring, that you might not realize or different level versions for things like ice-/firearrows, that are used to make only one of them the possible trigger (since icearrows shouldn't trigger fire-arrows, btw. I am also really annoyed from magic-flames triggering candle-flames) can be easily overseen and could break the gameplay blablabla ... to be short it is really tedious to be done for each Dmap. Also if I warp around a lot to be for example in a room once as a deku and once as a goron and have a lot of Dmaps to do so, is there any way to keep the "room visited" state in the minimap, since all these rooms/Dmaps represent the same level(floor) ?

 

[edit] Also, might it be possible to change the hookshot in a way, that not the hookshot itself is stopped by non-walkable combos, but Link is stopped instead?

Edited by Naru, 27 December 2015 - 05:05 PM.

[ywkls]

@Naru- All very good questions! Unfortunately I don't have the answers to half of them.

 

1. Regarding layers- the best advice I can give you is to place things on higher layers. If that still doesn't work, there is a layer 7 which can only be activated via script that draws even over the subscreen. The Screen->DrawLayer command draws a whole layer from another screen to your current screen on the layer of your choice. The command Screen->DrawTile draws a single tile or group of tiles at specified coordinates. The command Screen->DrawCombo draws a single combo or group of combos at the coordinates of your choice. The main difference between the last two is that combos can be animated. Lastly is Screen->DrawBitmap, which is something that I haven't really messed around with that much myself yet.

2. For the idea of having combos that block weapons and causes the weapon in question to just stop movement rather than cease to exist, that can but done; but would probably require a scripted weapon to accomplish. Further details on exactly what you're looking for would be helpful to point you in the right direction.

3. The best approach to multiple triggers I know of is tiered secrets. There may be other ways to do what you're looking for. I also have a script in the database that allows you to use as many as between 8 and 16 secrets that can each be triggered by different items on the screen at the same time. It's called Scripted Secrets and Sounds.

4. For disabling items, scripts or message strings can be used to temporarily take items out of your inventory. To store the information that a room has been visited is another thing that can be scripted, but more details would be helpful in providing a solution.

5. As far as I can tell, the behavior of the built-in hookshot can't really be messed with. However, we could make a scripted hookshot that does what you want, possibly.

 

Sorry that you didn't make it through the entire thread. I agree that it has gotten kind of long. That is one of the reasons that I created a link in my signature which goes to a topic entitled 'Table of Contents for Scripts I've Developed/Found', This topic links to specific scripts in the database and other topics that have useful scripts. I created it as a way for people to find some of the stuff that I'd discovered or created.

 

I hope that this reply helps you. If you have any further questions, please feel free to ask. I may not be able to reply (because I don't know) but there are others more experienced at scripting than I am who regularly reply to this topic and might be able to provide further assistance.

[Lejes]

There are a number of ways you can change how layers are drawn, like drawing over Link/an enemy with a tile or changing the combo type itself with Screen->ComboT[] or ComboD[]. I think you're always going to run into limitations of ZC's layer system no matter what implementation you go with, though. For the DMap item disabling, I can't think of a system right now that wouldn't be at least as clunky as disabling them manually in ZQuest. Carrying over rooms visited is easy, though. You just use Game->SetScreenState() to set ST_VISITED on any other DMaps you want. The hookshot shouldn't even need a script for that, because Hookshot Only combo types exist.

[Naru]

Though I do not get most of the stuff (I really mostly ask because I want to avoid to overwork all of my screens afterwards), thanks a lot. Just to make this clear, the "Game->SetScreenState() to set ST_VISITED"-things are to be used in scripts, right? At least I cannot find something similiar in ZC.

 

1. What I meant with the overlayers was to have more or less a tree that is overlayer, if i stand behind it, and not overlayer, if i stand in front of it, kind of decided by the y-coordinates. There is also something similiar for jumping and trees in the database, so I hope this is possible.

 

2. The main idea here was reasoned by my attempt to avoid overhead-issues with items through just blocking them, but melee-moves are not blocked by the flag and the flame is not even created. This is not really anything I want to use anymore, but I can imagine useful situations for such things.

 

3. This is for independent secrets that can also reset independent. BTW, is there a way to warp between two screens and carry over enemys without creating new enemies on warping back to the screen, that spawned them? I am not even sure, it is possible to carry over enemies on warping (thought there was a flag for that, but am searching forever). I want to create kind of an false wall, the get transperent if walking through it (overhead non-transparent and sensetive direct warp on screen 1 - overhead transparent and direct warp on screen 2), but that will look very odd with the enemyspawns...

3.1 I am really open to alternate solutions to this though I am sry, if this does not fit the topic anymore.

 

4. Thought so, but shouldnt try to be less lazy anyway

 

5. Hmm, to use a scripted weapon instead seems logical. @Lejes, what I meant is a Hookshot, that moves like other projectils also over non-walkable combos and if hitting a hookshot-grab, it will pull link to it, but will stop, if Link hits a non-walkable (excluding "hookshot only") combo. Of course it works also the way it is now, but often there are situation like with lower-walls that just look odd if they block the hookshot.

5.1 Again, is there a way to use multiple inherent flags (that work only on layer 0) like convoyer up and direct warp or push block and damage?

[Timelord]

What are you wanting item disabling to do? It works as-is, but are you trying to ensure that the item is still on the subscreen, but rendered unusable? Meaning that, the player may select it, but using it produces an error?

There is a way to do that, but it's somewhat tedious to implement.

Warping enemies: Screen State Carryover of some kind... How does Moosh do that? (I know that Moosh did this in a few quests.)

(5) Sounds like something I could do with light scripting on the normal hookshot item. It'd need to read Link's position every frame, and if he collides with an object that is solid, mark the spot -/+ 16 based on direction, then kill the hookshot lweapon, and move Link to the spot marked. Pretty much what I did with the switchshot, but using different offsets, and a modified mechanism for combo detection.

 

Possibly something like this (call using an item script on the hookshot, via RunFFCScript(id,NULL); )

ffc script DeadStopHookshot{
    void run(){
        int lx;
        int ly;
        int lOffsetX;
        int lOffsetY;

        while(NumLWeaponsOf(LW_HOOKSHOT)){
            lx = Link->X;
            ly = Link->Y;
            int cmb = ComboAt(Link->X, Link->Y);
            if ( Link->Dir == DIR_UP ) {
                lOffsetY = 0;
                lOffsetX = -16;
            }
            if ( Link->Dir == DIR_DOWN )  {
                lOffsetY = 0;
                lOffsetX = 16;
            }
            if ( Link->Dir == DIR_LEFT )  {
                lOffsetY = 16;
                lOffsetX = 0;
            }
            if ( Link->Dir == DIR_RIGHT )  {
                lOffsetY = -16;
                lOffsetX = 0;
            }
    
            if ( ComboS[cmb] !=0 && ComboT[cmb] != CT_HOOKSHOTONLY ) {
                for ( int q = 1; q <= Screen->NumLWeapons(); q++ ) {
                    lweapon l = Screen->LoadLWeapon(q);
                    if ( l->ID == LW_HOOKSHOT ) l->DeadState = WDS_DEAD;
                }
                Link->X = lx + lOffsetX;
                Link->Y = ly + lOffsetY;
            }
            Waitframe();
        }
    }
}

Do push blocks not work on layers above 0 at all, with the normal engine?

Edited by ZoriaRPG, 28 December 2015 - 09:56 AM.

[ywkls]

Do push blocks not work on layers above 0 at all, with the normal engine?

They are completely ignored. Something I discovered while trying to fix a few screens in my game where you much push a block on screens with something on layer 1 or 2. I shifted those blocks to a different layer and the flag was ignored.

You also apparently can't affect Slash-type blocks on layers.
 

@Naru-

1. So, a tree (or whatever) where if you're behind it it is drawn above you and below it; it is drawn below you. Sounds possible, but incredibly script-intensive.

2. That's kind of what I thought that you meant.

3. The aforementioned script will also allow for secrets that will reset if you leave the room. It's pretty versatile, actually. To clarify, you can have up to 28 secrets that reset when you leave the screen. Each would do a different thing on that screen. If you want to have permanent effects like light all the candles or hit all the switches; you can have up to 16 different triggers. If you want to have permanent effects where each trigger does something different, you can have up to 8 of those.

3.1. On the false wall idea... I really can't say at the moment how that might be done, since I'm not entirely sure what you're talking about.

 

I believe that the other two questions have been covered already. If you have anything else you're uncertain about, don't hesitate to ask! That's how I learned everything I know over the course of time, mostly with the aid of this topic.

[C-Dawg]

@Naru:  I've run into your layers problem myself.  Basically, Zquest itself has no innate ordering of sprites or layers based on the Y coordinate.  So, if one FFC moves over another, barring Overhead flags, the order they render in is determined by the index number for the FFC, not their Y location.  Ditto with layers.  So, you will end up seeing an enemy further up the screen on the Y axis render in front of one lower on the screen, or a large sprite being cut off by the top of a tree from BELOW as well as from ABOVE.  This offends your sense of depth perception because it's not what happens in reality.

 

Trouble is, you can't fix this without taking control of how ZClassic renders layers and FFCs.  As for the layers, I believe you could solve this by adding a function to your global script that draws layers 3 and up for you.  Like, you set aside the next 2 maps for each map you design solely to be used for layers 3 and 4, and tell the script to go to those maps and draw the combos it finds on the appropriate layer of the current screen -- with a routine that first checks for collision and draws to layer 1 instead.  I believe all of this is possible, it would just require some logic.  Also, you'd need to give up on screen scrolling because otherwise the layers will not scroll with the screen.

 

FFC rendering can happen the same way, as long as you give up assigning combos to FFCs and have each one run a script that renders a portion of the tile sheet directly.  Basically, each FFC can check the location of every other FFC before rendering.  If it finds another FFC overlapping it, it can draw to a lower layer or higher layer, depending.

 

I don't know how useful it will be to your own quest, but I will probably be coding something like this for myself sooner rather than later, so I'll post it when I do.

[Timelord]

That radically ruins some ideas that I have. Have you made code for push blocks on higher layers; or need I do that?

[C-Dawg]

Shouldn't be too hard.  You can access the combos and flags on any MAP in Zelda Classic at any time, right?  

 

1. Check whether there's a push block flag on layer 2

2. If so, and the player is able to push it, zero out the combo on layer 2 and put an FFC that mimics solidity and draws a tile identical to the combo on layer 2 of the screen.  Have that FFC move over a tile.

3. Then, either redraw the combo on the proper MAP in a new location (I think this makes the push permanent) or just have the FFC hang out there until moved again.

[Gleeok]

@Naru:  I've run into your layers problem myself.  Basically, Zquest itself has no innate ordering of sprites or layers based on the Y coordinate.  So, if one FFC moves over another, barring Overhead flags, the order they render in is determined by the index number for the FFC, not their Y location.  Ditto with layers.  So, you will end up seeing an enemy further up the screen on the Y axis render in front of one lower on the screen, or a large sprite being cut off by the top of a tree from BELOW as well as from ABOVE.  This offends your sense of depth perception because it's not what happens in reality.
 
Trouble is, you can't fix this without taking control of how ZClassic renders layers and FFCs.  As for the layers, I believe you could solve this by adding a function to your global script that draws layers 3 and up for you.  Like, you set aside the next 2 maps for each map you design solely to be used for layers 3 and 4, and tell the script to go to those maps and draw the combos it finds on the appropriate layer of the current screen -- with a routine that first checks for collision and draws to layer 1 instead.  I believe all of this is possible, it would just require some logic.  Also, you'd need to give up on screen scrolling because otherwise the layers will not scroll with the screen.
 
FFC rendering can happen the same way, as long as you give up assigning combos to FFCs and have each one run a script that renders a portion of the tile sheet directly.  Basically, each FFC can check the location of every other FFC before rendering.  If it finds another FFC overlapping it, it can draw to a lower layer or higher layer, depending.
 
I don't know how useful it will be to your own quest, but I will probably be coding something like this for myself sooner rather than later, so I'll post it when I do.

Y-sorting ffcs, items, and enemies is something that ZC could do without /too much trouble I think. The only weird thing is this probably doesn't work as intended at a global level, so maybe screen flags or something. Not sure. It's certainly possible though.

[Timelord]

Y-sorting ffcs, items, and enemies is something that ZC could do without /too much trouble I think. The only weird thing is this probably doesn't work as intended at a global level, so maybe screen flags or something. Not sure. It's certainly possible though.

 

FFC solidity was also intended, and certainly possible; but never implemented.

 

(I doubt it would work as intended, either.)

[Naru]

I know already that it is possible to put projectiles above overlayers through scripting, might it be an alternate solution to script instead player, item and enemysprites to be below (layer 4) depending on their screenposition?

 

Also, it is possible to create block-flags to only block projectiles coming from the back? This would perfect the "behind the tree" expirience. I also am back to the block-idea a bit. Is it possible to change the block in a way that wand-magic/candle-flame create a Flame on beeing blocked.

 

Also if you walk near an edge of a solid combo, Link's position is slightly corrected, is it possible to make this correction for complete quarter-solid combos like diagonal walls? I know this is totally unneeded but it is annoying me. Also of course I want this not to work as global script.

 

A script that makes only certain pits crossable with the ladder and disables the ladder to work otherwise? The Ladder-item can be soo annoying sometimes. Also I have certain problems with solid combos above water, since Link will just ignore them.

 

I searched for the secret-script ywkls spoke about and could not find anything that woul include my needs. Is there something that works like triggering a secret on activating step 1 and reseting this on activating step 2 to be triggerable again by step 1 and so on? And this should work completly independent from other secrets. Maybe through putting a FFC on a Layer so only this Layer is affected by the trigger?

 

Again this is mostly to have the background-info what is possible and what not. To really use scripts is actually no something I am able with my actual knowledge...