Player hunger about valence

[dyc3]

This sounds like implementing vanilla behavior, which is out of scope for valence. Is client behavior affected by this? In other words, does the client automatically update hunger and saturation without the server telling it to?

[SelfMadeSystem]

This sounds like implementing vanilla behavior, which is out of scope for valence. Is client behavior affected by this? In other words, does the client automatically update hunger and saturation without the server telling it to?

The client does not automatically update hunger and saturation without the server telling it to, but there is also no way to tell the client about their own hunger right now either. In my opinion, I agree that implement behavior such as automatically decreasing food level when player runs, automatic regeneration, etc. is out of scope, but I also believe that just implement the basics so that it's usable by devs wouldn't be outside the scope.

If anything, from what I can tell, I would say that the current state of #558 is actually outside the scope of valence regarding implementing status effect behavior. If you also believe it to be the case, I'll remove the behaviour and ready it to be merged.

I would love to discuss further what precisely are the non-goals of valence, as it's not clear in the README. For example, what exactly do you consider to be "vanilla behavior"? Because there's a lot that valence is already doing that vanilla is also doing. I'd just like it to be a bit clearer. Thx :)

[dyc3]

"Vanilla behavior" is any behavior that is not client predicted. If something the client does would cause it to become out of sync with server state, valence needs to account for that so that it's capable of detecting it and correcting client state if desired by the user.

For example: the furnace crafting recipe is vanilla behavior, but the concept of a crafting recipe is not. Minecraft's terrain generation is vanilla behavior, but the concept of chunks is not.

So regarding potions, we only need to implement what's necessary to get the client to show the effect in the UI. We don't need to implement any of the actual effects unless the client makes state predictions that would invalidate the server's state.

An exception we have is "would having this behavior or feature make it easier for end users without limiting anything", which is evaluated case by case, based entirely on opinion.

[SelfMadeSystem]

"Vanilla behavior" is any behavior that is not client predicted. If something the client does would cause it to become out of sync with server state, valence needs to account for that so that it's capable of detecting it and correcting client state if desired by the user.

For example: the furnace crafting recipe is vanilla behavior, but the concept of a crafting recipe is not. Minecraft's terrain generation is vanilla behavior, but the concept of chunks is not.

So regarding potions, we only need to implement what's necessary to get the client to show the effect in the UI. We don't need to implement any of the actual effects unless the client makes state predictions that would invalidate the server's state.

An exception we have is "would having this behavior or feature make it easier for end users without limiting anything", which is evaluated case by case, based entirely on opinion.

Alright, thanks for the clarification. I'll remove the potion stuff then and make it ready for merging then. I'll keep this issue open.