NullPointerException: Cannot invoke "org.bukkit.entity.Player.getWorld()" because "this.player" is null

[Folas1337]

https://mclo.gs/pMIMDqI

Using this setup:

Events:
  lootGenerateEvent1:
    type: custom
    custom_event_data:
      event: org.bukkit.event.world.LootGenerateEvent
      player_variable: getEntity()
    actions:
      default:
        - 'call_event: testCall1'
  testCall1:
    type: call
    actions:
      default:
        - 'to_range: 32;true: actionbar: Test;200'

When setting a Decorated Pot with the following command and breaking it: /setblock ~ ~ ~ decorated_pot{LootTable:"chests/end_city_treasure"} replace, potentially because the getEntity() returns null when decorated pots generate loot tables compared to chests.
The decorated pot only has a chest loot table for demonstration purposes. They usually use different loot tables.

I'm using this somewhat strange setup because it was the only way I could make an action bar appear within a range of a player.

The getEntity() method returns null for the decorated pot which it doesn't for other containers like chests, so I am assuming that's the reason but I'll leave the rest to you 🫡

[Ajneb97]

The spigot wiki says this about getEntity():

Get the entity used as context for loot generation (if applicable). For inventories where entities are not required to generate loot, such as hoppers, null will be returned. This is a convenience method for getLootContext().getLootedEntity().

If method is returning a value in some cases and null in others then you must add a condition to check for the container

[Folas1337]

The spigot wiki says this about getEntity():

Get the entity used as context for loot generation (if applicable). For inventories where entities are not required to generate loot, such as hoppers, null will be returned. This is a convenience method for getLootContext().getLootedEntity().

If method is returning a value in some cases and null in others then you must add a condition to check for the container

Add a condition like what? I was scratching my head over that as well.
Using something like %player% == %player% will always make the action trigger and the same goes for any attempts I made with %player% !startsWith ... or %player% !matches ...

Could we get some way to check if a method is returning null cause I can't think of one right now ☹️

Edit 1: Oh yeah and I don't want to restrict this to certain containers... even though you're right, I could but since new ones can always be added it would be much more future-proofed to have the ability to check the return value of a method for null properly.

[Optifyne]

Hello, as said on the Spigot API page:

This event is NOT currently called when an entity's loot table has been generated (use EntityDeathEvent.getDrops(), but WILL be called by plugins invoking LootTable.fillInventory(org.bukkit.inventory.Inventory, java.util.Random, LootContext).

So most likely you will always get "null" from trying to get the Entity, only when some plugins call the mentioned method, the event will be triggered.
Also there is none "current player" ("player_variable") in this event.
All this means that you can remove "player_variable" line at all.

To make "to_range" working you need to have some active player in the event, but we already knew that there is no active player could be in this event.

To make it work, you can obtain "variables_to_capture" to get the location of the InventoryHolder which was filled, and then call the event with "to_all" to call it for all players and check %is_nearby_<x>_<y>_<z>_<world>_<radius>% variable from the global variables:

  lootGenerate:
    type: custom
    custom_event_data:
      event: org.bukkit.event.world.LootGenerateEvent
      variables_to_capture:
      - '%world%;getInventoryHolder().getLocation().getWorld().getName()' # Obtain world
      - '%x%;getInventoryHolder().getLocation().getX().intValue()' # Obtain X coord
      - '%y%;getInventoryHolder().getLocation().getY().intValue()' # Obtain Y coord
      - '%z%;getInventoryHolder().getLocation().getZ().intValue()' # Obtain Z coord
    actions:
      default:
      - 'to_all: call_event: lootGenerateActions;already_stored' # Calling the event for all online players with already obtained variables
  lootGenerateActions:
    type: call
    conditions:
    - '%is_nearby_{x}_{y}_{z}_{world}_32% == true' # If the player is inside the necessary radius near to the "generated loot location", perform actions
    actions:
      default:
      - 'actionbar: Test;200'

It will show the actionbar to all players in radius of the 32 blocks near to the "generated loot location".

[Folas1337]

That's a solution, I agree but couldn't there be a way for users of the plugin to allow checking for null results of a method? Or perhaps the plugin should check it and just set the variable to an empty string in those cases?

There might be events where you only get a player object where even that can be null and then you couldn't do whatever might be the idea.

So perhaps I should change this to a feature request so an ability is added where you can check for null results?

[Optifyne]

That's a solution, I agree but couldn't there be a way for users of the plugin to allow checking for null results of a method? Or perhaps the plugin should check it and just set the variable to an empty string in those cases?

There might be events where you only get a player object where even that can be null and then you couldn't do whatever might be the idea.

So perhaps I should change this to a feature request so an ability is added where you can check for null results?

If you want to check for presence of something, you can check what %player% variable (or any other variable) will return to you with /ce debug <event> command, and check in conditions whether the %player% IS NOT EQUAL to this value. But in methods chain in "variables_to_capture", to avoid errors about calling methods on null objects, unfortunatelly you can not do this and avoid it. So to do something like this "%x%;getEntity().getLocation().getX()" you always need to know that getEntity() will not be null, but it will be always null until some plugin will not cause this event with special method, as was mentioned in my first message. And I am NOT sure that the getInventoryHolder() will NOT be used, so most likely it will be enough like currently even for custom plugins calls.

Current implementation still have some restrictions, for example when getInventoryHolder() will be null due to block breaking but not opening, but as I said, unfortunatelly this is not possible to check on null in methods chain, so this is limited implementation (you can try to use custom "BlockBreakEvent" event for that, check in conditions all necessary blocks and whether their loottables were already generated or not, and then disable the current LootGenerateEvent with /ce disable <event> command in actions, then enable it back after 1 tick, but this still may cause problems, like in this 1 tick none other "loot generating" will not work).

[Folas1337]

I'm afraid there might be a bit of a misunderstanding here. I've slightly shifted from my example to a broader solution that wouldn't only fix my issue but a general issue that I'm seeing with null return values.

At this point I'm mainly asking @Ajneb97 if there could either be a fix within the plugin which I could see by returning an empty string in the variable or catching null return values before. The latter I think would take away power from the user as they can't decide anymore what happens if a method returns null.

[Ajneb97]

I will see if I can add a new variable to custom events to show whether the player is present or not.