Mudlet: Le serveur IRE ne négocie pas pour MXP

Cela pourrait expliquer le code original - mais ils pourraient ne pas être les seuls, et nous ne pouvons pas casser les choses par défaut et ajouter des solutions de contournement pour chaque jeu.

Vrai; cependant, alors le problème retombera sur Evennia et d'autres jeux MUD qui négocient aussi, @ vadi2 : rire: vous jouez donc peut-être avec la patate chaude. : man_shrugging:

Selon Evennia, le mushclient fonctionne pour eux! Cela ne doit peut-être pas être un choix.

Intéressant. donc nous avons juste par défaut MXP pour aller de l'avant? (et de mettre un commentaire quelque part là-dedans pour faire référence à ce problème ...)

Eh bien, non, nous devons trouver une solution qui fonctionne à la fois pour Evennia et IRE. Pour Evennia ne pas échapper à <> avant que MXP ne soit négocié et pour IRE de faire fonctionner MXP d'une manière ou d'une autre sans qu'ils ne le négocient.

C'est la chose difficile que nous devons faire. Les utilisateurs ne se soucient pas de savoir si cela fonctionne sur l'un ou l'autre, ils veulent que Mudlet fonctionne simplement: man_shrugging:

peut-être créer une fonction Lua qui peut activer mxp pour l'utilisateur. J'ai remarqué que nous n'avons pas de fonctionnalité Lua (paresseuse) qui nous permet d'éteindre ou d'activer mxp directement. avec cette idée, nous pourrions les coupler dans un profil.

en même temps, il est utile d'avoir cette fonctionnalité pour que les codeurs mud et les utilisateurs mudlet puissent créer un alias à activer et désactiver pour l'observer facilement.

C'est toujours une solution de contournement pour les utilisateurs IRE. Comment MUSHclient le fait-il - et fonctionne-t-il réellement pour Evennia / ChatMUD et les IRE prêts à l'emploi?

Je dois noter que c'était «sur commande» par défaut dans le client mush.

Ah ok, donc IRE est sorti de la boîte.

Je pense essayer d'implémenter quelque chose de similaire dans mushclient sous la forme de:

1) 'oui / non / sur commande'
2) il devrait également fournir une info-bulle utile expliquant quelle option convient à quel serveur. par exemple, pour «oui»:
"Il est recommandé de sélectionner cette option si vous jouez à des jeux IRE (achaea, aetolia, starmourn, etc.).

3) implémentez ceci dans l'option XML (n'abandonnez pas l'option forced_mxp_negotiation) à la place, utilisez-la pour importer l'option dans une nouvelle variable. il s'agit de convertir l'ancien profil en un nouveau profil dans une mise à jour.
4) chaque profil par défaut aura une option XML qui peut être l'une de ces options activées / désactivées / une commande adaptée à chaque jeu respectif.

Cela ne fonctionnera pas, nous ne pouvons pas avoir un client compliqué qui nécessite plus de boutons et de télécommandes à mesure qu'il grandit juste pour que les choses continuent de fonctionner (et n'ajoutent aucune nouvelle fonctionnalité).

Qu'en est-il de la détection automatique du MXP et de son activation?

Nous voulons donc détecter mxp sous la forme de [#z et également détecter la négociation?

Oui. Fondamentalement, ajoutez une solution de contournement pour IRE (jusqu'à ce qu'ils le résolvent).

Je suis surpris qu'ils ne le négocient pas compte tenu de l'étendue de leur implémentation MXP - vous êtes super sûr que c'est le cas?

mushclient ou IRE?

COLÈRE

d'après ce que j'ai rassemblé, il peut être activé par leur configuration. bien qu'ils ne mettent pas encore en œuvre la négociation pour mxp. comme j'ai directement communiqué avec Tecton à ce sujet, il dit que cela pourrait être implémenté dans la prochaine mise à jour du moteur Rapture. (dans lequel je ne sais pas quand ce sera la prochaine mise à jour).

D'accord - ajoutons une option de détection automatique pour les cas où un moteur commence à le forcer (comme nous l'avions fait avant ... ha)

nous avons eu cette détection automatique avant tel ou ce même code avant de les modifier?

Non, rappelez-vous que nous avons supposé que MXP était activé sans que le serveur ne négocie pour cela - et c'est pourquoi IRE a fonctionné.

ensuite
1) par défaut, on laisse mxp on (avec mMxp à false sur init) évidemment IRE peut l'activer par (esc) [4z
2) si et si un serveur mud est négocié, alors mMXP sera retourné à true. (AKA code 0 ligne ouverte)

bien?

Je pense que oui - vous dites que MXP peut être activé soit par une négociation appropriée, soit par nous scannant la chaîne magique. Sinon, il est désactivé et < , > s'affiche OK. Ça a l'air bien.

détection automatique magique. : p je vais faire un patch magique PR demain.

Rappelez-vous qu'il existe des MUD qui ne connaissent même pas / ne se soucient même pas de MXP, donc modifiez leur sortie s'ils utilisent < > pour, par exemple, une forme de mise en évidence d'une valeur dans une liste de sorte que d'un point de vue HTML / XML, il semble qu'une balise ne soit tout simplement pas activée. Quoi oh! Ou, au moins, il ne devrait PAS être activé par défaut ...! :Ne vois pas de mal:

Vous devriez pouvoir lancer la magie de détection automatique en mettant quelque chose dans TBuffer::translateToPlainText(std::string& data, const bool isFromServer) après la ligne:

                case static_cast<quint8>('z'):

cela interceptera TOUTES les séquences de code de contrôle MXP mais n'agira sur elles que si les conditions sont réunies. Vous devriez peut-être bloquer le tir avec isFromServer afin que seules les données du serveur (et les rediffusions correspondantes) chatouillent votre code - cela évitera les faux positifs de feedTriggers( ... ) appels par les scripts de l'utilisateur / packager ...: smiling_imp:

@SlySven merci. Je vais l'examiner.