documentation on MXP afk and MXP recommend_option

Hello Herr Gammon ;)

Is there a source for the exact syntax your MXP <afk> and <recommend_option> extensions expect? I could only find some hints in the changelogs.

I'd be insterested in the following - and I think it might be useful for others to:

1.) What syntax does MXP <recommend_option> exactly expect? ("option1 option2 ... " or "option1=on ... " ?).
What defaults would these options otherwise have?

2.) What syntax does MXP <afk> expect - in the shortform and with the challenge-keyword.
What where your intentions for it? (because exchanging MXP <afk> responses cancels the idle state on the connection, doesn't it?)
Why did you implement the additional challenge word?

Did you add other MXP extensions, that I missed?

Thanks

Presumably, server-side support for this would treat these messages as not changing idle status of the connection as far as the MUD is concerned.

The afk tag works like this:



The AFK figure is the number of seconds since user input (ie. a command typed). The AFK response would cancel TCP idle-time, yes.

The challenge was intended to make it harder for a client to simply spit out AFK replies periodically. The idea was that the server would send out a random challenge, and that challenge had to be incorporated in the response.

---

As for <recommend_option> the release notes explain it fairly well:


Implemented MXP tag <recommend_option> that lets a server recommend that a client option be set. This has to be enabled on the MXP/Pueblo configuration page.

The options that the server may set are currently: mud_can_change_link_colour, mud_can_remove_underlines, underline_hyperlinks and use_custom_link_colour.

eg. <recommend_option use_custom_link_colour=0>


This is basically to let the server recommend that the client turns on, or off, one of those four options.

In MUSHclient, you have to have enabled the option "MUD can change some options", and if you have that checked, then the recommendation is acted on.

option=value (where 0=off and 1=on).

The defaults are whatever they had the client configured to be.

Ok, thanks for the clarifications.



I am curious, did this work as intended? ;)
Did this become necessary because the <afk> it was misused by players?




I will just add for completeness sake: On my installation this means that the options are by default:

user custom link colour is ON
mud can change link colour is ON
underline hyperlinks is ON
mud can remove underline is OFF
mud can change some options is ON

There is a thread somewhere about this. Basically we gave up on the idea because it is too easy to defeat it. The whole point is to defeat botters, right? But people who want to advance by having a bot running for hours killing mobs, or gathering resources, are going to have the motivation, and quite possibly the skill, to work around it.

For example, a simple plugin, which uses a timer, which uses the Windows PostMessage function call to put keystrokes into the Windows message queue. I could probably write such a thing in 15 minutes. Then, it could periodically do a "look" or "sigh" or something, and MUSHclient would think they had actually typed that, and clear the AFK flag.

Or there was the Logitech G15 gamers keyboard.



I think that could be programmed to do things in a loop, with a delay. So you plug that into a spare USB port, configure it to send some harmless command every 10 minutes, and hey presto! AFK flag cleared.