Closed cheeezburga closed 4 months ago
This is being caused because nearest entity
is an Expression
Here at Skript, our policy is to do these unchecked, unverified casts without properly checking and just suppress the warning, which is why this is occurring as a problem.
The easy fix is to just make the charge effect not do that cast, since it isn't necessary, but the larger question is why the %livingentities%
input is accepting %entities%
without any kind of conversion, since this will run into the same problem elsewhere.
This is being caused because
nearest entity
is an Expression returning an array of Entities, being cast to an Expression that wants to return an array of LivingEntities, and an array of Entities is not an array of LivingEntities, so it's failing.Here at Skript, our policy is to do these unchecked, unverified casts without properly checking and just suppress the warning, which is why this is occurring as a problem.
The easy fix is to just make the charge effect not do that cast, since it isn't necessary, but the larger question is why the
%livingentities%
input is accepting%entities%
without any kind of conversion, since this will run into the same problem elsewhere.
I feel like it might be a bit more complicated than that, since nearest entity
works fine, and player's spectator target
, which is an Expression\<Entity>, also worked fine in tests.
I feel like it might be a bit more complicated than that, since
nearest entity
works fine, andplayer's spectator target
, which is an Expression, also worked fine in tests.
No, it's exactly this, and it happens with a bunch of other syntax -- I'm testing it right now to find the whole list.
Basically, %livingentities%
permits Expression<Entity>
s and doesn't apply any kind of conversion, and because of the generic <LivingEntity>
type, when getArray
is called it tries to cast the array to a LivingEntity[]
which, clearly, it won't be, since it's an entity expression, so it's throwing the class cast exception.
What probably ought to be happening is that it should sub in some kind of converted Expression that filters out the incorrect elements and returns the array that's been asked for.
Having chased this issue down the rabbit hole, we discovered its cause is some expressions wrongly reporting their returntype as being different from the array type they return in get...
, so in this issue the charge the nearest creeper
fails because the expression promises to return a Creeper
(a LivingEntity
) but actually returns an array of Entities. This means the parser doesn't convert the expression.
I have a fix for this in the pipeline but I'd also like to find a way to address the more pervasive issue in future.
Skript/Server Version
Bug Description
I was testing some stuff with an effect I was making and tried passing
nearest armor stand
in where%livingentities%
were accepted and it threw a stack trace (see the errors section of this). If I usetarget
instead, it works as intended.I tested with the following syntax, as well as with my own effect:
Expected Behavior
Nearest entity was supposed to work as intended. Not super sure what else to say, as I have no idea why the error is occurring.
Steps to Reproduce
This is how I reproduced it, but I imagine it works with any effect that takes
livingentities
whennearest x
is used:make (nearest creeper) charged
Errors or Screenshots
Other
Sovde and I had a chat about this which lasted a few messages here (very useless). Most of the messages are about the effect I was trying to make, but Sovde found out that, to quote, "weirdly it's only for nearest x and not nearest entity", which I think might be worth mentioning.
Agreement