Spigot 1.16.3
MobHunting 7.5.8-b1097 (and probably previous releases)

What produces this in-game error

WARNING, this was a FAKE reward with no value

and how can I identify the immediate cause?

Im aware that Creative mode can destroy the Bags this is because the Lores is removed if you move the Items while in Creative mode. I cant fix that.

I noticed that if you move a skull reward around in a creative inventory it can remove the hidden lores especially if you wear it as a hat. I don't know if it shows as a fake reward or not when this happens since that was not what I was testing. Just thought it may point you in the right direction.

This happens if the hidden lores is missing or if you have tried to change the value.

Where do I find that in the configuration?

No where, what is it you want to achieve?

Do you have many fake rewards?

No where, what is it you want to achieve?
Do you have many fake rewards?

I want to understand where that message came from, and correct whatever caused it. I don't know what a fake reward is. The word "fake" does not appear

• in my configuration
• in the generated default configuration (ie., clean install)
• in the Overview page
• in the wiki
• in the MobHunting database
• in the BagOfGold database

I have not intentionally created a fake reward. How do I identify one?

Background: The FAKE reward is actually an problem I solved long ago. The problem was that I realized that players (using the right tool) was able to change the value of the item, just by changing the lores. This way they were able to cheat and get lot of money. So I had to find a solution to that.

The solution: The solution was to add an extra lore (the last one) containing an encrypted string. The encrypted string contain a HASH of the lores I don't want the players to be able to change. If the HASH does not match I write "This was a FAKE reward" and set the value to 0.

Bugs: There have been some bugs in the past which made the Item loose its value and this way it was detected as a FAKE reward.

The is no configuartion of this because FAKE rewards is not allowed, so it the test is hardcoded in the sourcecode.

So it sounds like I encountered a bug. I cannot replicate it, since I have no idea how it was generated. Perhaps the details should be logged when this occurs, so it can be investigated.

Exactly I cant reproduce it either. So I have assumed that it is an old bug or maybe old items store in the world. I do not anymore old items to test on, on my test-sever (because of all the testing)

I write "This was a FAKE reward" on the screen when I detect it. What more information would you like to have?

I just checked my code. A FAKE reward is only detected if the display name is the same as the BagOfGold display name in config and if the Lores is missing.

	private boolean isFakeReward(ItemStack itemStack) {
		if (itemStack != null && itemStack.hasItemMeta() && itemStack.getItemMeta().hasDisplayName()
				&& itemStack.getItemMeta().getDisplayName().contains(Core.getConfigManager().bagOfGoldName)) {
			if (!itemStack.getItemMeta().hasLore()) {
				return true;
			}
		}
		return false;
	}

if the HASH is wrong (because the lores is changed) I write some thing else

// Hash
			else if (str.startsWith("Hidden(5):")) {
				this.encodedHash = str.substring(10);
				String compareHash = Strings.encode(moneyStr + rewardTypeStr);
				if (!encodedHash.equalsIgnoreCase(compareHash)) {
					Bukkit.getConsoleSender().sendMessage(ChatColor.GOLD + "[BagOfGoldCore]" + ChatColor.RED
							+ "[Warning] A player has tried to change the value of a BagOfGold Item. Value set to 0!");
					money = 0;
					updateEncodedHash();
				}
			}

Because the test server is clean, I can guarantee that it was a new reward, not "an old one laying around". It would be nice to know what entity was killed. That would at least give a hint as to what to investigate. But I don't expect to see it again, so it's up to you.

All killed entities is already logged when /mh debud is enabled.

I dont think I will make any changes unless we are able to narrow down this problem. I have no idea about what to look for at the moment

OK, but I am not going to run in debug-mode all the time, waiting for an event that isn't likely to recur. I will reconsider, if it becomes a regular occurrence.