Closed TheBentoBox closed 5 years ago
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.
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!
Happy to hear!
@TheBentoBox Hey, is there anything I can do in this repository?
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.
Thanks @TheBentoBox !! and good luck too... You might want to see this: #1385, main repository
Bye! @redbrain1014
Alright, testing out the new alpha build from @bensku, here are the current issues I can find with the aliases system:
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.send "%tool%"
returns it with the material name instead of the alias.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)
send "%true if target block is dry oak fence else false%"
while looking at a waterlogged fence returns true.%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
)'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.(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.
yellow flower
to be an optional alias even though I'd prefer it returns as dandelion
by doing (dandelion|yellow flower)Ā¦s = minecraft:dandelion
).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.
Good to hear, and I definitely agree, the consistency in naming order is more of a nice to have in the future than anything.
Where do I download the plugin?
@TheBentoBox I might be missing something but do you know where I can download the plugin's .JAR file?
Hello?
@redbrain1014 on the GitHub page for Skript https://github.com/SkriptLang/Skript Click on "releases"
Thanks!
I believe this is all resolved. Aliases seem to basically work great now!
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:
[huge] red mushroom blockĀ¦s = minecraft:red_mushroom_block
, I could change the data value and it would still successfully compare my target block withred mushroom block
šThe Bad:
any tulipĀ¦s = red tulip, orange tulip, white tulip, pink tulip
, but giving myself or setting a block toany tulip
always sets it to the pink tulip (last in the grouped alias). I also haveany cobble[stone] [blockĀ¦s] = cobblestone, mossy cobblestone
and giving/setting a block toany 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?)pink tulip
orany flower
it fails, but it passes when compared toany small flower
. However, when doingsend "%target block%"
while looking at the pink tulip, it returnsany 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 (doingbroadcast "%true if target block is any flower else false%"
broadcasts false).set target block to furnace
and it sets a furnace, thensend "%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 alit furnace
even though we have the alias for it:broadcast "%true if target block is any repeater else false%"
broadcasts false when looking at a repeater, and setting a block to aninactive repeater
sets it to aminecraft:powered_repeater
(and vice-versa, setting anactive repeater
sets an inactive one) even though the aliases are defined properly:The Ugly:
So yeah, lots of weird issues but I think for a first test of the aliases it actually went decently well.