Jump to content

Photo

Bomb-blocking shield


  • Please log in to reply
11 replies to this topic

#1 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 27 May 2019 - 10:46 AM

The current block/reflect flag system for shields doesn't account for enemy bomb projectiles, so I'm curious if this can be done by script.

What I'm hoping the script could do is reference Link's current shielded/unshielded status, and let the bomb projectiles explode normally but disable their damage if they hit Link from the front while shielded.

This would occur if he has this specific L4 shield (item #134), but not the original L1-L3 shields.

So ideally the script could just be appended to an existing shield, since rescripting the shielding system from scratch probably wouldn't be worth the effort.

I would use this in 2 instances:

1) An update to an older quest that I'm hoping to roll out within a week (though the update's been in progress for over 2 years, so I can wait a few more weeks for this if it's actually possible).
2) The moderately expanded classic tileset that I'm hoping to release within a few months.

With that in mind, this would be for ZC 2.53.0 (unless ZC 2.55 goes final within the next month).

#2 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 27 May 2019 - 10:49 PM

With that in mind, this would be for ZC 2.53.0 (unless ZC 2.55 goes final within the next month).

Err, not in Beta, nevermind final. 2.55 will certainly not be final this year (beta this year might happen, but certainly not gamma/release)

Especially considering I will be leaving for Japan in September, and won't be back until almost February.



#3 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 27 May 2019 - 10:58 PM

Yeah I was basically reiterating it would have to be for 2.53.0 despite the recent emphasis on 2.55's possibilities, since it would actually get used in final releases very soon.

#4 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 29 May 2019 - 07:32 AM

The current block/reflect flag system for shields doesn't account for enemy bomb projectiles, so I'm curious if this can be done by script.

What I'm hoping the script could do is reference Link's current shielded/unshielded status, and let the bomb projectiles explode normally but disable their damage if they hit Link from the front while shielded.

This would occur if he has this specific L4 shield (item #134), but not the original L1-L3 shields.

So ideally the script could just be appended to an existing shield, since rescripting the shielding system from scratch probably wouldn't be worth the effort.

I would use this in 2 instances:

1) An update to an older quest that I'm hoping to roll out within a week (though the update's been in progress for over 2 years, so I can wait a few more weeks for this if it's actually possible).
2) The moderately expanded classic tileset that I'm hoping to release within a few months.

With that in mind, this would be for ZC 2.53.0 (unless ZC 2.55 goes final within the next month).

 
Try this:
 
 

const int I_SHIELD4 = 134;

ffc script shields //Dummy script, used for namespace purposes. No need to assign to a slot.
{
	void run(){}

	void blockbomb()
	{
		if ( Link->Action != LA_WALKING && Link->Action != LA_NONE ) return; //Abort
		if ( Link->Item[I_SHIELD4] )
		{
			
			for ( int q = ScreenNumEWeapons(); q > 0; --q )
			{
				eweapon e = Screen->LoadEWeapon(q);
				if ( e->ID == EW_BOMBBLAST || e->ID == EW_SBOMBBLAST )
				{
					if ( Link->Dir == DIR_UP )
					{
						if ( e->Y < Link->Y+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_DOWN )
					{
						if ( e->Y > Link->Y+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_LEFT )
					{
						if ( e->X < Link->X+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_RIGHT )
					{
						if ( e->X > Link->X+8 ) e->HitYOffset = -32768;
					}
				}
			}
			for ( int q = ScreenNumLWeapons(); q > 0; --q )
			{
				lweapon e = Screen->LoadLWeapon(q);
				if ( e->ID == LW_BOMBBLAST || e->ID == LW_SBOMBBLAST )
				{
					if ( Link->Dir == DIR_UP )
					{
						if ( e->Y < Link->Y+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_DOWN )
					{
						if ( e->Y > Link->Y+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_LEFT )
					{
						if ( e->X < Link->X+8 ) e->HitYOffset = -32768;
					}
					else if ( Link->Dir == DIR_RIGHT )
					{
						if ( e->X > Link->X+8 ) e->HitYOffset = -32768;
					}
				}
			}
		}
	}
}

global script test
{
	void run()
	{
		while(1)
		{
			shields.blockbomb();
			Waitframe();
		}
	}
}

 
If you already have an global acive script, then call shield.blocvkbomb() in your current global script.
 
LMK i it fails to work or to compile. Im writing it on the bedroom laptop.
 
In 2.55, it would be this, as an item script that runs perpetually.


  • ShadowTiger likes this

#5 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 29 May 2019 - 07:00 PM

LMK i it fails to work or to compile. Im writing it on the bedroom laptop.

Thanks for looking into this.

There seem to be undeclared functions that prevent compiling.

In 2.53.0 R2, this is the S10 error list:

FUNCTION SCREENNUMEWEAPONS IS UNDECLARED
FUNCTION SCREENNUMLWEAPONS IS UNDECLARED
FUNCTION SHIELDS.BLOCKBOMB IS UNDECLARED

I searched through the 2.53.0 R2 and 2.55 A23 folders, but none of the script libraries in there have a "ScreenNumEWeapons" or "ScreenNumLWeapons" function, so you must be referencing a library that I need to get a hold of.

Additionally, I tried compiling the 2.55 version in A23, and it gave me a similar message - "ERROR T021: FUNCTION SCREENNUMEWEAPONS() HAS NOT BEEN DECLARED" - and then ZQuest crashed.

#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 01 June 2019 - 09:42 AM

Thanks for looking into this.

There seem to be undeclared functions that prevent compiling.

In 2.53.0 R2, this is the S10 error list:

FUNCTION SCREENNUMEWEAPONS IS UNDECLARED
FUNCTION SCREENNUMLWEAPONS IS UNDECLARED
FUNCTION SHIELDS.BLOCKBOMB IS UNDECLARED

I searched through the 2.53.0 R2 and 2.55 A23 folders, but none of the script libraries in there have a "ScreenNumEWeapons" or "ScreenNumLWeapons" function, so you must be referencing a library that I need to get a hold of.

Additionally, I tried compiling the 2.55 version in A23, and it gave me a similar message - "ERROR T021: FUNCTION SCREENNUMEWEAPONS() HAS NOT BEEN DECLARED" - and then ZQuest crashed.

 

 

Just missing a pointer arrow token.

 

const int I_SHIELD4 = 134;
     
ffc script shields //Dummy script, used for namespace purposes. No need to assign to a slot.
{
        void run(){}
     
        void blockbomb()
        {
            if ( Link->Action != LA_WALKING && Link->Action != LA_NONE ) return; //Abort
            if ( Link->Item[I_SHIELD4] )
            {
                
                for ( int q = Screen->NumEWeapons(); q > 0; --q )
                {
                    eweapon e = Screen->LoadEWeapon(q);
                    if ( e->ID == EW_BOMBBLAST || e->ID == EW_SBOMBBLAST )
                    {
                        if ( Link->Dir == DIR_UP )
                        {
                            if ( e->Y < Link->Y+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_DOWN )
                        {
                            if ( e->Y > Link->Y+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_LEFT )
                        {
                            if ( e->X < Link->X+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_RIGHT )
                        {
                            if ( e->X > Link->X+8 ) e->HitYOffset = -32768;
                        }
                    }
                }
                for ( int q = Screen->NumLWeapons(); q > 0; --q )
                {
                    lweapon e = Screen->LoadLWeapon(q);
                    if ( e->ID == LW_BOMBBLAST || e->ID == LW_SBOMBBLAST )
                    {
                        if ( Link->Dir == DIR_UP )
                        {
                            if ( e->Y < Link->Y+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_DOWN )
                        {
                            if ( e->Y > Link->Y+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_LEFT )
                        {
                            if ( e->X < Link->X+8 ) e->HitYOffset = -32768;
                        }
                        else if ( Link->Dir == DIR_RIGHT )
                        {
                            if ( e->X > Link->X+8 ) e->HitYOffset = -32768;
                        }
                    }
                }
            }
        }
    }
     
    global script test
    {
    void run()
        {
            while(1)
            {
                shields.blockbomb();
                Waitframe();
            }
        }
    }

 

I tested that it compiles, but nothing more.


  • ShadowTiger likes this

#7 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 01 June 2019 - 02:31 PM

Just missing a pointer arrow token.

I tested that it compiles, but nothing more.

OK, that fixed the code up, and now it all compiles here too.

(tbh I probably should've recognized that, since I've used those before.)

But unfortunately, it doesn't seem to do anything after picking up the shield.

As a matter of curiosity, I experimented with editing some of the Link-> and HitYOffset values to different numbers. I also tried compiling with and without inserting the ffc portion into a slot. Neither rendered it effective.

The "while(1)" line in the global is new to me. I've seen "while(true)" all the time, but never (1). Also as a matter of curiosity, I tried changing "1" to "true," but still nothing.

If you want to see what I'm using the script with in practice, this is a stripped-down version of the quest with shield item and graphics in place, and other scripts removed. It has an open room with shield in corner and an always-returning Bomborok, and init data includes sword and spin scrolls. Posted script is compiled and in place:

https://drive.google...WyZzczFoJZiC7Ng

#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 01 June 2019 - 08:13 PM

It may simply need to run before Waitdraw. I also realised that if this moves the coordinates of Link weapon bomb explosions, that theu won't hurt enemies either, so, that is another problem, and it isn''t easy to solve without other extremely large issues in 2.50/2.53. Pnce Link->Deence is in the equation, planned for 2.55, it would probably be easy, but in 2.50/2.53, you basically have four choices:

 

  1. LW Bombblasts won't hurt enemies if Link deflects them.
  2. Don't allow LW bombs to hurt Link (quest rule).
  3. Accept a hack where Link flashes, and makes a sound of being hit, but he is not knocked vack, and the damage isn't applied.
  4. Alllow Link to be immune to other attacks/damage until the number of frames that the explosion can hurt him expires.

 

Also, while is an ordinary statement, that accepts a logical expression.

 

All of these have the same effect (infinite loop):

while(1)
while(!0)
while(4)
const int A  = 6; while(A)
while(0<1)
for ( int frame= 0; 1 > 0; ++frame ) //this is an infinite loop that declares frame and advances it every iteration. The loop condition is alway true.
while(35559)
while(!false)

As long as the statement evaliates its expression as true, it runs its block. Any expression that produces nonzero value is true, In C, true is just a macro for 1 anyway.

 

Similarly, while( 0 ) and while(false) will never run their block.



#9 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 02 June 2019 - 03:11 AM

I als need to account for a specific area n the other axis with an absolute difference. Still, for this to work in 2.5m you would need to pick one of those four, equally awful options.



#10 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 04 June 2019 - 07:26 PM

So many ways to do the same thing  :ohmy:

At any rate, regarding the currently available shield script options...

[...] but in 2.50/2.53, you basically have four choices:

  • LW Bombblasts won't hurt enemies if Link deflects them.
  • Don't allow LW bombs to hurt Link (quest rule).
  • Accept a hack where Link flashes, and makes a sound of being hit, but he is not knocked vack, and the damage isn't applied.
  • Alllow Link to be immune to other attacks/damage until the number of frames that the explosion can hurt him expires.
...if I'm understanding #2 correctly, it simply requires the "Items" quest rule "Link's Bombs Hurt Link" to be unchecked? In which case, here's what I'm thinking:

For the quest update, the file already disables Link getting hurt by his own bombs, so #2 should be applicable here by default. Since this is a one-shot instance where people basically have to play it "my way," that particular method can be used without issue.

For the tileset, it may be best to wait for 2.55. Unlike the quest update, the tileset needs to preserve the versatility of the default ZC options. Restricting them for an item, or doing other hacks that won't be up to general standards, aren't good choices for a release meant to be used by the general public in whatever "their way" may be.

So could we do the #2 quest rule version for the quest update? Then just wait for 2.55 to do the generally-accessible non-hack version.

#11 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 13 June 2019 - 12:01 PM

How does it prevent damage, now?



#12 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 10 July 2019 - 03:37 PM

How does it prevent damage, now?

Sorry, I don't understand?

The script in your second post didn't initially change anything.

Or did you update it? Because I recompiled what's currently in the post, and no behavior changed from what was in the initial post.

Basically, the bomb hits Link and explodes and does damage like it always does by default - flashes him, bumps him back a bit, and takes away however many hearts.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users