[CS 1.6] messagemode command

[barcasl3]

Hi! After the new update of today, the messagemode command is getting blocked, therefore rendering big parts of AMXMODX unusable, and also, my user system unusable, as it depends on that command for user input. My question would be: why was it necessary to block that command? And if it was very necessary, then please provide us an alternative to get input from users. Thanks!

[RauliTop]

Also, connect command can't be used by third-party plugins: Could not execute privileged command "Connect" xx.xx.xx.xx:27035

Error about messagemode: Server tried to send invalid command:"messagemode"

All issues with cl_filterstuffcmd in 0...

[barcasl3]

Yeah, but connect may be explainable, but messagemode? What was the problem with that one?

[RauliTop]

Yeah, but connect may be explainable, but messagemode? What was the problem with that one?

Connect can be bypassed before update, now can't (? not 100% sure) Also they blocked messagemode

Waiting for see if is something more broken

[Mistrick]

messagemode was used for avoid client filter but current solution broke all plugins which work with messagemode. devs should make more elegant solution for saving backward compatibility.

[barcasl3]

Yeah, but connect may be explainable, but messagemode? What was the problem with that one?

Connect can be bypassed before update, now can't (? not 100% sure) Also they blocked messagemode

Waiting for see if is something more broken

I am in search of a bypass for messagemode for like 2 hours or so, but nothing yet, nothing seems to work, and AFAIK there is no other way to properly get user input for a system like this...

[vidme]

Yeah, but connect may be explainable, but messagemode? What was the problem with that one?

Connect can be bypassed before update, now can't (? not 100% sure) Also they blocked messagemode Waiting for see if is something more broken

I am in search of a bypass for messagemode for like 2 hours or so, but nothing yet, nothing seems to work, and AFAIK there is no other way to properly get user input for a system like this...

back to the console commands :/

[barcasl3]

Yeah, but connect may be explainable, but messagemode? What was the problem with that one?

Connect can be bypassed before update, now can't (? not 100% sure) Also they blocked messagemode Waiting for see if is something more broken

I am in search of a bypass for messagemode for like 2 hours or so, but nothing yet, nothing seems to work, and AFAIK there is no other way to properly get user input for a system like this...

back to the console commands :/

Yup, very convenient, and user friendly......:/

[metita]

Upvote for visibility, learn to fix things without broking essential gameplay stuff.

[barcasl3]

Does anyone have any temporary, user-friendly solution for replacing the messagemode command?

[Giferns]

Various client protectors can block messagemode too, so I think it's better to avoid using it completely. Usually, i use chat input. Example: 1) Player press on menu item 2) System (amxmodx plugin) tells him (by chat msg) that he must enter "required data" in chat. 3) Player press 'y' or 'u' (messagemode) and enters requested data. To implement this, you need to hook say/say_team, and use marking (bool) variable, that tells to system that player in "input mode" when hook triggers. After input variable resets to false. Also, i provide 'say /cancel' option to cancel input.

[barcasl3]

Various client protectors can block messagemode too, so I think it's better to avoid using it completely. Usually, i use chat input. Example:

1. Player press on menu item
2. System (amxmodx plugin) tells him (by chat msg) that he must enter "required data" in chat.
3. Player press 'y' or 'u' (messagemode) and enters requested data. To implement this, you need to hook say/say_team, and use marking (bool) variable, that tells to system that player in "input mode" when hook triggers. After input variable resets to false. Also, i provide 'say /cancel' option to cancel input.

Thank you very much for that insight, that helped me a lot.

[BaHeK1994]

Various client protectors can block messagemode too, so I think it's better to avoid using it completely. Usually, i use chat input. Example:

1. Player press on menu item

2. System (amxmodx plugin) tells him (by chat msg) that he must enter "required data" in chat.

3. Player press 'y' or 'u' (messagemode) and enters requested data.
   To implement this, you need to hook say/say_team, and use marking (bool) variable, that tells to system that player in "input mode" when hook triggers. After input variable resets to false. Also, i provide 'say /cancel' option to cancel input.

How many extra actions will now have to be done instead of sending one command

[afwn90cj93201nixr2e1re]

That's must be done 10 years ago. Suck. Some shitty fixes from old ExtraMirror src.

Maybe it' will be fixed in new update. Wait till the end.

[fl0werD]

You can use say command hook as in sourcemod

https://github.com/alliedmodders/sourcemod/blob/master/plugins/basebans.sp#L385-L395

[SamVanheer]

The messagemode and messagemode2 commands were explicitly flagged as privileged. You're not getting those back because they're part of an attack vector for exploits.

[WPMGPRoSToTeMa]

@SamVanheer that is really bad because it can be filtered without breaking any existing safe usage of it. I can help to accomplish the best solution for the command filtering if Valve developers don't have time for it.

[SamVanheer]

@WPMGPRoSToTeMa agreed, the command given should be filtered but they decided on this solution instead. I don't know why they decided to do this, it would be nice if we could get some direct communication with them.

[afwn90cj93201nixr2e1re]

Check if messagemode came with 1 arg, then if arg === any registered command, block. Also check args.

[vidme]

seems like its working again

[SamVanheer]

The messagemode and messagemode2 commands are now no longer marked as privileged.

[metita]

based Valve

Edit: any info on the specific changelog from todays update?

[StevenKal]

Thank you VALVe for making an effort toward the direction of the player's wishes. Just try, in the future, to make better efforts at making quality changes/fixes (more smooth...), then test in details first before pushing the updates to the public. This will prevent some complain & inconvenients, like this.

One word about some restricted commands: I see things like "kill", "say", etc., but you looks not really aware about the fact server owners can, via AMX, kill the player using other ways (as calling the "Killed" vfunc), and send a chat (say) message via internal command or by using the "SayText" message... So I suggest to remove them from the list, because their effect is bypassable. And please do not block some useful commands (as setinfo), used to store some infos client-side rather than server-side, which is better for reliability at through multiple servers (unique data always available on the client, no need to set it and save multiple times at through differents servers... I know it's not the case on filter set to 0, but I'm just telling you, in case of you have plans to change your restrictions settings.

[afwn90cj93201nixr2e1re]

some useful commands (as setinfo)

:/

U can use database instead of put some shitty info into limited client info storage.

[afwn90cj93201nixr2e1re]

Now standart cmd's in messagemode {x}, where {x} - one of registered cmd - are blocked/filtered. Other stuff, like messagemode ban_reasons - available.

[StevenKal]

U can use database instead of put some shitty info into limited client info storage.

Well, does the AMX's language setinfo sound like a "shitty" info for you? "setinfo" should only be used to store persistent settings (and only the most important & frequently used/shared ones, as the AMX's language I've just quoted), because this is certainely the best & most reliable way to keep the latest data available (except when the client configuration got modified/removed, etc.). Using MySQL database is not better than a single file per AuthID/IP or a single for all of those (in the server configs directories), except for a group of servers (community servers...), where this can be shared.

Except for some default client settings as rate, etc., any custom setinfo that could be added is just "data" (like a field on an Excel spreadsheet), and there is nothing harmful with that, even when those can contain "shits" as you said. Only the limit (that I'm talking below) could cause problem for new upcoming setinfos backup.

Unfortunately the setinfo's buffer is quite limited (255 chars), which remains a problem, and nothing has been made to increase it a bit on the updates, even under Sven Co-op.

[afwn90cj93201nixr2e1re]

Using MySQL database

U know only 'bout ORM db? Ok. So...

[afwn90cj93201nixr2e1re]

"setinfo" should only be used to store persistent settings (and only the most important & frequently used/shared ones, as the AMX's language I've just quoted), because this is certainely the best & most reliable way to keep the latest data available (except when the client configuration got modified/removed, etc.).

u can use external amxmodx storage for set some info, use https://github.com/alliedmodders/amxmodx/blob/7c7ad3d3c0b269f448f73337f996e838d2d510c8/amxmodx/amxmodx.cpp#L2498 It's better than server slowhacking.

[StevenKal]

I think you misunderstood me when I've talked about "persistance" of the data. I'm talking about informations being kept all the time and retrievable under ANY server under the SAME game (server X, server Y, server Z...). "set_user_info" just saves "server-side", but once the client left, the information is not kept with his own client (and so not saved in his "config.cfg"). That means if he goes to any other server, the information will not be retrieviable by that other server.

You think this: set_user_info(iClientID, "custom_key", "custom_value") Is the same (and better) than this: client_cmd(iClientID, "setinfo custom_key custom_value") ? The first has instant effect (and no slowhack), and it's only good for keeping things as old name, etc., in the "pfnClientUserInfoChanged" for example. While the second will have a latency before being executed, but if not blocked by the filter and if the client has still place for it in his local buffer, this will be saved, so you could type yourself in your console "setinfo", then probably see the new setinfo (custom_key custom_value) at the end of the list.

Do you understand better the assets? There is a solid & useful reason why the AMX[X]'s language plugin is using the second method rather than the first! But well, if you hate any kind of slowhacking no matter how harmless it is, this is another story. Besides, we shouldn't deviate from the original subject.

[SamVanheer]

How does SourceMod do it?

[WPMGPRoSToTeMa]

SourceMod has Client Preferences API which uses server-side storage.

[SamVanheer]

Then i suggest developing a version for GoldSource.

[afwn90cj93201nixr2e1re]

I'm talking about informations being kept all the time and retrievable under ANY server under the SAME game (server X, server Y, server Z...).

No, i get u. But client side - is not good way to keep dat data, coz it's can be modified/lost e.t.c.

"set_user_info" just saves "server-side", but once the client left, the information is not kept with his own client (and so not saved in his "config.cfg").

i know it, but for lang's u can use sqlite/nosql databases/geoip module

Is the same (and better) than this:

in your case - yep.

The first has instant effect (and no slowhack), and it's only good for keeping things as old name, etc., in the "pfnClientUserInfoChanged" for example.

u must use database for dat

There is a solid & useful reason why the AMX[X]'s language plugin is using the second method rather than the first!

That's crappy way.

Give me real task. If you have more than one server - u can use databases. Save user steamid via json object, which can contain some settings and other info, like oldnames:[{},{},{}]. If u wanna provide REST Api - u must create REST API service(there arer many lib's/frameworks which can made you service async) then server owners must use it, instead of slowhacking. Also if u don't wanna use databases - use cookies. There are many way's without slowhacking.

[mikela-valve]

Closing this as messagemode/messagemode2 are no longer blocked from unprivileged sources only privileged commands resulting from them.