This relates to the mod not respecting vanilla Minecraft game mechanics ("gamerules"), not a config with the mod. I have renamed the already-closed #147 which got misinterpretted as a different issue. Hopefully this description should make things clearer.

Steps to Reproduce

1. Set up the mod correctly so that you can view relayed event messages.

2. Run /gamerule sendDeathMessages true followed by /kill @s

• ✅ A death message is shown in the game and is relayed to Discord.

3. Run /gamerule sendDeathMessages false followed by /kill @s

• ✅ A death message is not shown in the game.
• ❌ A death message is is relayed to Discord.

4. Run /gamerule announceAdvancements true followed by /advancement grant @s only minecraft:adventure/arbalistic

• ✅ An advancement message is shown in the game and is relayed to Discord.

5. Run /gamerule announceAdvancements false followed by /advancement grant @s only minecraft:adventure/arbalistic

• ✅ An advancement message is not shown in the game.
• ❌ An advancement message is relayed to Discord.

Expected Behaviour

The gamerules showDeathMessages and announceAdvancements should control whether death and advancement messages are relayed to Discord respectively. When either is set to true, their respective message type should be relayed as normal; but if either is set to false then their respective message type should not be relayed to Discord.

Commentary

The solution to this is not simply changing the mod's config, because being able to change these in-game lets you dynamically determine when they appear and when they do not.

There is a very janky work-around for showDeathMessages. You can make a data pack which defines a custom damage type with a malformed translation key and add it to several damage-context-bypassing registry tags, and you add the malformed part of the translation key to the mod's chat filter. Then when you want to kill a player silently you have to change the gamerule and kill them with /damage and that damage type instead of /kill. This should not be considered as an acceptable or "intended" way for users to get around this bug with the mod.

There is no workaround for announceAdvancements.

Suggested Changes:

The mod's deathMessages and advancementMessages configs should be changed to have three options, "GAMERULE", "ALWAYS", and "NEVER". "ALWAYS" should act like true does now, "NEVER" should act like false does now, and "GAMERULE" should make the mod respect those vanilla gamerules at the moment of their creation. "GAMERULE" should be the default value to avoid confusion as it should be expected that the mod correctly respects gamerules' effect on chat/event messages.

Fixing this would also involve letting CraterLib read gamerules.

Similar to #146, this will be a non-rollback (or breaking) config change as well, so will also be implemented/fixed in next minor release

Edit: Side note, not really a bug, since the mod was never designed to respect game rules in the first place, and you're literally the first to try and use it. So this is more a feature request xD

the mod was never designed to respect game rules in the first place, [...] So this is more a feature request

That's fair, but I see it as a bug in the sense that I would expect the mod to, by default, relay accurately what players can see in-game, so having extra messages appear that would normally never be intended to be seen by anyone is problematic.

Also, it's highly likely that this has affected others but wasn't important enough to warrant a formal report. In cases such as mine (a server owner) or in mini-games on servers which need dynamic control over these visuals, it's an important issue.

Implemented in 3.3.0