![]() |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
By now you're fairly familiar with the efun write()
, it simply
outputs data to whoever is registered as listening, it might be a player
or it might be an object. Usually this function suffices, you have full
control of what you want to write and who you want to write it
to. However, there exists one function that sometimes is necessary,
namely write_sockect()
that only writes to the interactive
user. If none exists, it writes to the central error log instead. It works
analogous to write()
in all other aspects. Coding ordinary objects
you will never need to use this one, it's mostly or perhaps I should say
only, used for certain mudlib objects, particularly to do with logging in
players.
Writing is nice, but sometimes you want to relate whole parts of files
quickly. Then you should use the efun cat()
. It will print
a specified portion of a file directly on the screen quickly and easily.
There even exists a special efun called tail()
for listing only
about the last 1080 bytes of a file in the same manner. cat()
makes sure that it starts reading from a new line and returns the number
of lines actually read. tail()
returns 1 on success and 0 on
failure.
int cat(string path, int start, int len); int tail(string path); e.g. // List 80 lines in the file TESTFILE, 20 lines down cat("TESTFILE", 20, 80) // List the ending of the same file tail("TESTFILE); |
A small warning, if you use cat()
on long files you might get an
eval-cost error. This is fairly common when you have logs or instructions
you want to display, and forget to cut them up into smaller parts.
Most input to LPC programs comes as arguments to commands. However, at
times you need to actually ask the player for input and he needs to
answer. This poses a special problem since object execution in the
gamedriver is sequential; if you stop to wait for an answer, all of
the game will stop along with you while the player makes up his mind
(if ever) and types. This obviously won't do. Instead you can use
the special efun input_to()
which allows you to specify a
function which then will be called with whatever the player types
as argument, after the completion of the current function. This sounds
complicated but is not, just look at this example:
void input_to(function func, void|int noecho); e.g. interrogate_fun() { write("Please state your name: "); input_to(func_2); } func_2(string n_inp) { string name; if (!strlen(n_inp)) { interrogate_fun(); return; } name = n_inp; write("\nState your sex (male or female): "); input_to(&func_3(, name)); } func_3(string s_inp, string name) { string sex; if (s_inp != "male" && s_inp != "female") { write("\nState your sex (male or female): "); input_to(&func_3(,name)); return; } sex = s_inp; write("\nState your occupation: "); input_to(&func_4(, name, sex)); } func_4(string o_inp, string name, string sex) { string occupation; if (!strlen(o_inp)) { interrogate_fun(); return; } occupation = o_inp; write("\nYour name is " + name + ",\n" + "you are a " + sex + " " + occupation + ".\n" + "\nThank you for your cooperation!\n"); } |
If you specify the second argument to input_to()
as 1, whatever
the player types will not be echoed on his screen. This is what you want
to do for passwords and other sensitive information.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |