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

Suggestions #4

Open
Blueyescat opened this issue May 5, 2018 · 6 comments
Open

Suggestions #4

Blueyescat opened this issue May 5, 2018 · 6 comments
Labels
enhancement New feature or request

Comments

@Blueyescat
Copy link
Contributor

Blueyescat commented May 5, 2018

1

If an item type can be an item or a block in the same time, then there should be a required "block" suffix to get the block of that item type. And using the item type without a suffix or using with "item" suffix should get the item. For example:

redstone [dust] block¦s <- should return the block
redstone [dust] [item¦s] <- should return the item

2

Item types with "any" prefix should exist, but not as an optional prefix because it just causes confusing/bugs.
Normally written item names shouldn't return random items, it should return the natural block/item. For example:

lit redstone torch¦es = minecraft:redstone_torch
unlit redstone torch¦es = minecraft:unlit_redstone_torch
[any] redstone torch¦es = lit redstone torch, unlit redstone torch

The user would think when using redstone torch it will return unlit redstone torch like in inventories or when you place a redstone torch but it will return lit or unlit torch randomly.

But an item type with "any" prefix can return random items, there is no a problem. So it should be:

lit redstone torch¦es = minecraft:redstone_torch
[unlit] redstone torch¦es = minecraft:unlit_redstone_torch
any redstone torch¦es = lit redstone torch, unlit redstone torch

So when the user uses "redstone torch" it will return unlit redstone torch.

Another example can be any apple for the 3 types of apples but golden apple should return the normal golden apple. If the user wants enchanted golden apple, then will use enchanted golden apple.

So i say, make the aliases user friendly.

@Syst3ms
Copy link

Syst3ms commented May 5, 2018

I mostly agree, except that making torches unlit by default is just bad, since they are on by default.

@Blueyescat
Copy link
Contributor Author

Oh i wrote it wrong, it should return lit redstone torch. But what if they want to use it as a block?

@Blueyescat
Copy link
Contributor Author

Blueyescat commented May 6, 2018

I'm confused about that suggestion lol. I think Skript needs something to seperate blocks and items.

@Syst3ms
Copy link

Syst3ms commented May 7, 2018

Here the problem is kind of a consistency problem, which Spigot also has. When we say "cauldron", is it the item or the block? If it's the item, then we should have "cauldron block" alongside, and "cauldron item" otherwise

@Snow-Pyon
Copy link

Spigot adds the block suffix to every constant in the Material enum that is identifying a Block, so, I'd say we should do the same.

@TheBentoBox
Copy link
Member

I agree with what was said here and I may make some changes to my aliases to reflect this. I'm personally a fan of any NOT being optional, I've done it in most of my aliases so far but that's to reflect old aliases since it was optional in a lot of them, at least at one point. But I think it's more clear to be able to say "If you want to refer to a whole category, use any". I also agree block should be part of the alias for any material whose Material enum entry uses block, even if we make it optional in the alias.

@TheLimeGlass TheLimeGlass added the enhancement New feature or request label Apr 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants