Jump to content

Photo

Lockblocks - any value of counter rather than a minimum


  • Please log in to reply
11 replies to this topic

#1 ShadowTiger

ShadowTiger

    The Doctor Is In

  • Members

Posted 29 December 2019 - 07:31 AM

Foolish Khajiit that is definitely not drunk at all because it's true requests a way to have a Lockblock not actually require a counter/ or item-count to be at a minimum value before the lockblock can be turned into a different combo. It would simply remove the specified amount regardless of whether or not you actually have the value that the lockblock demands as what we would believe to be a minimum.

It would be the "Eh, good enough" variation. :P It might require a minimum attribute though, as in "Hey, as long as you have one rupee, I don't mind you not having all fifteen rupees that I'm asking for."

Heaven forbid we get a randomize feature too, where it'd take somewhere between those two values. I'm actually kind of afraid of seeing that, to be honest.


Specifically, from the Discord, something I and others said: (It's a mishmash of sentences because properly quoting it just crashed the parser and resulted in a database error. Whee.
Spoiler


#2 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 December 2019 - 12:26 PM

Added as a 'Thief' flag. This is entirely at the fault of the questmaker if you can softlock a quest with key counts.

If the Thief flag is enabled, and you have < the required counter value, the lockblock will drain that counter to 0, but not unlock.

#3 ShadowTiger

ShadowTiger

    The Doctor Is In

  • Members

Posted 30 December 2019 - 12:34 PM

Oof.  That's cute.  I guess it can't have a lazy equivalent where it unlocks no matter how many keys/items you give it?   Kind of an  "Eh, good enough.  Go on in." option. 



#4 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 December 2019 - 01:40 PM

Oof.  That's cute.  I guess it can't have a lazy equivalent where it unlocks no matter how many keys/items you give it?   Kind of an  "Eh, good enough.  Go on in." option.


Hmm... Why do you want or need that? You want a version that does what now? Drains a counter to 0 if it is above 1 and unlocks??

I did add a flag that checks the requirement, but does not drain the counter, but I think that a version that only checks for a partial requirement and drains it to zero is a bit bizarre. Check if Counter > 0 and Drain it to 0 is easy to add, but I don't see a gameplay value reason for it?!

BTW, Combo Scripts now exist as of A48. Shhhh! Don't tell everyone.
  • ShadowTiger likes this

#5 ShadowTiger

ShadowTiger

    The Doctor Is In

  • Members

Posted 30 December 2019 - 02:14 PM

It would be a useful feature for toll roads.  "Drain all of your money" sorts of things.  No matter what you have, it'll take it, but then let you pass.  The thief attribute that was just programmed in would take what you have but not let you pass.  It's sort of like "This is a no money area" activity.  There have been quests that indulge in such activities, such as James24's Liberation of Hyrule quest(s) that need you to re-accumulate a certain amount of money when you enter a segment of a specific dungeon.

 

  Though it's very easy to make a script that just sets a counter to 0 when you enter the room, (A moron like me has done that before.) though turning that into an FFC that checks if the player is on certain combos isn't as trivial of a script for non-scripters.

 

Looking forward to seeing what combo scripts can do though.  I'll bet they go hand in hand with the new "Label" feature of Combos. 



#6 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 December 2019 - 04:33 PM

It would be a useful feature for toll roads.  "Drain all of your money" sorts of things.  No matter what you have, it'll take it, but then let you pass.  The thief attribute that was just programmed in would take what you have but not let you pass.  It's sort of like "This is a no money area" activity.  There have been quests that indulge in such activities, such as James24's Liberation of Hyrule quest(s) that need you to re-accumulate a certain amount of money when you enter a segment of a specific dungeon.
 
  Though it's very easy to make a script that just sets a counter to 0 when you enter the room, (A moron like me has done that before.) though turning that into an FFC that checks if the player is on certain combos isn't as trivial of a script for non-scripters.
 
Looking forward to seeing what combo scripts can do though.  I'll bet they go hand in hand with the new "Label" feature of Combos.


Toll road?
 
combodata script tollroad
{
	void run(int ctr, int msg)
	{
		while(1)
		{
			if ( ( Abs(Hero->X - this->PosX()) < 8 )
				&& ( Abs(Hero->Y - this->PosY()) < 8 )
			{
				Screen->Message(msg);
				Audio->PlaySound(this->Attribytes[0]);
				Game->Counter[ctr] = 0;
			}
			Waitframe();
		}
	}
}

  • ShadowTiger likes this

#7 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 30 December 2019 - 09:55 PM

Ooooh, combo scripts in action! Wonderful!

I'd add `if(msg)` on that `Screen->Message()` call.



#8 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 30 December 2019 - 11:09 PM

Ooooh, combo scripts in action! Wonderful!
I'd add `if(msg)` on that `Screen->Message()` call.


Why would I want to add useless instructions?

Screen->Message(invalid) does nothing, by design in at least 2.53+, if not 2.50.2+.

 

Negative values I suppose could be internally rectified with abs(), but Message(0) simply aborts, and decimals are truncated...

 

As I recall, if a call to a string table entry is > num_used_strs, then it also aborts, as it'd be invalid.



#9 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 30 December 2019 - 11:37 PM

Why would I want to add useless instructions?

Screen->Message(invalid) does nothing, by design in at least 2.53+, if not 2.50.2+.

 

Negative values I suppose could be internally rectified with abs(), but Message(0) simply aborts, and decimals are truncated...

 

As I recall, if a call to a string table entry is > num_used_strs, then it also aborts, as it'd be invalid.

If I recall, Screen->Message(0) will clear a string from the screen if one is already being displayed, which is not a null behavior.



#10 ShadowTiger

ShadowTiger

    The Doctor Is In

  • Members

Posted 31 December 2019 - 05:17 AM

Neat. So, a few questions, please:

For one, these Combo scripts will be global, in that wherever the combo is placed, each iteration of the combo will have the script running on its own individual combo? Or will it affect every instance of that combo on the entire screen? (In which case, to make them work individually, we'd just duplicate the combo and place the duplicates on the screen.)
 

		while(1)

Does "1" just mean "true?" If so, does that work elsewhere, so we can replace "true" with "1" ?
 

			if ( ( Abs(Hero->X - this->PosX()) < 8 )

The need for the Abs implies that the player won't be somewhere off-screen, or we don't care if they are? What's their purpose here, please?
 

			if ( ( Abs(Hero->X - this->PosX()) < 8 )
				&& ( Abs(Hero->Y - this->PosY()) < 8 )

This is specifically for when the player attempts to occupy the middle'ish region of the combo, yes?  Though this does beg the question, is this a solid combo?  (Like a Lockblock.)  Do scripts get activated when the player attempts to push themselves into the combo?

Because I would expect some bit of code that says, to the effect, "If Link is Y-8 pixels below this combo and presses "up" for half a second, do the rest of this code." But I never see any. Why is that? :huh:

It's easy enough to figure out the rest of the directions of interaction though. The Y-8 thing would only effect the south direction due to the way the grid system works. Or is X-8 just a tradition of the system. ... or have I completely misunderstood why X-8 and Y-8 (As appropriate) are written.

 

this->PosX()
Remind me again why PosX needs parentheses?  ... or blank ones, at least?

Thanks much!



#11 Lüt

Lüt

    Germanize

  • Members
  • Real Name:Steve
  • Location:Chicago

Posted 31 December 2019 - 05:33 AM

Does "1" just mean "true?"

This much I know: yes.

As an ordinary statement, any expression that "while" evaluates as "true" will cause it to run its block, and any non-zero value will register as "true" (which is apparently just a macro for "1" in C anyway).
  • ShadowTiger likes this

#12 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 31 December 2019 - 07:29 PM

Neat. So, a few questions, please:

For one, these Combo scripts will be global, in that wherever the combo is placed, each iteration of the combo will have the script running on its own individual combo? Or will it affect every instance of that combo on the entire screen? (In which case, to make them work individually, we'd just duplicate the combo and place the duplicates on the screen.)

Each combo will be running the script. Combos on layers can run the script, depending on QRs.

		while(1)
Does "1" just mean "true?" If so, does that work elsewhere, so we can replace "true" with "1" ?

 

In this case, they are identical. In general, it is better to use 'true', because functions can be overloaded with multiple versions which take different parameters.... the main thing is, `int` casts implicitly to `bool`, meaning `bool foo = 1;` will be `true`. Generally it's better for readability to use `true` or `false` for booleans, though.

			if ( ( Abs(Hero->X - this->PosX()) < 8 )
The need for the Abs implies that the player won't be somewhere off-screen, or we don't care if they are? What's their purpose here, please?

 

It's not Abs'ing the hero's position, it's Abs'ing the difference of position. So, if the hero is 4 pixels LEFT of the combo, then it's `Abs(-4)`. If he's 4 pixels RIGHT of the combo, it's `Abs(4)`. This is a basic distance formula, and has nothing to do with being offscreen, but being left/up of the combo.

			if ( ( Abs(Hero->X - this->PosX()) < 8 )
				&& ( Abs(Hero->Y - this->PosY()) < 8 )
This is specifically for when the player attempts to occupy the middle'ish region of the combo, yes?  Though this does beg the question, is this a solid combo?  (Like a Lockblock.)  Do scripts get activated when the player attempts to push themselves into the combo?

 

This detects if you are stepping on the combo; not pushing into the side. Pushing would need different logic.

Because I would expect some bit of code that says, to the effect, "If Link is Y-8 pixels below this combo and presses "up" for half a second, do the rest of this code." But I never see any. Why is that? :huh:

Because this code doesn't do that. A lot of code checks if you are on a combo, not next to one.

It's easy enough to figure out the rest of the directions of interaction though. The Y-8 thing would only effect the south direction due to the way the grid system works. Or is X-8 just a tradition of the system. ... or have I completely misunderstood why X-8 and Y-8 (As appropriate) are written.

There's no `-8` here, but `<8`. This means you are within 8 pixels of the combo, so you are mostly standing ON the combo. Distance.

this->PosX()
Remind me again why PosX needs parentheses?  ... or blank ones, at least?
Thanks much!

 

It's a FUNCTION. All function calls need parentheses, because that's how you call a function. This function has empty ones, because it doesn't take any parameters. `Screen->LoadFFC(5)` is a function, which takes one integer parameter.


This much I know: yes.

As an ordinary statement, any expression that "while" evaluates as "true" will cause it to run its block, and any non-zero value will register as "true" (which is apparently just a macro for "1" in C anyway).

`true` isn't a macro for `1` in ZScript, it is in C. However, int/float cast implicitly to bool; meaning that if you do `while(2)`, it converts that 2 to a true/false. By definition, `int == 0` is false, `int != 0` is true.


  • ShadowTiger likes this


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users