 |
2004-10-23 :: A Greenasaurous Ate My Car.
Todays update features yesterdays stuff, as I was too tired to write up what went
on yesterday. I'll just get straight to it:
If a DCC chat session (in response to someone typing your trigger) isn't accepted
or established within 120 seconds (2 minutes), TuxServe will assume that the user
cannot connect and remove them from the list of users. 120 seconds also seems to be
the same amount of time XChat gives for a DCC chat session to be established. A
related note; if you cannot establish a DCC chat session with them, but they
start a DCC chat session with you (before the 120 seconds timeout), it will still
work as if you connected to them as normal. But, if you can't DCC chat with people,
chances are that you can't DCC send, either - meaning that it is pretty useless :)
Whilst on the subject of DCC stuff: if a DCC send stalls, or fails to connect (times
out), TuxServe will class these as failed sends and move to the next one. And whilst
on the subject of sends: when a user types "sends" into the fserve window, they will
now only see the filename of the sends - not the full path, as before. Also, if you
use the command "/ts csaq show_sends" it will look slightly better - and you get to
see the full path - the same as with the queues. Another thing about listing the
sends: it will also list sends which are connecting or waiting, as well as those which
are already connected and sending.
The user commands "clr_queue #" and "clr_queues" will either confirm that the queues
have been cleared, or report an error to the user. I noticed last night that users
using the "clr_queue #" command can clear ANY queue in the queues list - not
just their own. That's now been fixed - it checks if the queue is theirs before clearing
it. If it is theirs, it clears it and lets the user know that it was successful - if not,
it will let the user know that this is not their queue, and that they can't clear it.
The users can now use "cd ../" as well as "cd ..". If you included the "/" on the end
of the "cd .." command, it wouldn't work - it would say that it doesn't exist. That's
been fixed. When adding or changing a "trigger_dir", TuxServe will add a "/" to the end
of the path if you don't include one. The warning about using long unsigned ints has
been fixed, too.
Now for the biggest change/update - something called "show_info". I can't take credit
for this idea; Eno_ came up with this great idea. Basically, "show_info" will display
information, written by you, about each dir. This may take some explaining, so bare with
me :) Say, for example, one of the dirs accessable via your fserve contained a collection
of rar archives which are all passworded - how do you let the user know of the password?
Put in a text file "password_in_here.txt"? Wait until they ask you for the password? Or
use "show_info". When a user enters a directory on your fserve, TuxServe will (if show_info
is enabled) check for an "info file" for that directory - if it finds one, it will display
the text in the file just above the file listing of the directory. This way, you can
include specific notes/info about each directory that will automatically be displayed to
the user. So, if we think back to our previous example of a dir full of rars, you can
put some text in the info file - something like this:
All the rar archives in this directory are password protected - the password is "monkeys"
Useful, huh? :) Now, the "tricky" part - how to actually use it. Well, first of all, you
need to enable "show_info" with "/ts config set show_info 1" - it's enabled by default.
Secondly, you need to create the actual info files. These are just plain text files, so
open up your fave text editor (pico!) and type out the information that you want the users
to see everytime they enter a specific dir. Once you've done that, you need to save it
with a specific name: ".TuxServe_info-<dir_name>". <dir_name> must be the name
of the directory it is to be placed in (and be careful - it's case sensitive!). If you
wanted this info to show whenever a user entered a dir called "lots_of_rars", you'd save
the info file as ".TuxServe_info-lots_of_rars". This file must also be in the actual dir
which the user is to enter - eg, ".TuxServe_info-lots_of_rars" must be in the dir called
"lots_of_rars".
Sorry if that seems a little confusing - I'll write up full docs for it later - after it
has been fully implimented. The above stuff works fine - but there is also going to be
support for info on each file, too. Please remember to keep the info files
reasonably short - I doubt that the users would be too pleased about reading though pages
of text. Also, you can include mIRC colour/formatting codes in this text (not XChat type
codes, though) - but the default colour is the second colour set in the config (which
is blue - or code 12, but default).
It's now been exactly 4 weeks since the latest release, and I'm pleased to say that
there have been 137 downloads so far :) The next version, v0.0.11alpha, should be
released in 9 days; the 1st of November. All of these changes and updates that you've
read about can be found on the CVS repository. If you need any help, or want some
stuff (like "show_info") explained, feel free to drop by on IRC.
Update: I forgot to mention the "!voiceme" feature. I'm considering removing
it from TuxServe, and either making it a seperate plugin - or just abandoning it altogether.
I don't really like the idea of sticking too much stuff into 1 app. TuxServe is an fserve,
and a "!voiceme" feature isn't needed. If you want this feature kept in, contact me - if
I get enough responses (about 10), I'll keep it in. Otherwise, it's gone.
Anyhoo, that's about it for today - even more stuff to come tomorrow, hopefully.
Enjoy.
Aypok...
|
|
 |
