Mudlet - Forum

In the current version of Mudlet the "auto connect" feature in the profile sends username, followed by password best I can tell.
When connecting to a MOO the correct syntax is "connect username password".
In Pueblo for example you can select the type of Mud/MOO you're connecting to in order to send the correct login sequence.

Any way to achieve this in Mudlet?

While you can't use the autologin field, you can create a trigger that does send("connect username password") to achieve this!

The game I play starts off by asking if you want to use color... seems to me it would make sense to just change the auto-connect feature to have an arbitrary list of commands to send on connect.

Well it'll be trivial to see the password then - at least it's in a password field right now.

I'd question why is it so vital to change the colour setting on every login. Do they ask you for the screenwidth as well before they let you log in? Seems like such an arbitrary thing to do.

Well, since we can probably assume the password is the last line sent to login, you could just have a list of commands to send before the password.

As for why it asks if you want color every time, I assume it is because the game started back far enough that some people were still playing via a terminal. But even after that, it has some into text after which you need to hit enter to continue. Then select that you want to login, as opposed to seeing who is online or viewing helpfiles, then finally your username and password. I made an alias for it, but having auto login would be nice.

But see the original request - it's all one command for the OPs game.

In which case, you could treat it all as the password. Still protects password privacy, while allowing flexibility. Alternately, you could still have name and password fields, but then have have room below to list commands to send, in which you use some sort of variables to stand in for those values.

So a typical game might have this:
%name
%password

The OP’s game would use this:
connect %name %password

And mine would use this:
y

l
%name
%password

Thanks everyone, the trigger method worked well.
In the end I'm sending my password via telnet in plaintext across the Internet anyways, so being able to see the password in the trigger isn't that big of a deal at this time.

Yeah, you might as well just use a trigger then instead of us making up a scripting language in the profiles chooser. I'm not seeing much of an advantage either way.

Now what would be really good is if MUDs standardised logins via some protocol that Mudlet could use!

Actually putting both the character name and the password in the "password" field separated by a space might not work, IIRC the password field is only sent if it and the character name fields are not empty - ah Use the Source, Luke suggests {see (void) cTelnet::handle_socket_signal_connected() in src/cTelnet.cpp} that the code has changed since I last saw it in that once it was nested so that a non-empty character name was sufficient to send just the character name but the password required BOTH...

Vadi wrote:Now what would be really good is if MUDs standardised logins via some protocol that Mudlet could use!

Well the underlying Telnet protocol does have a standard - after a brief flurry of option negotiation the Server would be expected to ask the Client for a user-name and then a password - exactly like a command line login on a *nix console. So sending a user name and a password after a short delay is not so unreasonable as it seems, unfortunately MUD servers are not exactly the same as a remote connection to a *nix computer in that they have to offer the means for a previously unknown user name to connect and set up a new account; this requirement is probably what led to some MUDs using a menu type system, even if that is limited to displaying a list of options and inviting the user to select an option to proceed. That, though, is where such a hypothetical protocol would come into play but I guess there is something of a chicken-and-egg situation in that Mudlet or any other client needs to support other MUDs without such a thing.