Skript: Block events incorrectly firing for other blocks if they're part of the same alias group

Created on 28 Sep 2018  路  17Comments  路  Source: SkriptLang/Skript

Code:

on break of diamond ore:
    cancel event
    set block to air
    drop 1 diamond

Version:
alphav4

Issue:
Breaking iron,gold,lapis,coal ores gives a diamond with this skript XD

Notes:
on alphav4 - no errors
on alphav3 - error in console (idk if it's important, it's not latest)

bug completed medium

Most helpful comment

  • [ ] Bug
  • [ ] Feature
  • [x] EASTER EGG

Pardon me, I had to <3

All 17 comments

Bug still in alphav5 ... When I break coal ore etc I'm getting diamond with skript on break of diamond

Can anyone else confirm this for me?

@ShaneBeee could you? ; d

Yes I can confirm this.
Here is my findings.
Using the code @iOshawott posted, I get diamonds

I threw in a debug check

on break of diamond ore:
    send "Block: %event-block%"
    cancel event
    set block to air
    drop 1 diamond

It sends "coal ore" ... but still cancels the event and drops diamonds, silly skript!

If I change it up a bit:

on break:
    if event-block is diamond ore:
        cancel event
        set block to air
        drop 1 diamond

this one works fine

This is important, then. It's probably happening with a lot of blocks then; perhaps it's for any grouped alias @bensku ?

Okay, so, I'll explain what I got from my tests.
https://github.com/SkriptLang/Skript/blob/c7c10c41ae600240e1d2b474c1e50d8d1b088e29/src/main/java/ch/njol/skript/aliases/AliasesProvider.java#L174
This variable and the getSubtypes method is named wrongly, it gets the supertype of a subtype, not the subtype of a supertype (was this actually meant to do this? @bensku), and since it gets the supertype of the subtype the folllowing happens:
the event-block (coal ore), is compared with diamond ore through ItemType#getSupertypeOf, what this does is get the "subtypes" of the "supertype" as you can see here:
https://github.com/SkriptLang/Skript/blob/c7c10c41ae600240e1d2b474c1e50d8d1b088e29/src/main/java/ch/njol/skript/aliases/Aliases.java#L528-L529
And then it checks if the list of subtypes (we're getting diamond ore's supertype, so, it's equal to any ore) contains the event-block (coal ore), which results in true.

That is not intentional. Still, easiest fix might be making it intentional.

  • [ ] Bug
  • [ ] Feature
  • [x] EASTER EGG

Pardon me, I had to <3

Note #1647 for another instance of this issue. Updating the title to make it more clear what the exact issue is.

And just for clarity, I'll note that I DID just check this with a normal comparison, i.e. looking at a coal ore and doing send "%true if target block is diamond ore else false%" and it worked as expected (i.e. the comparison did not pass). Also works fine for held item comparisons. Seems to purely be an issue with conditional block events.

Should be fixed for the next release.

@Snow-Pyon it isn't still fixed in beta-2

on break of gold ore:
    send "zloto"

it still happens when your breaking diamond ore

This issue looks more strange

on break of ...

gold ore = detects gold, iron, coal, lapis, diamond, emerald, quartz
iron ore = detects iron, coal, lapis, diamond, emerald, quartz
coal ore = detects coal, lapis, diamond, emerald, quartz
lapis ore = detects lapis, diamond, emerald, quartz
diamond ore = detects diamond, emerald, quartz
redstone ore = detects emerald, quartz
emerald ore = detects emerald, quartz
quartz ore = detects quartz

Don't know the alias code well enough to say but is this potentially due to @Snow-Pyon's change in this commit? (which WAS necessary to fix other issues)

Either way, the important thing to note is the order in which the any ore alias group was declared (which is the reason I asked the above question):

any ore = gold ore, iron ore, coal ore, lapis ore, diamond ore, redstone ore, emerald ore, nether quartz ore

You'll see the issue is they're matching with any block after them in the alias group.

I've fixed a similar issue before. It turned out to be caused by aliases system handling handling plural mark wrong. However, this could probably also be caused by broken aliases. Or, this might be a completely unrelated issue.

Supertype handling, as I originally wrote it, was unnecessarily complicated. I think I figured out a way to make it much simpler with loss of some Java methods that were not used outside of aliases system.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Coolfire02 picture Coolfire02  路  3Comments

DeagoTheDoggo picture DeagoTheDoggo  路  3Comments

Anoniempje1234 picture Anoniempje1234  路  3Comments

wohahobg picture wohahobg  路  3Comments

Snow-Pyon picture Snow-Pyon  路  4Comments