Mudlet: Rendre commandSeparator réglable avec une fonction

ou vous pouvez utiliser le formulaire approprié, qui est sendAll("com1", "com2", "com3", "com4")
ou vous pouvez utiliser getCommandSeparator puis utiliser la sortie de celui-ci pour former votre chaîne, IE

local cs = getCommandSeparator
local commands = {
  "com1",
  "com2",
  "com3",
  "com4",
}
send(table.concat(commands, cs))

Je ne suis pas sûr que nous voulions encourager les auteurs de scripts à définir/réinitialiser le séparateur de commandes dans leurs scripts. Je vais me retrouver avec des tonnes de gens qui demandent pourquoi ils ne peuvent plus utiliser un point-virgule, ou pourquoi les deux-points divisent soudainement les choses en deux commandes et tout ce qu'il faut, c'est que votre fonction se trompe une fois avant de la réinitialiser. Surtout que vous ne faites rien avec si c'est ; et maintenant le joueur se retrouve avec une configuration cassée de manière inattendue.

Cela étant dit, setCommandSeparator pourrait être bon d'avoir juste pour avoir la suite complète de getters/setters de préférences, mais c'est exactement pour cela qu'il ne devrait pas être utilisé.

Assez juste. Mis à part les problèmes potentiels, pouvoir lua setCommandSeparator("somethingElseTemporarily") depuis la console principale serait un pas vers la résolution des problèmes pour les joueurs habitués à ';' comme séparateur de commandes. S'il était implémenté, il pourrait avoir besoin d'un >>> Soyez prudent car en cas d'utilisation abusive, vos scripts pourraient se casser. <<< dans le manuel.

Je ne comprends pas pourquoi tout ce changement temporaire du séparateur de commandes est en cours. S'ils sont habitués à ; , pourquoi ne le changeraient-ils pas simplement en ; comme ils en ont l'habitude ? C'est beaucoup à taper deux fois pour le changer d'avant en arrière quand ils peuvent simplement aller dans les paramètres et le changer une fois pour ce qu'ils veulent réellement.

Il semble que vous vouliez un alias qui alimentera sendAll dans le sens du premier commentaire de demonnic

Qu'est-ce que les gens tapent alors exactement dans vos autres clients pour envoyer plusieurs commandes, mais sans interférer avec les smileys clins d'œil et les manigances côté serveur ?

J'ai aussi pensé que l'omission d'une fonction pour définir le séparateur de commandes était une décision consciente et délibérée au niveau de l'exécutif :grin: pour éviter la casse qui pourrait survenir si un script/paquet le changeait tandis qu'un autre (éventuellement asynchrone s'exécutait à partir d'un minuterie !) était actif.

Autant que je sache, la discussion principale à ce sujet a eu lieu dans #1866 .

Cela ressemble à quelque chose que nous aurions pu faire, mais je pense que l'accessibilité peut finir par nécessiter que nous créions un moyen de la définir au moins à partir de la ligne de commande, même si elle est distincte de l'API lua elle-même.

Je ne comprends pas pourquoi tout ce changement temporaire du séparateur de commandes est en cours. S'ils sont habitués à ; , pourquoi ne le changeraient-ils pas simplement en ; comme ils en ont l'habitude ? C'est beaucoup à taper deux fois pour le changer d'avant en arrière quand ils peuvent simplement aller dans les paramètres et le changer une fois pour ce qu'ils veulent réellement.

Le problème réside dans les cas où le MUD accepte ';' comme entrée et il n'y a aucun moyen d'entrer un ';' sans saut de menu si ';' est votre séparateur de commandes. Être capable de faire des smileys est une chose (on pourrait créer un alias mudlet qui bascule temporairement le séparateur de commandes sur quelque chose d'inoffensif lors de l'utilisation d'un canal de discussion pour éviter cela). Une autre est que le MUD peut stocker des alias côté serveur, qui seront généralement plus rapides à traiter et plus rapides/plus faciles à créer que les alias côté client, mais ceux-ci utilisent ';' pour séparer également la commande.

tout cela me semble être une raison de ne pas utiliser ; comme séparateur de commandes.

Ce n'est malheureusement pas une option alors que nous avons déjà des centaines de déclencheurs et d'alias côté client qui utilisent send("tens of commands separated by ;") qui se cassent tous lors du changement du séparateur de commande. Je pense que l'habitude vient de ZMud qui utilise ; pour séparer les commandes, bien que l'analyseur de ZMud envoie ; s'il est entouré d'espaces. Et si doubler le séparateur de commandes envoyait simplement cela à la boue à la place? Comme si votre séparateur de commande comme dans mon cas était ; alors envoyer ;; enverrait un ; à la boue à la place donc par exemple taper say hello everyone;;) enverrait say hello everyone;) . Si vous avez utilisé ;; comme séparateur de commande, vous feriez ;;;; pour échapper au séparateur de commande et envoyer ;; . Pourrait avoir une case à cocher dans les préférences qui activerait / désactiverait cette option, désactivée par défaut, ainsi que pour éviter de casser la fonctionnalité pour tout ce qui pourrait casser le doublement du séparateur de commandes, bien que je ne puisse pas imaginer quel serait le mal.

Si vous avez utilisé ;; comme séparateur de commandes, vous feriez ;;;; pour sortir du séparateur de commandes

Pensez-vous que les gens accepteront de taper le point-virgule quatre fois ? :thinking: Je ne pense pas que ce soit réaliste.

Pensez-vous que les gens accepteront de taper le point-virgule quatre fois ? 🤔 Je ne pense pas que ce soit réaliste.

Je ne pense pas que ceux qui ont déjà adopté un séparateur de commandes à 2 caractères trouveraient très souvent le besoin d'échapper à leur séparateur de commandes. Combien de fois auriez-vous besoin d'échapper à un séparateur de commandes déjà défini sur ;; ? L'alternative est simplement de ne jamais pouvoir envoyer ;; au MUD de quelque manière que ce soit, n'est-ce pas ? Je suis d'accord que s'échapper serait fastidieux pour ceux qui ont 2 caractères ou plus définis pour leur séparateur de commandes, mais n'était-ce pas le but de définir 2 caractères ou plus dans votre séparateur de commandes que vous ne rencontreriez pas de problème avec l'envoi à la boue a seul caractère du caractère échappé ? Il serait intéressant de voir un sondage sur ce que les gens utilisent comme séparateur de commandes, et s'ils ont adopté ou non ;; ou un autre caractère doublé.

Je ne pense pas qu'un sondage soit utile parce que cela dit « allons foutre en l'air la minorité », quelle que soit la minorité qui finira par être.

Le scénario d'origine :

local x = getCommandSeparator()
if x ~= ";" then setCommandSeparator(";")
send("com1;com2;com3;com4")
setCommandSeparator(x)
else
send("com1;com2;com3;com4")
end

C'est une somme de travail insensée, pourquoi compliquer autant les choses ? Si vous avez plusieurs choses à envoyer, utilisez sendAll() ?

Je ne pense pas qu'un sondage soit utile parce que cela dit « allons foutre en l'air la minorité », quelle que soit la minorité qui finira par être.

Je ne vois pas comment quelqu'un serait vissé par une méthode pour échapper au séparateur de commandes. Une nouvelle option ou fonction de préférences ne devrait pas interrompre les fonctionnalités actuelles. Je suis curieux de savoir ce que les gens utilisent réellement pour leur séparateur de commandes, si les gens ont adopté un séparateur de commandes à 2 caractères afin qu'ils puissent envoyer ce caractère au MUD ou non. Si votre séparateur de commande est un seul ; , alors ;;) enverra ;) et contournera le séparateur de commande. Si votre séparateur de commande est un double ;; alors ;) enverra toujours ;) sans activer le séparateur de commande. Si vous vouliez envoyer ;; pour une raison quelconque, par exemple gossip Hey guys, I use Mudlet and my command separator is ;; , alors vous pourriez taper ;;;; pour envoyer le ;; au MUD dans l'exemple précédent.

C'est une somme de travail insensée, pourquoi compliquer autant les choses ? Si vous avez plusieurs choses à envoyer, utilisez sendAll() ?

Ce serait une solution de contournement si nous avions une fonction setCommandSeparator() pour ceux qui aiment utiliser ; comme séparateur de commandes mais qui ont encore besoin d'envoyer ; à leur MUD. sendAll() fonctionne très bien s'il ne s'agit que de 2 ou 3 commandes, mais lorsque vous obtenez 30 ou 40 commandes d'affilée, celles-ci deviennent fastidieuses à écrire assez rapidement par rapport à la séparation des commandes avec la commande ; déjà existante séparateur.

Je suppose que cela est devenu 2 suggestions maintenant, une pour la fonction setCommandSeparator() et l'autre une option de case à cocher des préférences pour Double command separator to bypass the command separator . Je ne suis pas sûr de l'étiquette pour Github dans ce cas, alors mes excuses là-bas !

Je ne pense pas que vous soyez réaliste lorsque vous dites à quelqu'un qu'il doit taper ;;;; ... désolé ! La réponse que vous obtiendrez probablement est "vous vous moquez de moi ?"

Nous n'avons pas inclus la fonction pour commencer pour une raison spécifique - elle permet de mauvaises habitudes. Je comprends la friction que les joueurs de votre jeu ont avec cette mauvaise habitude et à quel point c'est difficile, et ils aimeraient faire plus de travail en mettant de très gros alias de script qui changent, éditent, etc. habitudes... mais peut-être est-il préférable de changer l'habitude pour quelque chose de mieux à la place ?

Si vous souhaitez envoyer plusieurs choses, n'utilisez pas send() avec le séparateur de commandes. C'est une mauvaise pratique. Nous avons sendAll() pour cette raison qui évite complètement ces dégâts. Voir le code démoniaque collé un peu plus tôt.

Je comprends tout à fait que vous souhaitiez faciliter la transition vers Mudlet. Mais permettre de mauvaises habitudes n'est probablement pas une bonne façon de procéder, car à la fin Mudlet deviendra alors aussi merdique que les autres clients, n'est-ce pas ?

Je ne pense pas que vous soyez réaliste lorsque vous dites à quelqu'un qu'il doit taper ;;;; ... désolé ! La réponse que vous obtiendrez probablement est "vous vous moquez de moi ?"

Ils n'ont pas à le faire bien sûr, seulement s'ils veulent échapper au séparateur de commandes pour quelque raison que ce soit. S'ils utilisaient un seul ; comme séparateur de commande, ils n'auraient qu'à le taper deux fois pour s'échapper et envoyer un seul ; . ;)

Si vous souhaitez envoyer plusieurs choses, n'utilisez pas send() avec le séparateur de commandes. C'est une mauvaise pratique. Nous avons sendAll() pour cette raison qui évite complètement ces dégâts. Voir le code démoniaque collé un peu plus tôt.

Malheureusement, je n'avais pas réalisé que sendAll() était l'option préférée pour cela lorsque j'ai écrit beaucoup d'alias et de déclencheurs et que je ne connaissais pas non plus le speedwalk() pour saisir de nombreuses directions.
Je me suis donc retrouvé avec beaucoup d'alias qui ressemblaient à quelque chose comme ça "brief;compact;s;s;w;w;w;w;w;w;w;w;w;w;w;w;w;w;w;w;s;w;w;s;s;w;s;s;s;s;s;e;s;s;e;e;s;e;e;n;e;e;n;e;n;d;d;n;n;n;d;e;e;s;s;s;u;u;u;n;u;u;n;n;w;n;n;u;u;u;n;n;enter lift;u;s;s;s;s;s;s;s;d;d;d;e;e;e;s;s;s;e;e;e;s;s;e;s;e;s;e;e;s;u;u;u;u;u;e;n;n;n;e;n;n;n;e;n;n;n;n;e;e;s;e;s;e;n;n;e;n;e;n;e;s;e;s;e;e;s;s;s;e;e;e;s;brief;compact"

Revenons au sujet cependant, je ne crois pas que devoir sauter dans le menu pour échanger les séparateurs de commandes lorsque le besoin se fait sentir d'envoyer le caractère que l'utilisateur a choisi pour le séparateur de commandes au MUD, puis sauter à nouveau dans le menu pour le revenir, est un amélioration de la conception par rapport aux autres clients à cet égard et je pense que Mudlet peut faire mieux.

Ouvrez un éditeur qui peut effectuer une recherche et un remplacement de regex, mettez ce modèle dans : (.+?); et remplacez-le par "\1", et cela vous permettra d'atteindre 95 % du chemin pour chaque alias.

Malheureusement, je n'avais pas réalisé que sendAll() était l'option préférée pour cela lorsque j'ai écrit de nombreux alias et déclencheurs et que je ne connaissais pas non plus le speedwalk() pour saisir de nombreuses directions.

D'accord, nous allons améliorer les documents ici afin que cela aide pour l'avenir.

Edit: c'est fait dans tous les endroits pertinents.

Ma question reste toujours sans réponse :

Qu'est-ce que les gens tapent alors exactement dans vos autres clients pour envoyer plusieurs commandes, mais sans interférer avec les smileys clins d'œil et les manigances côté serveur ?

Par exemple, je peux supposer que la plupart des joueurs ne veulent même pas trop plonger dans les scripts d'alias, ils veulent juste taper quelque chose comme par exemple speedy s;s;w;w;w;s;s;s;e;s;s;e;e;u;u;u;n;n;enter lift;u;s;s;d;e;e et ainsi de suite.

Si tel est le cas, vous pouvez facilement créer et distribuer un alias qui reconnaîtra la commande speedy et divisera le reste en éléments individuels qui pourront ensuite être envoyés séparément avec sendAll comme expliqué ci-dessus.

Voilá, les joueurs sont contents, pas besoin d'utiliser ou de changer de séparateurs du tout, du tout.

En aucun cas, je ne recommande le saut de menu pour continuer à définir et à réinitialiser votre séparateur de commandes préféré par rapport à celui que quelqu'un a utilisé dans ses scripts (rappelez-vous qu'il peut également y avoir des auteurs en conflit).
Je ne tolérerais pas non plus qu'un auteur puisse changer le séparateur sans l'avis du joueur et que tous les autres auteurs de scripts et le joueur lui-même en soient affectés.

Ma question reste toujours sans réponse :

Qu'est-ce que les gens tapent alors exactement dans vos autres clients pour envoyer plusieurs commandes, mais sans interférer avec les smileys clins d'œil et les manigances côté serveur ?

Parmi les joueurs que j'ai interrogés, j'ai entendu quatre méthodes différentes pour désactiver/contourner le séparateur de commandes en dehors du saut de menu.

1. ~ avant le séparateur de commande, donc ~; enverrait ;
2. Doubler le séparateur de commande pour que ;; envoie ;
3. Touche de raccourci ctrl+r pour désactiver, entre autres, le séparateur de commandes
4. Une icône à la fin de la barre de saisie de la console qui désactive le séparateur de commandes

D'après ce que je peux dire, le séparateur de commandes préféré est ; parmi nos utilisateurs, mais d'autres clients offrent différentes façons d'échapper au séparateur de commandes, en envoyant des smileys ou en émettant des commandes dans la boue qui nécessitent un ; ne sont pas un problème.

S'en échapper me semble bien - quelqu'un sait ce que font zmud/mush ?

ZMUD dit :

le texte est analysé comme une série de commandes séparées par le caractère séparateur de commande (par défaut, ;). Chaque commande se compose du nom de la commande comme premier mot, précédé du caractère de la commande (par défaut, #). Les séparateurs de commande utilisés entre guillemets ("" ou '') ou crochets ([] <> ou {}) sont ignorés lors de la séparation des commandes individuelles. Par example
#SAY {a;b}
est une seule commande, où comme
#SAY a;b
est deux commandes.

Conseils de la communauté MUSHCLIENT :

Dans MUSHclient, si vous commencez une ligne par un point-virgule, les points-virgules suivants ne sont plus traités comme des séparateurs de ligne.

L'approche de Mushclient semble plus raisonnable... mais voulez-vous quand même aider à tolérer un mauvais comportement ? Corriger les alias existants n'est pas difficile, voir https://github.com/Mudlet/Mudlet/issues/3677#issuecomment -620511178, et avec de meilleurs documents, moins de gens commenceraient à faire l'erreur.

@KitchenMUD êtes-vous capable de réparer vos alias avec ?

@KitchenMUD êtes-vous capable de réparer vos alias avec ?

C'est fastidieux, mais je peux convertir ceux qui utilisent send en sendAll en utilisant la méthode que vous suggérez.

Espérons que ce ne soit pas beaucoup plus de travail que d'intégrer l'utilisation de setCommandSeparator()

Espérons que ce ne soit pas beaucoup plus de travail que d'intégrer l'utilisation de setCommandSeparator()

@ vadi2 C'était peut-être un mauvais exemple de ma part. J'ai pensé que puisque nous avons déjà getCommandSeparator() , alors une fonction homologue setCommandSeparator() serait une solution facile. Le principal problème , je pense, est que Mudlet devrait avoir une méthode pour échapper au séparateur de commandes choisi en dehors de l'obligation pour l'utilisateur de sauter dans le menu.

Peut-être qu'une meilleure fonction serait une nouvelle qui ignore complètement l'analyse du séparateur de commandes et envoie directement ce qui est entré dans le code ? Il est plus sûr d'empêcher les utilisateurs finaux de gâcher quelque chose, en dehors d'une solution d'interface utilisateur.

Peut-être qu'une meilleure fonction serait une nouvelle qui ignore complètement l'analyse du séparateur de commandes et envoie directement ce qui est entré dans le code ?

J'aime cette idée. Cela le résoudrait-il pour vous ?

Que pensent les autres dans @Mudlet/lua-interface ?