23 Sep, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
I would like to create a reusable input model for upcoming additions to my mud.
A good example is:
> You have selected quest "kill all orcs"
> Would you like to accept this quest? [Y/N]

Of course, this is just one example. Do any of you use something like this?
I would like to build a system that can be as reusable as possible. Obviously the
descriptor state can be changed, but there seems to be more to it than that.
23 Sep, 2009, Idealiad wrote in the 2nd comment:
Votes: 0
Do you mean a modal input model? Some OLCs do this, also some help systems – maybe E-mud (or is it Emlen mud? I think Scandum might know about this).


eta: just checked, it's definitely an Emud, not Emlen mud I'm talking about.
23 Sep, 2009, Sandi wrote in the 3rd comment:
Votes: 0
I'd advise putting in an event system to time things out, and using specific commands rather than states.
23 Sep, 2009, David Haley wrote in the 4th comment:
Votes: 0
Lua coroutines make it ridiculously easy to handle input like this: you can linearize the sequence of player I/O events into a single function.

function do_something(actor)
actor:sendText("hello there, was is your name?")
local name = actor:waitForLine()
actor:sendText("Oh, your name is " .. name .. ", right?")
local nameOk = actor:waitForBoolean()
if nameOk then
actor:sendText("yay")
else
actor:sendText("boo")
end
end


No need to use things like event systems or timers explicitly; you can merge all of this into your normal input model. If the actor has an active coroutine, then resume it with the appropriate input.
23 Sep, 2009, elanthis wrote in the 5th comment:
Votes: 0
I tend to avoid modal input in any way possible. You really don't need it either, if you don't mind having slightly longer response commands. The player has a zero or one "confirmation state" objects attached at any time. The built-in commands "accept" and "decline" then send a message to the object (if any), and processing occurs.

You can reuse this construction in all kinds of places. Trading systems, OLC systems… anything that needs to allow the player to accept or reject an input.
23 Sep, 2009, Barm wrote in the 6th comment:
Votes: 0
You could add something like a "command stack" to each client object. Just a FIFO list of functions to call. Every time the client types a command, a function is popped off the list and called using that input. If the list is empty (as in 99.999% of the time), call the normal input processing. Everything stays nice and asynchronous. If you wanted to get fancy, you could even push a prompt too:

client.push('Enter name:', name_func)
client.push('Enter password:', password_func)


Where name_func() might push itself back to the top if the user enters blank or invalid input, or gets called until it returns a non-error, etc.
23 Sep, 2009, Scandum wrote in the 7th comment:
Votes: 0
Idealiad said:
Do you mean a modal input model? Some OLCs do this, also some help systems – maybe E-mud (or is it Emlen mud? I think Scandum might know about this).

eta: just checked, it's definitely an Emud, not Emlen mud I'm talking about.

Emud stores the state for menu-like commands as a string, which contains the command and optional arguments.

For example, if you type edit, your "menu" variable gets set to "edit", then if you type "room" the input parser changes the input command to: "edit room" - and the edit_room function sets your "menu" variable as "edit room". Next if you type: desc, the input parser inputs: "edit room desc" which will place you in the room description editor.

A nice side effect is that players can enter either 'edit' 'room' 'desc' or 'edit room desc' with the latter putting you straight into the room desc editor without the menu option spams.
0.0/7