Minecraft Version

1.19.2

What happened?

Currently. I am using your mod in a unique way. And as such I allow players to eat food even if their hunger bar is full. The problem with this and your mod however, is that your mod doesn't increase diet values if previous hunger ='s the current hunger.
Line 143 of PlayerDietTracker

A fix and probably better way to go about this would be to check against PlayerEntity::canEat(stack.getItem().getFoodProperties().canAlwaysEat()) method instead. This method is a boolean that determines whether or not players can eat food actually and is also what allows players to eat golden apples with full hunger if the boolean in it is set to true(PlayerEntity::canEat(true)).

Now even if players are full on hunger, if they are allowed to consume that item, it will increase their diet values. If for whatever reason you find this would cause unexpected behavior, you could always include it as a toggle.

If you're curious on how I'm using your mod. I have players spawn with 90 in all values by default and a min of 30 on respawn. If they drop below 25 in any category, they start getting debuffs. Hunger if they drop below 25 in all. I use it more like an advanced hunger system. However, they must be able to eat always as a result. I include that in with a tweaker mod of mine making canEat always return true, but this mod is currently incompatible with the logic. It's cool when it works though. I have a custom patch running on my server.

How do you trigger this bug?

1. Install mod
2. Have full hunger
3. Eat golden apple.
4. No diet increase.
   ...

Loader

Fabric

Loader Version

0.14.21

API Version

No response

Mod Version

Diet 2.0.0 Beta 1.19.2

Relevant Log Outputs

No response

Looking into your code a little more for any adverse side effects of doing this. I notice you apply decay only when food level does not equal previous. With this addition/change if you decide to include it, it might be worth checking against saturation as well for decay(although with less decay since it would be more extreme). Probably not worth adding in this mechanic now that I've thought about it more. Probably better to just keep it a check only against actual hunger, but up to you.

I'm not entirely sure the differences between your different consume methods either, so I'm not sure what should be taken into consideration there, but it would be nice to have diet values get improved by eating food if you're allowed to eat it.PlayerEntity::canEat(stack.getItem().getFoodProperties().canAlwaysEat()) I'm not sure how you could go about it with the consume method that has a itemstack List parameter thought. I'll let you decide on that one.

Thanks for getting back to me.

If enabled, this would essentially give players the ability to improve their diet values without any threat of decay.

I think your main concern could be addressed by having saturation decremenents count as 10 percent of the normal decay value or something low like that(Also gotta remember that saturation has I think 4 parts to a single hunger bar piece). You should also keep in mind that they still run out of food, and food is a limited resource that they have to get more of. Unless they're eating for the fun of it, they will run out of regular hunger normally. This has been the case when we played with it anyways on my server.

Hmm, so, in your use-case, a player doesn't experience hunger at all unless all food groups drop below a certain amount?

Well they still experience regular hunger if they don't eat at all and can still even starve, but if they neglect all their food groups, it will apply the hunger status effect & really mess em up. On top of that, I apply slowness for each category below 25 percent.

My main concern with letting overeating add diet values is that diet decays based off the hunger meter. If enabled, this would essentially give players the ability to improve their diet values without any threat of decay. As an example, say golden apples can add to the fruits group even when the hunger meter is full. If they had 50%, they could instantly eat a dozen golden apples and immediate jump to 100%. The balance of Diet as a whole is the push-pull between the decay as hunger does down and the ability of players to replenish that in finite amounts (emphasizing player choice in which foods they select).

That isn't to say that I'm rejecting this suggestion, I'm just outlining my thoughts to further discussion and potentially figure out a way this could work.

I have players spawn with 100 in all values by default and 50 on respawn. If they drop below 25 in any category, they start getting debuffs. Hunger if they drop below 25 in all. I use it more like an advanced hunger system. However, they must be able to eat always as a result.

Hmm, so, in your use-case, a player doesn't experience hunger at all unless all food groups drop below a certain amount? Is that right? So diet functions as the first layer of this advanced hunger system and only when neglected does it fall to the normal hunger system as the second layer. If that's the case, this is certainly a niche use-case but I understand why this particular limitation of the Diet system isn't ideal. Although, if that's the case, since Diet only decays off of hunger drops, how does it even decay at all in that scenario?

However, that's perhaps a good thing. Maybe someone wants the deathPenaltyMin to be 50, so the game won't penalize beyond 50 if they die, but set a min value of thirty, so if they're under 50 they keep their current value unless they're under 30, in which it resets to thirty.

Not intended behavior, but fair point. Maybe I'll need to introduce another config option anyways.

Anyways that's a little off topic, what are you thinking with my main suggestion of overeating?

Still need to think it over. Leaning towards accepting the idea, but I need to spend some time considering it.

You could have it as a config option as well. Like: Allow Overeating in the config.

Speaking of config, Can you add an additional config option for minimal spawn values on respawn. Like the minimal each value will be when a player respawns? If their current value is under it on death, it'll go up to the minimal kinda thing.

Speaking of config, Can you add an additional config option for minimal spawn values on respawn. Like the minimal each value will be when a player respawns? If their current value is under it on death, it'll go up to the minimal kinda thing.

That should be the case already, with deathPenaltyMin in diet-server.toml that handles minimum values on death.

I've seen that. It prevents the penalty loss from activating beyond that point, but if a player is below that point already, it keeps their current value.

For example, say you set the deathPenaltyMin to be 30. If the player has diet values 25 or anything under thirty. They'll still be at 25 on respawn. If they're over 30 though, it would bring em down to 30 max.

Perhaps that's not the intended behavior? I thought it was. I was thinking a config option that would bring you up to to a point tho if you're at under the value already. deathPenaltyMin currently doesn't do that.

However, that's perhaps a good thing. Maybe someone wants the deathPenaltyMin to be 50, so the game won't penalize beyond 50 if they die, but set a min value of thirty, so if they're under 50 they keep their current value unless they're under 30, in which it resets to thirty.

Anyways that's a little off topic, what are you thinking with my main suggestion of overeating?

I mean again, you could always include it as a config option. Allow_Overeating true/false

Well, perhaps it would be better named as Allow_Overeating_diet_benefit true/false