Additional Dropped Item Elements

[TheAbsolutionism]

Description

This PR aims to add additional elements relating to Dropped Items

---

Target Minecraft Versions: any
Requirements: none
Related Issues: #5110

[Fusezion]

iirc skript has a type registered for dropped entities can we make use of that instead of entity here so people don't interpret differently

[APickledWalrus]

Some initial thoughts

[Fusezion]

Some of the same as pickle probably

[TheAbsolutionism]

iirc skript has a type registered for dropped entities can we make use of that instead of entity here so people don't interpret differently

I'm not seeing any registered droppeditem or droppedentity

[Fusezion]

iirc skript has a type registered for dropped entities can we make use of that instead of entity here so people don't interpret differently

I'm not seeing any registered droppeditem or droppedentity

it's likely itementity and would be registered with NoDocs

[TheAbsolutionism]

it's likely itementity and would be registered with NoDocs ![image](https://private-user-

ahhh ok, appreciate it

[APickledWalrus]

Looking better!

[ShaneBeee]

Just a few thoughts.

[ShaneBeee]

Just some concerns I guess.

[ShaneBeee]

I'm still not a fan of returning null when something isn't null provided by Bukkit/Minecraft.
In my opinion this is super misleading.
ie: if owner/thrower of %itementity% is set: incorrectly returning false.
But if that is what the team wants, then I'll approve.

[APickledWalrus]

I think this is just about ready. I'm really liking the syntax changes.

[Fusezion]

Please don't hate me, mostly just concerns or questions

[ShaneBeee]

I'm still not a fan of returning null when something isn't null provided by Bukkit/Minecraft. In my opinion this is super misleading. ie: if owner/thrower of %itementity% is set: incorrectly returning false. But if that is what the team wants, then I'll approve.

@ShaneBeee I think this is fair, but for a Skript user, I'm not sure the distinction is important. I might argue that the thrower might as well be not set if it points to a non-existent entity. I'd imagine most users that want to obtain the thrower want to do something with that entity, but perhaps I am missing a larger use case. I'd love to hear what others think.

@APickledWalrus my main issue is when using this in conjunction with ... is set: ... it will return false even tho it shouldn't be false as it IS set.

[APickledWalrus]

my main issue is when using this in conjunction with ... is set: ... it will return false even tho it shouldn't be false as it IS set.

@ShaneBeee Yeah, I think that's fair. It could be confusing, though I do think it might as well be not set to the average Skript user (since they can't do anything with it). Of course, I'm operating on the assumption that it being a dead UUID means it is useless, which very well may not be the case.

[sovdeeth]

I'm ok with it returning a string uuid as a last resort, but I don't think there's a good solution either way. If we return a string uuid, then uuid of (owner of x) would be null if it returns a uuid, which I think is as confusing as it not being set when it's a uuid.
I'm generally ambivalent on the two options

[APickledWalrus]

I would say there should be a corresponding
(prevent|disallow) natural despawning of %itementities%

I'm also wondering if natural should be optional, as in prevent despawning of %itementities% (not 100% sure on that)

[TheAbsolutionism]

Let me know