Mudlet: Сервер IRE не выполняет согласование для MXP

Это могло бы объяснить исходный код - но они могут быть не единственными, и мы не можем сломать что-то по умолчанию и добавить обходные пути для каждой игры.

Правда; однако тогда проблема вернется к Evennia и другим играм MUD, которые тоже договариваются об этом, @ vadi2 : смеется: так что вы, возможно, играете с горячей картошкой. : man_shrugging:

По словам Эвеннии, на них работает мушклиент! Возможно, это не было выбором.

Интересно. так что мы просто используем MXP по умолчанию, чтобы двигаться вперед? (и разместить где-нибудь комментарий, чтобы сослаться на эту проблему ...)

Что ж, нет, мы должны найти решение, которое подойдет как для Evennia, так и для IRE. Чтобы Evennia не ускользнуло от <> до согласования MXP, и чтобы IRE каким-то образом заставил MXP работать без согласования с ними.

Это трудная вещь, которую мы должны сделать. Пользователям все равно, работает ли он на том или другом, они хотят, чтобы Mudlet просто работал: man_shrugging:

возможно, создать функцию Lua, которая может включить mxp для пользователя. Я заметил, что у нас нет функции Lua (ленивый), которая позволяет нам напрямую выключать или включать mxp. с этой идеей мы могли бы объединить их в профиль.

в то же время полезно иметь эту функциональность, чтобы кодировщик (-ы) бурового раствора и пользователь (-и) мудлета могли создать псевдоним для включения и выключения, чтобы легко наблюдать за ним.

Это все еще обходной путь для пользователей IRE. Как MUSHclient это делает - и действительно ли он работает как для Evennia / ChatMUD, так и для IRE из коробки?

Я должен отметить, что по умолчанию в MUSS-клиенте это было «по команде».

А, ладно, это IRE выломано из коробки.

Я думаю о том, чтобы попытаться реализовать что-то подобное в Mushclient в виде:

1) 'да / нет / по команде'
2) также должна быть полезная всплывающая подсказка, объясняющая, какой вариант подходит для какого сервера. например, для «да»:
"Рекомендуется выбирать этот вариант, если вы играете в игры IRE (achaea, aetolia, starmourn и т. Д.).

3) реализовать это в опции XML (не отказываться от опции force_mxp_negotiation) вместо этого использовать ее для импорта опции в новую переменную. это преобразование старого профиля в новый профиль в обновлении.
4) каждый профиль по умолчанию будет иметь параметр XML, который может быть любым из этих параметров включен / отключен / команда адаптирована для каждой соответствующей игры.

Этого не пойдет, у нас не может быть сложного клиента, который требует больше ручек и брелков по мере роста, просто для того, чтобы все работало (а не для добавления каких-либо новых функций).

Как насчет того, чтобы мы автоматически определяли MXP и включали его?

Итак, мы хотим обнаруживать mxp в форме [#z, а также обнаруживать согласование?

Ага. По сути, добавьте обходной путь для IRE (пока они не исправят его).

Я удивлен, что они не обсуждают это, учитывая, насколько обширна их реализация MXP - вы уверены, что это так?

Mushclient или IRE?

IRE

из того, что я собрал, его можно включить с помощью их конфигурации. хотя они еще не реализовали согласование для mxp. поскольку я напрямую общался с Tecton по этому поводу, он сказал, что это может быть реализовано в следующем обновлении движка Rapture. (в котором я не знаю, когда будет следующее обновление).

Хорошо - давайте добавим опцию автоматического обнаружения для случаев, когда двигатель начинает форсировать его (как у нас было раньше ... ха)

у нас было это автоматическое обнаружение перед тем или иным кодом, прежде чем я их изменил?

Нет, помните, мы предполагали, что MXP был включен без согласования с сервером - вот почему IRE работал.

тогда
1) по умолчанию мы оставляем mxp включенным (с mMxp равным false при инициализации), очевидно, что IRE может включить его с помощью (esc) [4z
2) если и должен согласовываться какой-либо грязный сервер, то mMXP будет переключен на true. (AKA code 0 открытая строка)

хорошо?

Я так думаю - вы говорите, что MXP можно включить либо путем надлежащего согласования, либо путем сканирования нами волшебной строки. В противном случае он выключен, и < , > появятся нормально. Звучит неплохо.

магическое автоопределение. : p Я завтра сделаю волшебный патч PR.

Помните, что существуют MUD, которые даже не знают / не заботятся о MXP, поэтому искажают свой вывод, если они случайно используют < > скажем, для какой-то формы выделения одного значения в списке так что с точки зрения HTML / XML кажется, что тег просто не включен. Что ой! Или, по крайней мере, он НЕ ДОЛЖЕН быть включен по умолчанию ...! :не вижу зла:

Вы должны иметь возможность активировать магию автоматического обнаружения, поместив что-то в TBuffer::translateToPlainText(std::string& data, const bool isFromServer) после строки:

                case static_cast<quint8>('z'):

который будет перехватывать ВСЕ последовательности управляющего кода MXP, но воздействовать на них только при правильных условиях. Возможно, вам следует заблокировать запуск с помощью isFromServer чтобы только данные сервера (и соответствующие повторы) щекотали ваш код - это предотвратит ложные срабатывания от feedTriggers( ... ) вызывает скрипты пользователя / упаковщика ...: smile_imp:

@SlySven, спасибо. Я буду смотреть в него.