Skip to content
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

[BUG] is block comparison #5536

Open
1 task done
Fusezion opened this issue Mar 19, 2023 · 7 comments
Open
1 task done

[BUG] is block comparison #5536

Fusezion opened this issue Mar 19, 2023 · 7 comments
Labels
bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. PR available Issues which have a yet-to-be merged PR resolving it priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation).

Comments

@Fusezion
Copy link
Contributor

Skript/Server Version

[06:57:49 INFO]: [Skript] Skript's aliases can be found here: https://github.com/SkriptLang/skript-aliases
[06:57:49 INFO]: [Skript] Skript's documentation can be found here: https://docs.skriptlang.org/
[06:57:49 INFO]: [Skript] Skript's tutorials can be found here: https://docs.skriptlang.org/tutorials
[06:57:49 INFO]: [Skript] Server Version: git-Paper-307 (MC: 1.19.2)
[06:57:49 INFO]: [Skript] Skript Version: 2.7.0-beta1 (skriptlang-github)
[06:57:49 INFO]: [Skript] Installed Skript Addons: 
[06:57:49 INFO]: [Skript]  - skript-gui v1.3 (https://github.com/APickledWalrus/skript-gui)
[06:57:49 INFO]: [Skript]  - SkBee v2.7.8 (https://github.com/ShaneBeee/SkBee)
[06:57:49 INFO]: [Skript] Installed dependencies: None

Bug Description

When attempting to compare a variable with is a block, the script is unable to determiner if this it true and returns false

Expected Behavior

For the output to return true if given item is a valid block type

Steps to Reproduce

command /example <block:item>:
  trigger:
    send "Literal: stone is a block" if stone is a block, else "Literal: stone is not a block"
    send "NonLiteral: %{_block}% is a block" if {_block} is a block, else "NonLiteral: %{_block}% is not a block"

Errors or Screenshots

image

Other

No response

Agreement

  • I have read the guidelines above and affirm I am following them with this report.
@Fusezion Fusezion changed the title [BUG] type comparison invalid [BUG] is block comparison Mar 19, 2023
@AyhamAl-Ali AyhamAl-Ali added the investigating The core developers are currently investigating this issue. Usually used for complex cases. label Mar 19, 2023
@TheLimeGlass
Copy link
Collaborator

The local variable is never set

@Fusezion
Copy link
Contributor Author

Fusezion commented Mar 19, 2023

The local variable is never set

set via the command system <block:item>

@TheLimeGlass
Copy link
Collaborator

That's a dumb new addition.

@TheLimeGlass TheLimeGlass added bug An issue that needs to be fixed. Alternatively, a PR fixing an issue. priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation). and removed investigating The core developers are currently investigating this issue. Usually used for complex cases. labels Mar 19, 2023
@Fusezion
Copy link
Contributor Author

That's a dumb new addition.

been around for years as far as I'm aware

@AyhamAl-Ali
Copy link
Member

That's a dumb new addition.

That's actually was added so long time ago, but almost no one knew it until a tutorial about commands was added (see SkriptLang/skript-docs#18)

@TheLimeGlass
Copy link
Collaborator

TheLimeGlass commented Mar 19, 2023

Issue is Skript is considering condition {_block} is a block to be CondCompare rather than CondIsBlock as it should be. This is due to Variable being an Object and thus gets parsed as an UnparsedLiteral and fits in the CondCompare patterns. Skript really shouldn't be picking CondCompare because it's not a valid syntax, but it's thinking block from the syntax is a Literal like an ItemType so block is an UnparsedLiteral, meaning it's thinking it's going to compare a variable to an ItemType or something Literal.

Both my fixes #5503 and #5504 do not solve this issue, unrelated to those.

Parser level issue.

@AyhamAl-Ali
Copy link
Member

AyhamAl-Ali commented Mar 19, 2023

I remember this was an old issue with CondCompare loading before some other conditions and since they share the same syntax is|are|etc. the parser goes with ConCompare rather than the proper condition class.

I think this can be solved by using priorities just like how classes are registered

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. PR available Issues which have a yet-to-be merged PR resolving it priority: medium Issues that are detrimental to user experience (prohibitive bugs or lack of useful implementation).
Projects
None yet
Development

No branches or pull requests

3 participants