Allow scripts to get the client protocol version in non-debug builds.

[red-001]

example usecase: it could be used by a mod that manipulates the chat to check if the client will display the chat message to the client before sending it to the server.

[sfan5]

This needs careful consideration
usecase?

[shacknetisp]

This is something I would appreciate, currently I had to enable this by editing the source and recompiling to continue supporting both older and new clients with the installed chat mods. Otherwise there's no way to tell if the client will echo their chat automatically or not.

Perhaps a more detailed table would be better than just the raw protocol, however, basic example that I could use:

{
 self_chat_echo = true, -- Will client echo their own chat?
 formspec_close = true, -- Will client close formspecs on ""?
}

[nerzhul]

in CSM can be useful, but we have MT version too, you don't need to know protocol version, release version should be the norm

[SmallJoker]

@nerzhul I think it's better to use the protocol version here. It clearly shows what the client supports if there were changes. That would make it work better for dev clients, where it's not known what changes it uses.

[nerzhul]

okay

[rubenwardy]

I'd prefer a feature query system for clients. This would be implemented using protocol version under the hood, but mods wouldn't need to be exposed to that.

Checking against a protocol version is not a very nice API, it's much better and way more readable to check a feature

if player:has_feature("formspec_close_on_empty_string") then
    minetest.show_formspec(player:get_player_name(), "", "")
else
    minetest.show_formspec(player:get_player_name(), "", "size[1,1]button_exit[1,1;1,1;close;close]")
end

It also means that if we ever get the client to declare the features it supports, then mods won't be broken.

[SmallJoker]

@rubenwardy This way is somewhat KISS from C++ side but I agree, checking against a table of features like in minetest.features is easier to understand for modders that aren't familiar with the protocol versions.
An issue that might appear with that is, that it gets forgotten in new added features with protocol bumps, resulting in outdated information.

[rubenwardy]

An issue that might appear with that is, that it gets forgotten in new added features with protocol bumps, resulting in outdated information.

minetest.features has the same problem - it's better to make adding feature flag a merging requirement somehow (although you can't CI this).

[rubenwardy]

Erm, you didn't address my comments. Checking the protocol version is a bad API.

[nerzhul]

@rubenwardy i think both are useful if needed

[SmallJoker]

The suggested function has_feature looks very promising but until someone's willing to implement that (what sometimes might take a very long time), it seems fine to offer at least one way to check the features.
At least this pull wasn't stalling ;)

[bigfoot547]

@nerzhul why "Aborted"?
Should be in "Done"

[nerzhul]

i think triage error, but you arevery late: p