Skip to content

Properly Handle Blockdata in Click Event #7886

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: dev/patch
Choose a base branch
from

Conversation

erenkarakal
Copy link
Member

@erenkarakal erenkarakal commented May 22, 2025

Problem

If you use the on right click on %blockdata% pattern and click on an entity, it always assumes the object is either an entity or an item type, but not block data, which can cause the server to crash.

Solution

Moved the blockdata check a bit earlier to fix the issue and added an instanceof ItemType check to prevent possible crashes in the future.

Testing Completed

Tested on right click on pig, on right click on stone, on right click on stone_button[] and on right click on stone_button[powered=false] to ensure nothing was broken with this fix.


Completes: #7885
Related: none

@erenkarakal erenkarakal requested a review from a team as a code owner May 22, 2025 10:33
@erenkarakal erenkarakal requested review from Efnilite and cheeezburga and removed request for a team May 22, 2025 10:33
@skriptlang-automation skriptlang-automation bot added the needs reviews A PR that needs additional reviews label May 22, 2025
Copy link
Contributor

@Absolutionism Absolutionism left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo, kinda weird having the conditions go from
object instanceof to entity != null then to object instanceof

@Absolutionism
Copy link
Contributor

Also, maybe this can be a good opportunity for a JUnit test.

@erenkarakal
Copy link
Member Author

imo, kinda weird having the conditions go from object instanceof to entity != null then to object instanceof

it's either that or I check instanceof BlockData twice, unless I'm missing something

@Absolutionism
Copy link
Contributor

it's either that or I check instanceof BlockData twice, unless I'm missing something

Why would you need to check it twice? I believe the only real fix was just adding the object instanceof ItemType itemType inside the entity != null block

@erenkarakal
Copy link
Member Author

it's either that or I check instanceof BlockData twice, unless I'm missing something

Why would you need to check it twice? I believe the only real fix was just adding the object instanceof ItemType itemType inside the entity != null block

there would be one inside there and another outside (the one I moved)

@Absolutionism
Copy link
Contributor

I just tested with this

return type.check(event, (Predicate<Object>) object -> {
	if (entity != null) {
		if (object instanceof EntityData<?> entityData) {
			return entityData.isInstance(entity);
		} else if (object instanceof ItemType itemType) {
			Relation compare = DefaultComparators.entityItemComparator.compare(EntityData.fromEntity(entity), itemType);
			return Relation.EQUAL.isImpliedBy(compare);
		}
	} else if (object instanceof ItemType itemType) {
		return itemType.isOfType(block);
	} else if (blockDataCheck != null && object instanceof BlockData blockData)  {
		return blockDataCheck.matches(blockData);
	}
	return false;
});

You wouldnt need a instanceof BlockData check inside.
The reason why the ItemType has a check inside is because some items and their respective entities share the same name/codename. So if we're given an ItemType we check to see if that item has a matching entity, which is stored in the aliases.

BlockData are specific, the user has to put [] at the end. In which case we shouldn't need to check for a matching entity

@APickledWalrus
Copy link
Member

It might not hurt to have a comment there to clarify why a BlockData check isn't necessary (even though an ItemType check is present)

@erenkarakal
Copy link
Member Author

It might not hurt to have a comment there to clarify why a BlockData check isn't necessary (even though an ItemType check is present)

its for comparing like a boat item to an entity boat if that's what you are asking

@Absolutionism
Copy link
Contributor

its for comparing like a boat item to an entity boat if that's what you are asking

He was saying to put a comment in the code

@erenkarakal
Copy link
Member Author

language barrier :(

@skriptlang-automation skriptlang-automation bot added patch-ready A PR/issue that has been approved and is ready to be merged/closed for the next patch version. and removed needs reviews A PR that needs additional reviews labels May 22, 2025
@sovdeeth sovdeeth added the bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. label May 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. patch-ready A PR/issue that has been approved and is ready to be merged/closed for the next patch version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants