Issues & inconsistencies when testing new aliases

[TheBentoBox]

I tested a build of the aliases-rework branch from the main repo with the aliases from this repo as of today since I think we've gotten them to a "complete at a cursory glance" state. Aside from obvious issues like a memory heap error when it tries to parse the +global-variations.sk file, here are my findings when testing in-game:

The Good:

• For aliases that parsed properly (some didn't due to version of variation issues), I seemed to be able to set blocks to aliases and give items to myself.
• If I define an alias with no tags, it seems to be pretty lenient, e.g. when I had [huge] red mushroom block¦s = minecraft:red_mushroom_block, I could change the data value and it would still successfully compare my target block with red mushroom block 👍
• In general, the basic parsing seems to be working 👍 Progress is good.

The Bad:

• Grouped aliases don't behave quite as I expected. I have any tulip¦s = red tulip, orange tulip, white tulip, pink tulip, but giving myself or setting a block to any tulip always sets it to the pink tulip (last in the grouped alias). I also have any cobble[stone] [block¦s] = cobblestone, mossy cobblestone and giving/setting a block to any cobble always gives me normal cobble (the first in the grouped alias). So it doesn't work randomly like it does currently (maybe that's ok?)
• If I look at a pink tulip and try to compare it to pink tulip or any flower it fails, but it passes when compared to any small flower. However, when doing send "%target block%" while looking at the pink tulip, it returns any flower. This is obviously weird for two reasons: a block shouldn't return a grouped alias, and it's returning an alias which it doesn't even successfully compare against (doing broadcast "%true if target block is any flower else false%" broadcasts false).
• Some blocks seem to return as their material. I can do set target block to furnace and it sets a furnace, then send "%target block%" returns "FURNACE" while a lit one returns "BURNING_FURNACE" (in all caps like that, like an enum entry). I also can't set or compare a block to a lit furnace even though we have the alias for it:

  unlit furnace¦s = minecraft:furnace
  lit furnace¦s = minecraft:lit_furnace
  [any] furnace¦s = unlit furnace, lit furnace

• Another example of some strangeness: broadcast "%true if target block is any repeater else false%" broadcasts false when looking at a repeater, and setting a block to an inactive repeater sets it to a minecraft:powered_repeater (and vice-versa, setting an active repeater sets an inactive one) even though the aliases are defined properly:

  (inactive|unpowered) [redstone] repeater¦s = minecraft:unpowered_repeater
  (active|powered) [redstone] repeater¦s = minecraft:powered_repeater

The Ugly:

• Global variations file can't parse at all, at least on my local 32-bit Java. Heap/memory error that I linked above.

So yeah, lots of weird issues but I think for a first test of the aliases it actually went decently well.

[bensku]

Some global variations appear to fail parsing even for me, even though no out of memory error is encountered. I'm currently investigating why this happens.

[bensku]

1.13 build now manages to fully start, and scripts are... somewhat usable? Quality of aliases seems really good, actually; the main issues are probably Skript bugs. Thanks everyone and especially @TheBentoBox for great work!

[TheBentoBox]

Happy to hear!

[redbrain]

@TheBentoBox Hey, is there anything I can do in this repository?

[TheBentoBox]

Not much left actually. The only empty file is transportation.sk but there's an in-progress PR open for that from Blue. Of course, feel free to look over any of the other files and add any aliases you notice as missing or which could be more detailed, then open a PR. There have been a number of PRs from @APickledWalrus with various random enhancements like that which may give you an idea of the types of improvements that may be left to be made.

[redbrain]

Thanks @TheBentoBox !! and good luck too... You might want to see this: #1385, main repository

[redbrain]

Bye! @redbrain1014

[TheBentoBox]

Alright, testing out the new alpha build from @bensku, here are the current issues I can find with the aliases system:

• Aliases are still being placed in an aliases folder within the JAR but they seem to need to load from aliases-english, or at least I don't seem able to use some of the aliases until I move them into there manually by editing the JAR.
• Holding more than one of ANYTHING and doing send "%tool%" returns it with the material name instead of the alias.
• Blocks are returning as and successfully comparing against incorrect block states. This goes for every single block with states. e.g. Every pison base I look at and send "%target block%" sends downward facing extended non-sticky piston regardless of its direction or if it's extended, while every piston head sends south facing piston head (regardless of direction), every cocoa bean sends east cocoa plant, etc.(edited)
  • By "comparing against incorrect block states" I mean send "%true if target block is dry oak fence else false%" while looking at a waterlogged fence returns true.
  • Also interesting is that the wording here is inconsistent. The direction variation is %direction%[ward] [facing]; the piston sends it in full (downWARD FACING), the head just sends facing with no "ward" appended (south FACING), and the cocoa doesn't use either of the optional parts (just east)'
• In a very recent commit I added unstable TNT aliases in a 1.13.1 or newer section since that state wasn't re-added until 1.13.1 but I'm getting errors on start-up saying the block state doesn't exist (eight errors, actually) even though it shouldn't be trying to parse that at all if I'm not on 1.13.1.
• There also isn't really any consistency as to which option ends up as the one that gets send/used as the default for blocks with optional parts. For example, both the living and dead pink coral accept (brain|pink) as the descriptor (since the game calls it brain coral and the color is pink), but the living one returns as living brain coral and the dead one returns as dead pink coral. I checked and confirmed they're declared the same way.
  • It'd be nice if possible for this to be consistent so we can essentially control the name of a block by what option we put first (e.g. I'd like yellow flower to be an optional alias even though I'd prefer it returns as dandelion by doing (dandelion|yellow flower)¦s = minecraft:dandelion).

[bensku]

It seems that I managed to fix to comparison bug, that specific case at least. Working on string representation issue.

Consistency of string representations would be nice, but is ultimately not critical to have working for first release.

[TheBentoBox]

Good to hear, and I definitely agree, the consistency in naming order is more of a nice to have in the future than anything.

[redbrain]

Where do I download the plugin?

[redbrain]

@TheBentoBox I might be missing something but do you know where I can download the plugin's .JAR file?

[redbrain]

Hello?

[ShaneBeee]

@redbrain1014 on the GitHub page for Skript https://github.com/SkriptLang/Skript Click on "releases"

[redbrain]

Thanks!

[TheBentoBox]

I believe this is all resolved. Aliases seem to basically work great now!