Was in the Developer chat and @Aidden explained the difference between Null/Validity checking. Here is an adaption of the conversation: When you get an object from the game, you store that item in memory (RAM), if the object didn't exist in game, the memory location will therefore have nothing in it, essentially being null. However, if the object did exist in game, data about the object is then stored in memory so the memory location that the object points to is being used and isn't going to change unless you tell the program to change it. You need to first null check in order to make sure the object actually existed in the game. If you need to know if the object is still in the game after that, an isValid check would be suitable as it's live state isn't reflected in memory. What's stored in memory is simply a snapshot of how the game was at the time of setting the objects value and doesn't record live changes within the game unless you're constantly re-setting the variable. Short and sweet.
Just a quick addition. If the object inside the game stops existing ie you go to a different area, and you have previously stored that object in your bot, your object won't be null, even though the object no longer exists in the games memory. This is why your bot absolutely must be grabbing the object from the game before the first time you use it every loop. If you were to store the object at the top of your bot, that will get the object from the game the second the bot starts. And if you don't update this variable every loop, you'll eventually be referencing an object that is no longer in the game (even though it might not be null for you).This will cause your bot to stop working very quickly because the object won't be null, but when you try to interact with it for example, the object won't exist in-game so you'll just stand there doing nothing.
