In fluffos, when a user tries to change their password, or use the help system, or do something else in which we use modal_simple() (or probably other modal things), the prompts aren’t being displayed.
IE: If they try to change their passwd, they don’t see the prompt to type their current passwd until they have typed in something, and pressed enter – then everything gets done.
So, something feels like it’s wrong with the way modal inputs are working in fluffos. We are using the same code that worked in mudos.
this has been fixed recently, for client that needed TELNET_GA (mudlet),
the moment you call input_to() a GA will be inserted and can you confirm if it is still a issue on the last release?
I am using mudlet, so it is likely the issue is as you described.
My best guess as to the version we’re using is:
Driver: fluffos v2019.20201121-27-g2908c5ff
The discord post I’m getting this from was on January 27, 2021 - about a week ago. It’s likely we haven’t changed it since then.
right, the problem that I’m aware of , is that , when in LPC the command_giver triggers another player’s prompt , meaning player A execute something and trigger an input_to to player B, does that match the
problem you have?
There is no second player involved, so no.
Mudos:
passwd
Enter your current password:
Invalid password.
Aborting.
Fluffos:
passwd
Enter your current password: Invalid password.
Aborting.
Under fluffos, when I type passwd, I see nothing until I hit enter again.
Under Mudos, I can see the prompt for the current password before it waits for the current password.
The code between them is identical:
private nomask void confirm_current_password(string who, string s) {
write("\n");
//DEBUG(who)
if ( PASSWD_D->valid_password(you()->get_userid(),s))
modal_simple((: get_new_password, who :), "New password: ", 1);
else
write("Invalid password.\nAborting.\n");
}
private void main(string who) {
if (who && adminp(you())){
// require_privilege(1);
write("Attempting to set passwd for "+who+", type passwd without "
"any arguments to change your own password.\n");
modal_simple( (:get_new_password, who :), "New password: ", 1);
} else {
modal_simple((: confirm_current_password, you()->get_userid() :),
"Enter your current password: ", 1);
}
}Here is modal_simple:
//////////////////////////////////////////////////////////////////////
//:FUNCTION modal_simple
// varargs nomask void modal_simple(function input_func,
// mixed prompt,
// int secure,
// int lock)
//
// Description:
// This function is used for very simple input handling (such as
// retrieving a single line of input). It is much like modal_push()
// but the handler with automatically be popped after the first line
// of input is dispatched.
//
// This can be used as a direct replacement for input_to().
//
// NOTE: for multiple inputs, the standard push/pop is encouraged
// for efficiency reasons.
//////////////////////////////////////////////////////////////////////
varargs nomask void modal_simple(function input_func,
mixed prompt,
int secure,
int lock) {
push_handler(input_func, prompt, secure, 0, INPUT_AUTO_POP,lock);
}oh? how is push_handler written?
//////////////////////////////////////////////////////////////////////
// push_handler()
//
// Push a handler onto the modal stack. The stack is grown as
// necessary to accomodate the new element.
//
//////////////////////////////////////////////////////////////////////
private nomask void push_handler(function input_func,
mixed prompt,
int secure,
function return_to_func,
int input_type,
int lock
) {
class input_info info;
info = new(class input_info);
info->input_func = input_func;
info->prompt = prompt;
info->secure = secure;
info->return_to_func = return_to_func;
info->input_type = input_type;
info->lock = lock;
modal_stack += ({ info });
if ( info->input_type == INPUT_CHAR_MODE )
efun::get_char( (: dispatch_modal_input :), info->secure | 2);
else
efun::input_to( (: dispatch_modal_input :), info->secure | 2);
}oh I see the issue, it looks like the prompt is written after the input_to is called, That’s the difference.
The previous fix is for prompt writes before calling input_to. interesting… I need to double check how mudos use to handle TELNET_GA, because clearly if it works there I can make it work the same way
1 Like
This issue is currently preventing us from migrating to fluffos from mudos.
Should I keep waiting for fluffos to support prompting after input_to is called, or should I remove the prompt completely, and just do a write before the input_to is called?
I can’t re-produce what you are saying, , as far as I can tell , MudOS also never have worked correctly with Mudlet, so there is no 100% fix as the problem is on mudlet side. The problem only appear when server doesn’t “write” anything and just send back a GA, as long as the server writes something with a GA, things works fine.
The cure is, use secure input_to and let the server write back the content received, I’ve made the change and tested this is working as expected. as you can see the example here: https://github.com/fluffos/fluffos/blob/master/testsuite/command/test_input_to.c
Please let me know.
Also, the only probmatic case is when a input_to leads to another input_to immediately.
All the other cases are tested to be working correctly now.
Thank you for helping us. I have just had myself and a couple other creators log in and test the passwd function, and it is now working. I don’t know if the driver was updated in the meantime, but something has changed. My apologies for the resurrection.
yep I have fixed it.